Только React.js, только хардкор (aka долой Angular и Knockout)!

Последние годы только ленивый не писал о javascript-фреймворках. AngularJS/KnockoutJS/Backbone/Ember — выбирай на вкус :) Но, озадачившись выбором фреймворка для небольшого веб-приложения с год назад, оказалось, что серебряной пули в мире js все еще не придумали.
Backbone и Ember слишком низкоуровневы и многословны, Knockout расстраивает постоянными конвертациями данных в observable, AngularJS.. да, почему бы не попробовать Angular, подумал я тогда. Энгуляр обладал приятным синтаксисом, структура Контроллеров была более менее близка и понятна и всё шло хорошо, пока.. пока мы не уперлись в довольно стандартную для Angular проблему произодительности.

Стэковерфлоу переполнен ответами на тему angular vs. performance, и лучше всего ситуацию проиллюстрируют два ответа: детальнейшее описание работы dirty-checking в Angular, сводящееся к тому, что если на странице у вас меньше 2000 элементов, то всё будет отлично (а уж 2000 элементов должно быть достаточно для каждого!). И следующий за ним контрпример, что в случае больших таблиц 2000 элементов набегают очень быстро.
В нашем случае у нас было много выпадающих списков, вроде таких: 123451 с большим количеством выпадающих элементов, значения которых были привязаны к модели. Заветные 2К элементов набежали очень быстро, и при изменении модели всё нереально тормозило (двух-трехсекундный лаг в браузере нельзя было не заметить).

В тот момент проблему мы решили низкоуровневой «затычкой» — шаблон этого «высоконагруженного» участка начали обрабатывать простейшим шаблонизатором Render.Js‘ом (или mustache‘ом, или handlebars‘ом.. да какая, в общем-то, разница? :)) и все пошло нормально, но осадочек остался…

И вот, наткнувшись на просторах интернета на любопытное видео о клиентском javascript-фреймворке React.JS, разработанный фейсбуком и делающем упор на производительности, я не мог не открыть проектик годовой давности и не попробовать переверстать проблемную область на React.

В процессе перехода React показал себя исключительно хорошо: производительность действительно на отличном уровне. Сказывается то, что «шаблонизатор» у React — это нативный javascript. А html-подобный синтаксис (такой формат у Реакта называется JSX) конвертируется в нативные вызовы при первом обращении (в production же конвертацию, безусловно, следует делать на сервере средствами Node.js).
А вот и пример шаблона в React:

             <div>
                {navigation}
                <div>
                    {activeFilters}
                    <Filters filters1={this.state.filters1} filters2={this.state.filters2} />
                </div>
                <div>
                {this.state.ViewModel.Tree.Items.length <= 0?"No results":this.state.ViewModel.Tree.Items.map(function(item) {
                    return <div class="treeCell">
                                        <a href={'#/' + item.Id}>
                                    <span>{item.Title} <b>[{item.ChildrenCount}]</b>
                                        <br />
                                        <img src="{item.Image}" class="treeCellImage" />
                                    </span>
                                </a>
                            </div>;
                })}
                </div>
            </div>

Выглядит весьма хардкорно, особенно часть, верстающая повторяющиеся элементы:

{this.state.ViewModel.Tree.Items.length <= 0?"No results":this.state.ViewModel.Tree.Items.map(function(item) { [/javascript] Что как-бы еще раз напоминает, JSX - это обычный яваскрипт. Использование виртуального DOM, за счет которого и происходит отслеживание изменений в сгенерированном html, даёт огромный прирост в производительности. Списки с 3000 элементов, которые были камнем преткновения в Angular отработали без малейших проблем. Любопытной задачей при использовании React стало взаимодействие со сторонними контролами (например, jQuery.UI или подобными). Такие контролы веб-разработчики используют каждый день, и без взаимодействия с ними нормальное внедрение js-фреймворка просто немыслимо. В React для подобных взаимодействий напрямую с DOM и сторонними компонентами существуют коллбэки, которые вызываются в случае их объявления в контроле:

• componentDidMount — вызывается по окончании первого успешного рендеринга компонента. К этому моменту DOM полностью сформирован и с ним можно работать.
• componentDidUpdate — вызывается по окончании рендеринга, если свойства (props) или состояние (state) компонента изменилось.

При желании о цикле жизни компонентов Реакта можно прочитать подробнее. В моем маленьком примере интеграция с msDropDown заключалась в объявлении метода:

        componentDidUpdate: function( prevProps,  prevState,  rootNode) {
            $(rootNode).find('select').msDropDown();
        },

Ну и еще один неоспоримый плюс React.JS — простота внедрения и отсутствие необходимости переписывать все веб-приложение целиком, чтобы начать его использовать. Если Энгуляр требует поклонения религии Контроллеров, Роутеров, Скоупа и прочей инъекции зависимостей с первых же минут, то Реакт упирает на выделение возможных вещей в отдельные контролы-компоненты (что видно даже на моем мини-примере), и внедрять такие контрольчики можно с легкостью в уже работающий проект малыми дозами.