Рейтинг и отзывы — очень важны и нам тоже. Мы это понимаем и прорабатываем различные варианты. Если у вас есть конструктивное предложение в каком формате модифицировать сайт — пожалуйста, пишите. Все пожелания мы собираем и анализируем.
PS Недавно на сайте появился публичный профиль продавца, который помогает повысить (либо, наоборот, снизить) уровень доверия к продавцу.
Для вас есть принципиальная разница: вы будете сами устанавливать себе корневой сертификат или правительство без вашего ведома будет иметь удобную админку со всеми вашими личными данными у крупнейших технологических компаний?
PS Я тоже не одобряю программы слежки, но хочу подчеркнуть, что подобное происходит во всём мире, а не только в нашей стране.
В любом случае — вам придётся скрещивать две разные методики и дублировать состояния в модели и в компоненте. Так же вам придётся отказаться от некоторых встроенных плюшек моделей и коллекций.
Я не говорю о том что невозможно скрестить эти две библиотеки, я говорю о том что чем больше проект, тем больше будет возникать проблем и сложностей с их поддержкой. И идея flux сразу писать кучу кода уже не выглядит настолько безумной
Коллекции и модели от Backbone — это очень хорошо, но совершенно не про React. Мы у себя на проекте скрестили эти две технологии и теперь мучаемся. Лучше бы сразу на flux'е всё делали.
Проблема: Передаём в компонент коллекцию или только модель, меняем модель (коллекцию), сохраняем.
Ничего нигде не перерендеривается. React.state ничего не узнаёт о том что изменилась модель, потому что модель — это не плоская сущность.
Конечно можно использовать миксины вроде react-backbone, что проблему как бы решает, но в реальности только усугубляем положение, скрещивая две совершенно разных методики.
Вывод: Не используйте React и Backbone вместе, если вы вдруг решили это сделать прочитав статью. Поддержка этого решения дорого вам обойдётся.
Я бы хотел подчеркнуть что в жизни опытных программистов далеко не всё решается зарплатой. Альтруизм не зависит от возраста и опыта. Он может зависеть от таких факторов, как, например: семья, дети, плохое финансовое положение, учёба, нехватка времени.
Голосование уровня: «Вы хотите быть богатым и успешным или больным и бедным?»
Я же вижу тут три градации (давайте похоливарим):
— Художник — стартапер, студент, одиночка, совершающий первые шаги в программировании. Ему не о чем заботиться, поэтому он может работать круглосуточно. Но не может поддерживать то что сам написал. Только херачить код со скоростью пулемёта.
— Расписыватель под гжель — юниор, которому теперь нужно отчитываться за свою работу, однако он всё ещё уверен что в чём-то он умнее всех в интернете в целом и ведущего программиста в частности. Может замутить такую конструкцию, которая непонятна никому в его компании, однако у самого джуниора этот код вызывает восхищение.
— Маляр — опытный программист, который понимает что всё что он делает, будет переделано. И поэтому нужно изначально соблюдать спецификации и стандарты разработки. Он понимает что код будут поддерживать люди которые увидят его впервые, поэтому он старается писать код как можно проще и понятнее. Возможно это чуть скучнее, однако его код не вызывает батхерта у коллег.
Сделайте в своей клиентской библиотеке модель с приватными ключами и публичными методами. Где приватные ключи будут иметь короткие имена, а методы — человекочитаемые.
Плюс не забывайте записывать схему редиса при любом изменении.
Названия ключей и полей, по возможности, стоит делать короче, как и стараться меньше использовать ZSET, где SCORE тоже достаточно прожорливое поле.
PS И не стоит сильно заморачиваться с длиной если данных не много и их рост не планируется.
PS Недавно на сайте появился публичный профиль продавца, который помогает повысить (либо, наоборот, снизить) уровень доверия к продавцу.
PS Я тоже не одобряю программы слежки, но хочу подчеркнуть, что подобное происходит во всём мире, а не только в нашей стране.
С плагинами её можно сильно прокачать.
Зря только виртуалку ставил…
Я не говорю о том что невозможно скрестить эти две библиотеки, я говорю о том что чем больше проект, тем больше будет возникать проблем и сложностей с их поддержкой. И идея flux сразу писать кучу кода уже не выглядит настолько безумной
Проблема: Передаём в компонент коллекцию или только модель, меняем модель (коллекцию), сохраняем.
Ничего нигде не перерендеривается. React.state ничего не узнаёт о том что изменилась модель, потому что модель — это не плоская сущность.
Конечно можно использовать миксины вроде react-backbone, что проблему как бы решает, но в реальности только усугубляем положение, скрещивая две совершенно разных методики.
Вывод: Не используйте React и Backbone вместе, если вы вдруг решили это сделать прочитав статью. Поддержка этого решения дорого вам обойдётся.
Я же вижу тут три градации (давайте похоливарим):
— Художник — стартапер, студент, одиночка, совершающий первые шаги в программировании. Ему не о чем заботиться, поэтому он может работать круглосуточно. Но не может поддерживать то что сам написал. Только херачить код со скоростью пулемёта.
— Расписыватель под гжель — юниор, которому теперь нужно отчитываться за свою работу, однако он всё ещё уверен что в чём-то он умнее всех в интернете в целом и ведущего программиста в частности. Может замутить такую конструкцию, которая непонятна никому в его компании, однако у самого джуниора этот код вызывает восхищение.
— Маляр — опытный программист, который понимает что всё что он делает, будет переделано. И поэтому нужно изначально соблюдать спецификации и стандарты разработки. Он понимает что код будут поддерживать люди которые увидят его впервые, поэтому он старается писать код как можно проще и понятнее. Возможно это чуть скучнее, однако его код не вызывает батхерта у коллег.
Парируйте
Только не нужно забывать, что для того что бы увидеть подобный комментарий, уже необходимо наличие интернета
Плюс не забывайте записывать схему редиса при любом изменении.
Названия ключей и полей, по возможности, стоит делать короче, как и стараться меньше использовать ZSET, где SCORE тоже достаточно прожорливое поле.
PS И не стоит сильно заморачиваться с длиной если данных не много и их рост не планируется.