«Если вам не стыдно за первую версию своего продукта, то вы опоздали с выходом на рынок»
Эти слова оправдывают развитие фронтенда Lingualeo с самого начала, с 2010 года. В сложном многоплатформенном продукте с 5-летней историей код наслоился чуть толще, чем пласты почвы над археологической Трипольской культурой. И вот, этот день настал: мы решили разбежаться и прыгнуть как следует, обновив платформу web-клиента. Ниже мы расскажем, что сделали, чтобы приземлиться как можно дальше от точки отсчета.
Пиарщице, безрассудно пытавшейся зарыться в понимание всего этого, пришлось сказать, что главные технологии, на которых основан фронтенд Lingualeo, — костыли и велосипеды. Надеемся, ей хватит ума не писать это на Хабр.
Шаг первый. Откопать пиарщицу
Фронтенд Lingualeo работает на куче разнообразных библиотек, с кодом, распределенным от тех мест, где грусть-пичаль, до тех мест, где “bleeding edge” — тоже своего рода грусть-пичаль :-D. В стародавние времена на сайте Lingualeo все начиналось с JS-файлов с вкраплениями jQuery. Потом возникла необходимость это разбивать, и появилось некоторое подобие «виджетов», к которым прикрутили глобальную шину событий. Сама система «виджетов» претерпела несколько итераций, пока мы не решили перебраться на так называемый компонентный подход. После некоторых колебаний и поисков мы добавили немного энтропии к суете вокруг React-а.
Шаг второй. Слепить, из того, что было, и немного добавить от себя
Итак, для тех, кто далек от темы и по ссылке выше поленился перейти, сообщаем: React — это JS библиотека для построения пользовательских интерфейсов. К моменту начала наших экспериментов React вышел в версии 0.13. С ним и приступили к работе. Непосредственно с React «подружиться» не удалось по нескольким причинам:
- нам надо было как-то поддерживать и скрещивать предыдущий код и код на React,
- на старте не хотелось отказываться от привычных текстовых шаблонов,
- было интересно копнуть глубже и написать что-нибудь своё,
- наш сборщик (которому тоже много лет) не научился работать с jsx.
Так что решили «обёртку» написать свою, а систему для создания и работы с Virtual DOM использовать готовую:
- https://github.com/Matt-Esch/virtual-dom для построения Virtual DOM и сравнивания его с предыдущим Virtual DOM,
- https://github.com/marcelklehr/vdom-virtualize — для преобразования html в Virtual DOM,
- https://github.com/nthtran/vdom-to-html — для преобразования Virtual DOM в html (думали пригодится, но нет, используем его, в основном, для отладки).
Кстати, мы уже упоминали это в посте о новой тренировке грамматики.
«Обёртку» старались писать с совместимостью по API с React-компонентами, т.е. проходящими тот же самый жизненный цикл со следующими хуками (hooks):
(componentWillMount, componentDidMount, componentWillUnmount,
componentWillUpdate, componentDidUpdate,
componentWillReceiveProps)
Так можно какие-то общие случаи искать, будто мы работаем с React, да и есть задел на более простой переход на React без переписывания всех компонентов.
Шаг третий. Спуститься на землю и вновь полюбить жизнь
Вся эйфория от перехода на задуманный план с Virtual DOM немного притупилась, когда созрел вопрос о том, как же быть с потоком данных и обработкой пользовательских событий. Архитектурный подход Flux показался нам каким-то уж очень абстрактным решением. Написав с его помощью первую версию новой тренировки грамматики, мы попятились и повернули в сторону Redux. Этот подход мы считаем более прямым и лаконичным: единое хранилище данных, наличие middlewares и любимые нами чистенькие функции-handler’ы в качестве обработчиков событий. Но мы были бы не мы, не написав своей прослойки для реализации этого подхода, на что было несколько разных причин. Последние, в основном, упирались в наш сборщик: он не поддерживает ES6, на котором написан Redux.
Redux в представлении разработчиков
Шаг четвертый. Мечтать и воплощать
В итоге мы потихоньку тянемся к светлому будущему, в котором:
- в компонентах минимум бизнес-логики, они просто отражают состояние и слушают события от пользователя;
- вся бизнес-логика (реакция на события) накапливается внутри стора, а точнее, Reducer'a, возвращающего новое состояние стора на основании старого состояния и действия;
- какие-то асинхронные действия выносятся в action creators или даже в middlewares;
- анимация — наш камень преткновения, ужас всех фронтендеров — запихивается в компоненты (в правильности такого подхода уверенность есть не у всех).
На самом деле до сих пор идёт притирка к данному подходу, и не на все вопросы ответы очевидны, как в случае с анимацией, например, но в целом данный подход нам весьма нравится и неплохо облегчает жизнь в тех местах, где он внедрен.
В планах же на будущее — переход на Virtual DOM по всему сайту и внедрение
Кстати, будем весьма признательны хабровчанам за комментарии о том, как они работают с анимацией в React: интересуют сложные случаи, когда происходит несколько взаимодействующих анимаций, либо взаимодействие с компонентом во время анимации). Да и вопрос о том, как осуществлялся переход от одной архитектуры к другой у вас нам тоже интересен ;-)
Искренне ваша фронтенд-команда Lingualeo.
Следите за нашими новостями в Twitter, Facebook, vkontakte и Instagram.
Off topic: Lingualeo ждет в свои ряды разработчиков iOS и Android. О всех открытых вакансиях читайте в блоге на сайте lingualeo.com. Ждем ваши резюме!
