Введение

В прошлом году произошло революционное событие в разработке веб-приложений: компания Facebook выпустила React — библиотеку для создания пользовательских интерфейсов в браузере, использующую радикально отличающийся подход к структурированию кода и написанию графических компонентов. Вместо того, чтобы, имея размётку, «цепляться» к ней из JavaScript, т.е. работать напрямую с DOM, вводится понятие компонента — самодостаточной единицы, которая представляет собой легковесное описание DOM. Когда «реакт» определяет, что необходимо перерисовать что-либо на странице, он рассматривает дельту изменений этого виртуального DOM и перерисовывает только изменённые части. Благодаря тому, что при таком подходе обращение к DOM происходит гораздо реже, возрастает отзывчивость интерфейса и скорость работы: работа JIT не прерывается тяжеловесными обращениями к нативному коду.

React предоставляет возможность сохранения состояния для каждого компонента, при изменении этого состояния он запускает «перерисовку». Таким образом, состояние вашего приложения может оказаться «размазанным» по дереву компонентов. Это не является недостатком React: наоборот, библиотека обеспечивает базовые необходимые блоки и не навязывает лишних правил, когда это возможно. Кто пробовал строить приложение по такой схеме, когда каждый компонент имеет своё изменяемое состояние, рано или поздно столкнулся с возрастающей неуправляемостью кода и сложностью понимания происходящего в приложении. В связи с этим начали появляться библиотеки-надстройки над React, наиболее известной из которых является Om на ClojureScript от David Nolen. Почитать подробнее про Om можно в его блоге.

Каждый React-компонент имеет возможность переопределить метод shouldComponentUpdate, чтобы помочь библиотеке узнать, необходима ли его перерисовка. По умолчанию React возвращает true, и это значит, что «перерисовке» подвергаются все компоненты. Под перерисовкой в данном контексте понимается вызов метода render каждого компонента для построения виртуального DOM, который впоследствии сравнивается с предыдущим значением, после чего перерисовываются в реальном DOM только затронутые части.

В Om был использован централизированный подход к управлению состоянием: оно хранится в ClojureScript атоме на самом верху иерархии компонентов. Дочерние же компоненты получают «указатели» на подразделы этого состояния, которое является иммутабельным значением. Это довольно очевидное решение с точки зрения функционального программирования. Таким образом это позволяет определить метод shouldComponentUpdate так, чтобы он сравнивал текущее состояние с предыдущим с помощью оператора ===, а также хранить всё состояние в одном месте, что значительно упрощает понимание работы приложения.

В компании, в которой я работаю, для проекта было принято решение создать концептуально похожую надстройку над React с нуля и на чистом JavaScript, т.к. использовать ClojureScript не было возможности и желания. Так было положено начало Morearty.js — «more» + «react» + «art» (от названия компании). Читать дальше →