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