Почему React — различия между версиями
м |
м |
||
| Строка 1: | Строка 1: | ||
Почему React? Потому, что это правильный вариант View (в MVC/MVVM?). По большей части, там вообще нет ничего про модель или контроллер, есть только компоненты. То есть, он не ограничивает вас в выборе реализации контроллера и модели. Почему это правильно? Потому, что в части контроллера, связанной с View, всегда куча вопросов, начиная с того, нужен ли вообще отдельный контроллер для каждого View? Должен ли он подавать на вход View готовые проецированные данные для элементов или полную модель? Должен ли контроллер ставить обработчики событий на элементы View? Отсюда все вариации с ViewModel’ами, ViewController’ами, презентерами и так далее. Короче, мы все чётко знаем, где начинается View и где начинается Model, а вот как между ними встаёт контроллер — вопрос. React обрубает все эти сомнения, объединяя View со всем, что к нему относится (ViewModel, ViewController) и называя это компонентом. Концепция очень простая и понятная. | Почему React? Потому, что это правильный вариант View (в MVC/MVVM?). По большей части, там вообще нет ничего про модель или контроллер, есть только компоненты. То есть, он не ограничивает вас в выборе реализации контроллера и модели. Почему это правильно? Потому, что в части контроллера, связанной с View, всегда куча вопросов, начиная с того, нужен ли вообще отдельный контроллер для каждого View? Должен ли он подавать на вход View готовые проецированные данные для элементов или полную модель? Должен ли контроллер ставить обработчики событий на элементы View? Отсюда все вариации с ViewModel’ами, ViewController’ами, презентерами и так далее. Короче, мы все чётко знаем, где начинается View и где начинается Model, а вот как между ними встаёт контроллер — вопрос. React обрубает все эти сомнения, объединяя View со всем, что к нему относится (ViewModel, ViewController) и называя это компонентом. Концепция очень простая и понятная. | ||
| − | Что мне гипотетически не очень нравится в реакте — это некоторая излишняя «явная иерархичность». Проблема в том, что скорость рендера сильно зависит от иерархии компонентов, собственно, чем они мельче, тем лучше, ибо компонент — это и есть минимальная «единица» обновления. При обновлении компонент, по сути, перерисовывается целиком с поправкой на Virtual DOM — и хоть это, конечно, быстрее, чем | + | Что мне гипотетически не очень нравится в реакте — это некоторая излишняя «явная иерархичность». Проблема в том, что скорость рендера сильно зависит от иерархии компонентов, собственно, чем они мельче, тем лучше, ибо компонент — это и есть минимальная «единица» обновления. При обновлении компонент, по сути, перерисовывается целиком с поправкой на Virtual DOM — и хоть это, конечно, быстрее, чем тупо поменять ему весь innerHTML [:)], всё равно нет ничего хорошего в том, чтобы обновлять и diff’ать, например, всю таблицу при изменении одной строки. Поэтому кроме компонента «таблица» обязательно приходится делать ещё и компонент «строка таблицы». |
В общем-то понятно, откуда всё это произрастает. Все новые фреймворки, по сути, в каком-то смысле — JS-шаблонизаторы, решающие задачу динамического обновления содержимого страницы при изменении входных данных. Angular выбрал прямолинейный путь с реализацией языка шаблонов и привязки их динамических частей к данным, а React выбрал нечто похожее на путь PHP/ASP, реализовав шаблонизацию прямо внутри кода на основном языке (ну и, конечно, пограмотнее самого PHP/ASP). Понятно, что при таком подходе не особо «влезешь» в структуру кодогенерации, отсюда и Virtual DOM, и разбиение на мелкие компоненты. Зато сам код шаблонов писать удобно. | В общем-то понятно, откуда всё это произрастает. Все новые фреймворки, по сути, в каком-то смысле — JS-шаблонизаторы, решающие задачу динамического обновления содержимого страницы при изменении входных данных. Angular выбрал прямолинейный путь с реализацией языка шаблонов и привязки их динамических частей к данным, а React выбрал нечто похожее на путь PHP/ASP, реализовав шаблонизацию прямо внутри кода на основном языке (ну и, конечно, пограмотнее самого PHP/ASP). Понятно, что при таком подходе не особо «влезешь» в структуру кодогенерации, отсюда и Virtual DOM, и разбиение на мелкие компоненты. Зато сам код шаблонов писать удобно. | ||
| + | |||
| + | Правда, как показывает библиотека Incremental DOM — Virtual DOM не так уж и обязателен, потому что скорость рендера в JS зависит не только от непосредственно количества операций, которые этот рендер делает, а также и от того, как много он гадит в память — чем больше объектов создаётся, тем чаще приходит GC (сборщик мусора) и тем меньше времени остаётся на собственно рендер. В итоге получается, что при быстром рендере и частом GC субъективное ощущение от производительности может быть хуже, чем при чуть более медленном рендере с редким GC. | ||
Версия 01:18, 20 июня 2016
Почему React? Потому, что это правильный вариант View (в MVC/MVVM?). По большей части, там вообще нет ничего про модель или контроллер, есть только компоненты. То есть, он не ограничивает вас в выборе реализации контроллера и модели. Почему это правильно? Потому, что в части контроллера, связанной с View, всегда куча вопросов, начиная с того, нужен ли вообще отдельный контроллер для каждого View? Должен ли он подавать на вход View готовые проецированные данные для элементов или полную модель? Должен ли контроллер ставить обработчики событий на элементы View? Отсюда все вариации с ViewModel’ами, ViewController’ами, презентерами и так далее. Короче, мы все чётко знаем, где начинается View и где начинается Model, а вот как между ними встаёт контроллер — вопрос. React обрубает все эти сомнения, объединяя View со всем, что к нему относится (ViewModel, ViewController) и называя это компонентом. Концепция очень простая и понятная.
Что мне гипотетически не очень нравится в реакте — это некоторая излишняя «явная иерархичность». Проблема в том, что скорость рендера сильно зависит от иерархии компонентов, собственно, чем они мельче, тем лучше, ибо компонент — это и есть минимальная «единица» обновления. При обновлении компонент, по сути, перерисовывается целиком с поправкой на Virtual DOM — и хоть это, конечно, быстрее, чем тупо поменять ему весь innerHTML [:)], всё равно нет ничего хорошего в том, чтобы обновлять и diff’ать, например, всю таблицу при изменении одной строки. Поэтому кроме компонента «таблица» обязательно приходится делать ещё и компонент «строка таблицы».
В общем-то понятно, откуда всё это произрастает. Все новые фреймворки, по сути, в каком-то смысле — JS-шаблонизаторы, решающие задачу динамического обновления содержимого страницы при изменении входных данных. Angular выбрал прямолинейный путь с реализацией языка шаблонов и привязки их динамических частей к данным, а React выбрал нечто похожее на путь PHP/ASP, реализовав шаблонизацию прямо внутри кода на основном языке (ну и, конечно, пограмотнее самого PHP/ASP). Понятно, что при таком подходе не особо «влезешь» в структуру кодогенерации, отсюда и Virtual DOM, и разбиение на мелкие компоненты. Зато сам код шаблонов писать удобно.
Правда, как показывает библиотека Incremental DOM — Virtual DOM не так уж и обязателен, потому что скорость рендера в JS зависит не только от непосредственно количества операций, которые этот рендер делает, а также и от того, как много он гадит в память — чем больше объектов создаётся, тем чаще приходит GC (сборщик мусора) и тем меньше времени остаётся на собственно рендер. В итоге получается, что при быстром рендере и частом GC субъективное ощущение от производительности может быть хуже, чем при чуть более медленном рендере с редким GC.
