Товарищи, что вы хотите сказать всеми этими минусами? Что в России такого нет? В статье нет ни слова о том, что собеседование было в Америке.
Или это такая фанатичная любовь к России и нежелание признавать косяки процесса отечественной веб-разработки? Поясните, хотя бы…
5. A зависит от C и B, B зависит от C. Когда изменится C, без разницы, что будет изменено раньше, A или B, т.к. событие произойдет только после обработки обоих микрозадач. В крайнейм случае, если я ошибаюсь (а это вряд ли, см. статью), всегда можно перегрузить акцессор и создавать свои нотификации только в том случае, если оба свойства (B и C) будут изменены.
Я думаю, что тут вы сможете найти всю интересующую вас информацию.
Как я описал выше — будут лишние вызовы обработчиков
Я сильно извиняюсь, но я до сих пор не понимаю, о чём вы говорите. Если данные меняются блочно, например, через сеттер, то оповещение возникнет только в конце очереди микрозадач, т.е. когда все N свойств изменятся. Если изменяется одно свойство — оповещение происходит сразу. Опишите пожалуйста кейс, когда возникнут лишние вызовы?
Это отличная возомжность реализовать нативный дата-байндинг. О каком event flood вы говорите? Вы с такой скоростью меняете данные? Даже если и так, то каждый раз, когда мы двигаем мышь, так же возникают события. Я не вижу ничего плохого в расширении ES, тем более, что Вы, скорее всего, даже не заметите, как поменяется начинка всех современных фреймворков в сторону О.о
Ну, я все-таки согласен с Mingun по поводу перевода комментариев. Разумеется, в жизни такого делать не стоит, но ведь это обычный обзор, и чем понятнее — тем лучше. Было бы неплохо переводить и изображения (например, на схемах), но это, может быть, где-нибудь в следующих переводах.
Я не могу себе представить полифил для такого функционала. Невозможно отследить изменения свойства объекта не через акцессор. Думаю, как только спецификация будет окончательно утверждена, в ближайших на тот момент версиях появится поддержка такого функционала, даже в IE(разумеется, речь идет только об edge-версиях)
Согласен с вами, писал на vanilla js, потом перешел на coffeescript, а потом опять вернулся к native. Просто только с опытом приходит осознание самого языка: чем он является, а чем нет. Я думаю нет смысла переубеждать автора в том, правильно ли писать на препроцессорах к js или нет, тут каждый находит свою истину.
Но свои пять копеек я всё же внесу: кофе хорош, но только на каких-то простых или маленьких проектах, над которыми вы работаете один или в небольшой команде. Когда проект содержит сложную логику, на кофе становится тяжелее писать. Тем более мне нравится стандартизирванный код, а опциональность вроде do или () порой смущает. Когда большая команда разработчиков пишет на coffee, все в результате пишут по-разному, и никакие coffeelint тут не помогают(конечно, можно развести из этого холивар, но я не преследую такую цель, это просто моё мнение).
Везде нужно знать меру, но лично мы предпочитаем фанатиков, нежели специалистов широкой специализации. Проблема с последними довольно проста: они умеют всего понемногу, но не способны использовать все возможности инструментов, которые используют, что приводит к разнообразным велосипедам, которые приходится исправлять «фанатикам».
Есть замечательный метод shouldComponentUpdate, который решает проблему перерисовки дочерних представлений в зависимости от измененной информации. А по поводу Cortex или BB Model — это шаг в верном направлении, но на мой взгляд, раз уж React предполагает работу с immutable данными, то и механизм, который мы должны использовать в качестве модели хранилища, должен реализовывать возможность работы с таким типом данных. Из коробки ни Cortex, ни BB Model не умеют этого делать. Посмотрите в сторону flux, это дает пищу для размышлений
Вы ничего не путаете? MVC — шаблон проектирования. React может лишь реализовывать(или не реализовывать) этот архитектурный шаблон. И он не реализует его.
У нас есть state где происходит store a state
Да, мы сохраняем состояния, но не данные. Сохранение данных в состояниях является порочной практикой, я думаю вы должны знать об этом. Соответственно, данные которые должны сохраняться/изменяться в процессе работы с view, будут сохраняться не через React, верно?
Состояния работают по принципу модели, но это не даёт вам права говорить, что это реализация M из MVC.
Да, я не по наслышке знаком с этим вопросом(я говорю о работе с данными). В данный момент я пишу небольшую библиотеку, которая будет предоставлять уровень абстракции для работы с immutable данными. Те же состояния, стек изменений и т.п. — только для данных. Я буду рад поделиться наработками и обязательно напишу об этом, но всему своё время. Думаю, это будет целая тема для разговора, т.к. имхо, сейчас работа с данными при использовании React — это самая слабая сторона.
Позволю себе не согласиться с вами: React — это не фреймворк, это просто библиотека, которая предоставляет удобную и быструю работу с DOM, разделяя UI на виджеты. Я согласен, что это скорее похоже на View из стандартной MVC, но таковым не является, т.к. содержит в себе логику работы с данными.
Что касается статьи — очень достойно, было приятно прочитать.
Спасибо.
Или это такая фанатичная любовь к России и нежелание признавать косяки процесса отечественной веб-разработки? Поясните, хотя бы…
Я сильно извиняюсь, но я до сих пор не понимаю, о чём вы говорите. Если данные меняются блочно, например, через сеттер, то оповещение возникнет только в конце очереди микрозадач, т.е. когда все N свойств изменятся. Если изменяется одно свойство — оповещение происходит сразу. Опишите пожалуйста кейс, когда возникнут лишние вызовы?
Но свои пять копеек я всё же внесу: кофе хорош, но только на каких-то простых или маленьких проектах, над которыми вы работаете один или в небольшой команде. Когда проект содержит сложную логику, на кофе становится тяжелее писать. Тем более мне нравится стандартизирванный код, а опциональность вроде do или () порой смущает. Когда большая команда разработчиков пишет на coffee, все в результате пишут по-разному, и никакие coffeelint тут не помогают(конечно, можно развести из этого холивар, но я не преследую такую цель, это просто моё мнение).
Вы ничего не путаете? MVC — шаблон проектирования. React может лишь реализовывать(или не реализовывать) этот архитектурный шаблон. И он не реализует его.
Да, мы сохраняем состояния, но не данные. Сохранение данных в состояниях является порочной практикой, я думаю вы должны знать об этом. Соответственно, данные которые должны сохраняться/изменяться в процессе работы с view, будут сохраняться не через React, верно?
Состояния работают по принципу модели, но это не даёт вам права говорить, что это реализация M из MVC.
Что касается статьи — очень достойно, было приятно прочитать.
Спасибо.