Почему React — различия между версиями

Материал из YourcmcWiki
Перейти к: навигация, поиск
м
м
Строка 1: Строка 1:
Почему React? Потому, что а) JSX и б) это правильный вариант View (в MVC/MVVM?). По большей части, там вообще нет ничего про модель или контроллер, есть только компоненты. То есть, он не ограничивает вас в выборе реализации контроллера и модели. Почему это правильно? Потому, что в части контроллера, связанной с View, всегда куча вопросов, начиная с того, нужен ли вообще отдельный контроллер для каждого View? Должен ли он подавать на вход View готовые проецированные данные для элементов или полную модель? Должен ли контроллер ставить обработчики событий на элементы View? Отсюда все вариации с ViewModel’ами, ViewController’ами, презентерами и так далее. Короче, мы все чётко знаем, где начинается View и где начинается Model, а вот как между ними встаёт контроллер — вопрос. React обрубает все эти сомнения, объединяя View со всем, что к нему относится (ViewModel, ViewController) и называя это компонентом. Концепция очень простая и понятная.
+
Почему React? Потому, что а) JSX — это круто б) он легковесный, там есть только компоненты и в) компоненты — это правильный вариант View в MVC/MVVM. По большей части, там вообще нет ничего ни про модель, ни про контроллер, и уж конечно там нет никакого DI. И это прекрасно, потому что при наличии requirejs DI нафиг не нужен (даже для тестов), а для реализации контроллеров и моделей есть куча прекрасных вариантов, например, реактивные Flux и Redux.
  
Что мне гипотетически не очень нравится в реакте — это некоторая излишняя «явная иерархичность». Проблема в том, что скорость рендера сильно зависит от иерархии компонентов, собственно, чем они мельче, тем лучше, ибо компонент — это и есть минимальная «единица» обновления. При обновлении компонент, по сути, перерисовывается целиком с поправкой на Virtual DOM — и хоть это, конечно, быстрее, чем тупо поменять ему весь innerHTML [:)], всё равно нет ничего хорошего в том, чтобы обновлять и diff’ать, например, всю таблицу при изменении одной строки. Поэтому кроме компонента «таблица» обязательно приходится делать ещё и компонент «строка таблицы». Хотя хз,
+
А почему компонент — это правильное View? Потому что он ставит крест на всех сомнениях, связанных с тем, нужен ли View свой отдельный контроллер, должен ли он «готовить» данные для View, должен ли он ставить обработчики событий или это должно делать само View… из которых растут ноги вариаций с ViewModel’ами, ViewController’ами, презентерами и так далее. Короче, мы все чётко знаем, где начинается View и где начинается Model, а вот как между ними встаёт контроллер — вопрос. React обрубает все эти сомнения, объединяя View со всем, что к нему относится (ViewModel, ViewController) и называя это компонентом. Концепция очень простая и понятная.
  
В общем-то понятно, откуда всё это произрастает. Все новые фреймворки, по сути, в каком-то смысле — JS-шаблонизаторы, решающие задачу динамического обновления содержимого страницы при изменении входных данных. Angular, Ember, Knockout выбрали прямолинейный путь с реализацией собственных языков шаблонов и привязки их динамических частей к данным, а React просто сказал "нафига нам изобретать язык программирования, когда у нас УЖЕ ЕСТЬ язык программирования?!" и реализовал шаблонизацию прямо внутри кода на основном языке. Получилось нечто, немного напоминающее PHP/ASP, только гораздо грамотнее, потому что не провоцирует на написание макарошек вместо кода.
+
Что мне гипотетически немного не нравится в реакте — это некоторая излишняя «явная иерархичность». Проблема в том, что скорость рендера сильно зависит от иерархии компонентов, собственно, чем они мельче, тем лучше, ибо компонент — это и есть минимальная «единица» обновления. При обновлении компонент, по сути, перерисовывается целиком с поправкой на Virtual DOM — и хоть это, конечно, быстрее, чем тупо поменять ему весь innerHTML [:)], всё равно нет ничего хорошего в том, чтобы обновлять и diff’ать, например, всю таблицу при изменении одной строки. Поэтому кроме компонента «таблица» обязательно приходится делать ещё и компонент «строка таблицы». Хотя хз, может это зато заставляет писать более структурированный код.
  
Понятно, что при таком подходе код шаблонов не особо-то обратишь. Отсюда Virtual DOM и diff'инг, и отсюда же разбиение на мелкие компоненты. Зато сам код шаблонов писать УДОБНО и ПРОСТО. Например, цикл в разных фреймворках выглядит так (пример из [https://medium.freecodecamp.com/angular-2-versus-react-there-will-be-blood-66595faafd51 статьи] с аналогичными рассуждениями):
+
В общем-то понятно, откуда всё это произрастает. Все новые фреймворки, по сути, в каком-то смысле — JS-шаблонизаторы, решающие задачу динамического обновления содержимого страницы при изменении входных данных. Angular, Ember, Knockout выбрали прямолинейный путь с реализацией собственных языков шаблонов и привязки их динамических частей к данным, а React просто сказал «нафига нам изобретать язык программирования, когда у нас УЖЕ ЕСТЬ язык программирования?!» и реализовал шаблонизацию прямо внутри кода на основном языке. Получилось нечто, немного напоминающее PHP/ASP, только гораздо грамотнее, потому что не провоцирует на написание макарошек вместо кода.
 +
 
 +
Понятно, что при таком подходе код шаблонов не особо-то обратишь. Отсюда Virtual DOM и diff’инг, и отсюда же разбиение на мелкие компоненты. Зато сам код шаблонов писать УДОБНО и ПРОСТО. Например, цикл в разных фреймворках выглядит так (пример из [https://medium.freecodecamp.com/angular-2-versus-react-there-will-be-blood-66595faafd51 статьи] с аналогичными рассуждениями):
  
 
<pre>
 
<pre>
Строка 15: Строка 17:
 
</pre>
 
</pre>
  
Правда, как показывает библиотека Incremental DOM — Virtual DOM не так уж и обязателен, потому что скорость рендера в JS зависит не только от непосредственно количества операций, которые этот рендер делает, а также и от того, как много он гадит в память — чем больше объектов создаётся, тем чаще приходит GC (сборщик мусора) и тем меньше времени остаётся на собственно рендер. В итоге получается, что при быстром рендере и частом GC субъективное ощущение от производительности может быть хуже, чем при чуть более медленном рендере с редким GC.
+
Кроме того, JSX оценят любители IDE, потому что в нём работает подсветка синтаксиса, подсказки и проверки типов.
 +
 
 +
А вот, кстати, как показывает библиотека Incremental DOM — Virtual DOM не так уж и обязателен, потому что скорость рендера в JS зависит не только от непосредственно количества операций, которые этот рендер делает, а также и от того, как много он гадит в память — чем больше объектов создаётся, тем чаще приходит GC (сборщик мусора) и тем меньше времени остаётся на собственно рендер. В итоге получается, что при быстром рендере и частом GC субъективное ощущение от производительности может быть хуже, чем при чуть более медленном рендере с редким GC.

Версия 01:38, 20 июня 2016

Почему React? Потому, что а) JSX — это круто б) он легковесный, там есть только компоненты и в) компоненты — это правильный вариант View в MVC/MVVM. По большей части, там вообще нет ничего ни про модель, ни про контроллер, и уж конечно там нет никакого DI. И это прекрасно, потому что при наличии requirejs DI нафиг не нужен (даже для тестов), а для реализации контроллеров и моделей есть куча прекрасных вариантов, например, реактивные Flux и Redux.

А почему компонент — это правильное View? Потому что он ставит крест на всех сомнениях, связанных с тем, нужен ли View свой отдельный контроллер, должен ли он «готовить» данные для View, должен ли он ставить обработчики событий или это должно делать само View… из которых растут ноги вариаций с ViewModel’ами, ViewController’ами, презентерами и так далее. Короче, мы все чётко знаем, где начинается View и где начинается Model, а вот как между ними встаёт контроллер — вопрос. React обрубает все эти сомнения, объединяя View со всем, что к нему относится (ViewModel, ViewController) и называя это компонентом. Концепция очень простая и понятная.

Что мне гипотетически немного не нравится в реакте — это некоторая излишняя «явная иерархичность». Проблема в том, что скорость рендера сильно зависит от иерархии компонентов, собственно, чем они мельче, тем лучше, ибо компонент — это и есть минимальная «единица» обновления. При обновлении компонент, по сути, перерисовывается целиком с поправкой на Virtual DOM — и хоть это, конечно, быстрее, чем тупо поменять ему весь innerHTML [:)], всё равно нет ничего хорошего в том, чтобы обновлять и diff’ать, например, всю таблицу при изменении одной строки. Поэтому кроме компонента «таблица» обязательно приходится делать ещё и компонент «строка таблицы». Хотя хз, может это зато заставляет писать более структурированный код.

В общем-то понятно, откуда всё это произрастает. Все новые фреймворки, по сути, в каком-то смысле — JS-шаблонизаторы, решающие задачу динамического обновления содержимого страницы при изменении входных данных. Angular, Ember, Knockout выбрали прямолинейный путь с реализацией собственных языков шаблонов и привязки их динамических частей к данным, а React просто сказал «нафига нам изобретать язык программирования, когда у нас УЖЕ ЕСТЬ язык программирования?!» и реализовал шаблонизацию прямо внутри кода на основном языке. Получилось нечто, немного напоминающее PHP/ASP, только гораздо грамотнее, потому что не провоцирует на написание макарошек вместо кода.

Понятно, что при таком подходе код шаблонов не особо-то обратишь. Отсюда Virtual DOM и diff’инг, и отсюда же разбиение на мелкие компоненты. Зато сам код шаблонов писать УДОБНО и ПРОСТО. Например, цикл в разных фреймворках выглядит так (пример из статьи с аналогичными рассуждениями):

Ember: {{# each}}
Angular 1: ng-repeat
Angular 2: ngFor
Knockout: data-bind="foreach"
React: JUST USE JS. :)

Кроме того, JSX оценят любители IDE, потому что в нём работает подсветка синтаксиса, подсказки и проверки типов.

А вот, кстати, как показывает библиотека Incremental DOM — Virtual DOM не так уж и обязателен, потому что скорость рендера в JS зависит не только от непосредственно количества операций, которые этот рендер делает, а также и от того, как много он гадит в память — чем больше объектов создаётся, тем чаще приходит GC (сборщик мусора) и тем меньше времени остаётся на собственно рендер. В итоге получается, что при быстром рендере и частом GC субъективное ощущение от производительности может быть хуже, чем при чуть более медленном рендере с редким GC.