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

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

Почему React? Потому, что а) JSX и б) это правильный вариант View (в MVC/MVVM?). По большей части, там вообще нет ничего про модель или контроллер, есть только компоненты. То есть, он не ограничивает вас в выборе реализации контроллера и модели. Почему это правильно? Потому, что в части контроллера, связанной с 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. :)

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