Изменения

Почему React

12 065 байтов добавлено, 14:59, 31 августа 2016
м
Нет описания правки
Почему React? Потому, что а) JSX и JSX — это круто б) он легковесный, там есть только компоненты и в) компоненты — это правильный вариант View (в MVC/MVVM?). По большей части, там вообще нет ничего ни про модель или , ни про контроллер, есть только компоненты. То есть, он не ограничивает вас в выборе реализации контроллера и моделиуж конечно там нет никакого DI. Почему И это правильно? Потомупрекрасно, потому что в части контроллера, связанной с View, всегда куча вопросов, начиная с того, при наличии requirejs DI нафиг не нужен ли вообще отдельный контроллер (даже для каждого View? Должен ли он подавать на вход View готовые проецированные данные тестов), а для элементов или полную модель? Должен ли контроллер ставить обработчики событий на элементы View? Отсюда все вариации с ViewModel’ами, ViewController’ами, презентерами реализации контроллеров и так далее. Корочемоделей есть куча прекрасных вариантов, мы все чётко знаемнапример, где начинается View и где начинается Model, а вот как между ними встаёт контроллер — вопрос. React обрубает все эти сомнения, объединяя View со всем, что к нему относится (ViewModel, ViewController) и называя это компонентом. Концепция очень простая реактивные Flux и понятнаяRedux.
Что мне гипотетически не очень нравится в реакте — А почему компонент — это некоторая излишняя «явная иерархичность». Проблема в том, правильное View? Потому что скорость рендера сильно зависит от иерархии компонентовон ставит крест на всех сомнениях, собственносвязанных с тем, чем они мельченужен ли View свой отдельный контроллер, тем лучшедолжен ли он «готовить» данные для View, ибо компонент — должен ли он ставить обработчики событий или это должно делать само View… из которых растут ноги вариаций с ViewModel’ами, ViewController’ами, презентерами и есть минимальная «единица» обновлениятак далее. При обновлении компонентКороче, по сутимы все чётко знаем, перерисовывается целиком с поправкой на Virtual DOM — где начинается View и хоть этогде начинается Model, конечноа вот как между ними встаёт контроллер — вопрос. React обрубает все эти сомнения, быстрееобъединяя View со всем, чем тупо поменять ему весь innerHTML [:что к нему относится (ViewModel, ViewController)]и называя это компонентом. MVVM и MVWhatever резко сдуваются, всё равно нет ничего хорошего а контроллер в томMVC наконец начинает заниматься тем, чтобы обновлять и diff’ать, напримерчем должен — только обработкой «действий», всю таблицу при изменении одной строкиполностью отвязанных от View. Поэтому кроме компонента «таблица» обязательно приходится делать ещё Концепция очень простая и компонент «строка таблицы»понятная. Хотя хз,
В общем-то понятно, откуда всё Что мне гипотетически немного не нравится в реакте — это произрастаетнекоторая излишняя «явная иерархичность». Все новые фреймворкиПроблема в том, по сутичто скорость рендера сильно зависит от иерархии компонентов, в каком-то смысле — JS-шаблонизаторысобственно, решающие задачу динамического чем они мельче, тем лучше, ибо компонент — это и есть минимальная «единица» обновления содержимого страницы при изменении входных данных. AngularПри обновлении компонент, Emberпо сути, Knockout выбрали прямолинейный путь перерисовывается целиком с реализацией собственных языков шаблонов поправкой на Virtual DOM — и привязки их динамических частей к даннымхоть это, а React просто сказал "нафига нам изобретать язык программированияконечно, когда у нас УЖЕ ЕСТЬ язык программирования?!" быстрее, чем тупо поменять ему весь innerHTML [:)], всё равно нет ничего хорошего в том, чтобы обновлять и реализовал шаблонизацию прямо внутри кода на основном языке. Получилось нечтоdiff’ать, немного напоминающее PHP/ASPнапример, только гораздо грамотнеевсю таблицу при изменении одной строки. Поэтому кроме компонента «таблица» обязательно приходится делать ещё и компонент «строка таблицы». Хотя хз, потому что не провоцирует на написание макарошек вместо кодаможет это зато заставляет писать более структурированный код.
В общем-то понятно, откуда всё это произрастает. Все новые фреймворки в каком-то смысле — просто JS-шаблонизаторы на стероидах, решающие задачу динамического обновления содержимого страницы при изменении входных данных. Angular, Ember, Knockout выбрали прямолинейный путь с реализацией собственных языков шаблонов и привязки их динамических частей к данным (каюсь, я сам хотел подобное сделать для своего шаблонизатора), а React просто сказал «нафига нам изобретать язык программирования, когда у нас УЖЕ ЕСТЬ язык программирования?!» и реализовал шаблонизацию прямо внутри кода на основном языке. Получилось нечто, немного напоминающее PHP/ASP, только гораздо грамотнее, потому что используется только во view и поэтому не провоцирует на написание макарошек вместо кода. Понятно, что при таком подходе код шаблонов не особо-то обратишьразберёшь на отдельные биндинги («что поменяется, если…»). Отсюда Virtual DOM и diff'ингdiff’инг, и отсюда же разбиение на мелкие компоненты. Зато сам код шаблонов писать УДОБНО и ПРОСТО. Например, цикл в разных фреймворках выглядит так (пример из [https://medium.freecodecamp.com/angular-2-versus-react-there-will-be-blood-66595faafd51 статьи] с аналогичными рассуждениями):
<pre>
Angular 2: ngFor
Knockout: data-bind="foreach"
React: JUST USE ПРОСТО ИСПОЛЬЗУЙТЕ JS. :)
</pre>
ПравдаКроме того, JSX оценят любители IDE, потому что в нём работает подсветка синтаксиса, подсказки и проверки типов. А вот, кстати, как показывает библиотека Incremental DOM — Virtual DOM не так уж и обязателен, потому что скорость рендера в JS зависит не только от непосредственно количества операций, которые этот рендер делает, а также и от того, как много он гадит в память — чем больше объектов создаётся, тем чаще приходит GC (сборщик мусора) и тем меньше времени остаётся на собственно рендер. В итоге получается, что при быстром рендере и частом GC субъективное ощущение от производительности может быть хуже, чем при чуть более медленном рендере с редким GC. Ещё заметка по поводу скорости других VirtualDOM’ов типа Bobril — многие из них, в отличие от React, не сохраняют вручную добавленные элементы. Небольшая заметка по поводу событий в React: оно по ходу не просто оборачивает события, а зачем-то ставит обработчики на window и само их доставляет… в итоге если поставить глобальный нативный обработчик на document.body и react-овский обработчик на элемент — глобальный обработчик запускается ДО react-овского! (видимо, для производительности) Ещё заметка: React можно юзать с SVG и даже с Canvas. Ну и с React Native, ага. И ещё controlled/uncontrolled inputs. А ещё есть вот такая штука https://facebook.github.io/draft-js/ Минутка юмора nodejs: globParent -> is-glob -> is-extglob ----- А я смотрел. Не штырит :) React выглядит гораздо аккуратнее и красивее архитектурно. Вот соображения по поводу React, очень похожие на мои: https://medium.freecodecamp.com/angular-2-versus-react-there-will-be-blood-66595faafd51 Мне понравилось как они это описали: все ангуляры, эмберы и нокауты, по сути, остались HTML-центричными (расширяют HTML с помощью яваскрипта), а React сделан JS-центричным (расширяет JS HTML’ем). В ангулярах и т. п. шаблон — это отдельный файл на отдельном языке, по сути, строковой литерал. А в React в JSX даже подсказки и проверки типов в IDE работают (!) То есть изначально они же все, по сути, решают одну и ту же задачу — всё это JS-шаблонизаторы на стероидах, которые хотят при изменении входных данных менять вёрстку. Ангуляр и прочие к этой задаче подошли втупую, действительно написав по шаблонизатору, а реакт сказал «нафига нам изобретать язык программирования, когда у нас УЖЕ ЕСТЬ язык программирования?» и просто встроили HTML в яваскрипт. Например, как сделать цикл? <pre>Ember: {{# each}}Angular 1: ng-repeatAngular 2: ngForKnockout: data-bind="foreach"React: ПРОСТО ИСПОЛЬЗУЙТЕ JS :) (обычный for или Array.map())</pre> От синтаксиса шаблонов Angular 2 впечатление у меня вообще плохое. А на JSX оч удобно на самом деле писать и HTML-безопасно. По скорости тоже — Angular2 бесспорно гораздо лучше Angular1 (они его оптимизировали путём «обрубания лишних проводочков» — разделили явно 1-way и 2-way биндинги, большая часть у тебя всегда 1-way, поэтому стало всё сильно быстрее), но реакт он всё равно не делает: https://auth0.com/blog/2016/01/07/more-benchmarks-virtual-dom-vs-angular-12-vs-mithril-js-vs-the-rest/ По некоторым замерам только последние версии Ember.js чуть быстрее React’а, но опять-таки — это только из-за того, что там явно шаблон делится на «статические» и «динамические» части, которые описываются в разном синтаксисе. По инструментарию тоже, подсказок по ВСЕМУ для React куча, поддержка IDE есть (я говорю, даже подсказки в JSX работают), поддержка инструментов разных — server-side rendering (кстати Netflix это юзает именно на React’е), hot reload, отладочный режим и даже профилировка. Даже тот же TypeScript можно юзать с JSX-вставками, если хочется, такое тоже есть. А вот остальные компоненты, которые в Angular есть — ИМХО не особо нужны. DI и прочий мусор отлично берётся из внешних библиотек и есть стандартные решения. Собственно, сейчас вообще-то уже и ангуляровцы пришли к тому, что надо что-то реактивное для архитектуры юзать (store -> view -> action -> dispatcher -> store, строго в одну сторону), в итоге берут RxJS, Angular2+RxJS = 900 килобайт minified. В React же есть отличные Flux и Redux, которые тоже гораздо чище и проще RxJS. Redux = 6.7 Кб minified, RxJS = 150 Кб minified (потому что RxJS — это общая реализация реактивности, которую «натягивают» на архитектуру, а Redux — это именно априори state container). Тот же Redux позволяет очень легко таскать состояние между сервером и клиентом при server-side рендере, делать вариации «undo» и сохранять состояние при hot reload (это когда ты код обновляешь, а у тебя в браузер сама новая версия приложения подтягивается, при этом ОСТАВАЯСЬ НА ТОМ ЖЕ view). Про DI я вообще не уверен, что он там нужен, потому что есть requirejs (через который хоть модуль делай, хоть сервис-синглтон), а для юниттестов есть jest, который эти модули автоматом все на mock’и заменяет. Ну и собственные модули в Angular — тоже непонятно, нафига нужны, когда есть стандартный requirejs. Анимации вообще делаются на CSS. Правда, если хочется, в React тоже для них компоненты есть. Короче, мне в React нравится именно его архитектурная красота, архитектурная красота сопутствующих компонентов типа Redux, и отсутствие лишнего. ----- а почему нода? на ноде всякие прикольные темы можно мутить. асинхрон же. клёво типа. собсно просто пишешь на js и понимаешь, что а нафига нужны все эти python, perl, php, WHATEVER, когда это по сути всё одно и то же и когда яваскрипт по сути покрывает фичи их всех? причём он настолько нахватался фич со всех языков, что часть по-моему чуть не из C# взята. а для упоротых по статической типизации есть даже типизированный typescript (есть и другие язычки поверх яваскрипта, но ts самый живой) — то есть получается, что в принципе js чуть ли не вообще потребности ВСЕХ удовлетворяет ruby какие-то там и т.п… нах всё это надо? и система модулей адекватнее с самого начала и нет идиотских тяжёлых фреймворков, как в пхп — скопипащенных с java (типа Zend == Spring). то есть фреймворки-то есть, просто они сильно поприличнее, не вот это вот г..но а composer php’шный скопипастен с npm.только разница в том, что в npm-то всё ок, а в php-то вся эта нереальная куча говна, поставленная с композера, будет инициализироваться каждый запрос заново, то есть априори будет тормозить. а в js — как в нормальных языках, инициализируется всё один раз…есть конечно phpdaemon (https://github.com/kakserpom/phpdaemon, у чувака емейл кстати как и ник — kak.serpom.po.yaitsam@gmail.com) — но возникает вопрос… а нахуа? если есть nodejs :) и perl ноде тоже проигрывает: система модулей там, конечно, ок, и приложение нормально живёт (не один запрос), но* асинхронщины нет (то есть она в принципе возможна, но никем не реализована)* репутация языка — не всех он удовлетворяет, мол write-only, синтаксис стрёмный* ну и правда уже устарел, почти не развивается, новые проекты на нём никто не пишет, библиотеки тоже потихоньку подгнивать начинают, а некоторые вещи просто никто не будет править, ибо это поломает совместимость python поновее, с асинхронщиной чуть получше (есть twisted), но всё-таки менее популярный и система модулей тоже на костылях (virtualenv), ну и сам язык немного странный, например отступы вместо фигурных скобок — наркоманство [[Категория:Разработка]]