Личный кабинет
Архитектурный вопрос
Good Parts
Pre-written code
Большое количество кода специфичного для проектов 2GIS и наших стандартов разработки browser приложений.
Gulp, библиотеки для работы с картой, общие инструменты для работы с Front End'ом, SVG, Less итд...
Good Parts
AppState
Архитектура для работы с History API, и доставка изменений в систему модулей.
Good Parts
Архитектура из коробки
Сервер, сборка, правила для разработки. Большая экономия времени на стартовом этапе.
Bad Parts
Архитектура данных
Большая часть обработки данных размазана между modules-components-helpers в зависимости от удобств разработчика.
Все данные silent (молчаливые) и не сообщают о изменениях централизованно. Все обновления данных проходят в ручном режиме.
Bad Parts
Недостаточная докумнетация
Не редко приходится уточнять различные вопросы у разработчиков фреймворка, либо у людей с богатым опытом использования.
Bad Parts
Избыточный ручной контроль
Многие вещи приходится делать руками, создание модулей, прокидывание данных из родительских компонентов дочерним,
вывоз функции slot.rerender(). В некоторых случаях это помогает, а в некоторых это слишком избыточно и можно было бы отдать на отработку фреймворку.
Bad Parts
Проблемы в инструментах
Так как многие инструменты писались исключительно под проект 2GIS.RU, не были учтены некоторые особенности. Яркий пример тому reqwest/request который в версии слота очень плохо работает с post/put/delete запросами. В некоторых случаях придется переписывать для комфортного использования.
Новая концепция: DDA
Data Driven Application
Data Driven Application
Часть 1: Фундамент
AppState 2.0
Старая схема:
Data Driven Application
Часть 1: Фундамент
Что делать если URL
покрывает только 10%-20%
реальных действий пользователя?
Data Driven Application
Часть 1: Фундамент
Новый подход
Data Driven Application
Часть 1: Фундамент
Новый подход (технически)
AppState это персистентная структура данных Map. Переход между состояниями называется State Patching. Разница между состоянием 1 и 2 это Patch.
Действие направленное на изменение структуры именуется commit'ом. Каждый patch записывается в stateHistory. Источники изменений для AppState называются Providers. Восстановленное состояние называется InitialState. Каждый patch имеет hash представление.
Data Driven Application
Часть 1: Фундамент
Потенциальные сложности
- Очистка состояния от User Action's
- Сложный Patch'инг в некоторых случаях
- Наличие большого количества кода в AppState
Data Driven Application
Часть 1: Фундамент
Концепция AppState 2.0
очень похожа на VCS GIT
Data Driven Application
Часть 1: Фундамент
References
http://jsonpatch.com/
https://github.com/elierotenberg/remutable
https://github.com/intelie/immutable-js-diff
https://github.com/intelie/immutable-js-patch
Data Driven Application
Часть 2: Стены
Flux Stores
Data Driven Application
Часть 2: Стены
Flux Stores
1 состоянию AppState соответствует 1 состояние данных этого приложения. После изменения состояния, данные должны синхронизоватся.
Все данные приложения можно разделить на 3 уровня: AppState, Model, Specific Model.
Data Driven Application
Часть 2: Стены
Flux Stores
Основным условием для поддерживаемой архитектуры должно служить следующее правило:
Структура данных может подписаться только на структуру которая на 1 приоритет выше чем она.
AppState - 1 // Model - 2 // Specific Model - 3
Data Driven Application
Часть 2: Стены
Тонкие моменты
Внешнее воздействие на структуру данных должно менять appState, но к appStat'у имеет доступ только stateProvider, нужно понять как поступать в таких случаях (например web sockets или polling).
Нужно внимательно следить за доставкой событий change.
Data Driven Application
Часть 3: Интерьер
Web Components
Web Components
Кандидаты
Data Driven Application
Часть 3: Интерьер
Плюсы
Хорошая документация
Большое коммьюнити
Хорошо ложится на Flux
Есть завязка на state
Минусы
Скудная изоморфность
У команды нет опыта в нем
Быстро не перепишем
Свой шаблонизатор
Непонятно
Быстро ли писать на нем?
На сколько хорош Virtual DOM?
Data Driven Application
Часть 3: Интерьер
Плюсы
Хорошая документация
Быстрая разработка
Хорошо ложится на Flux
Минусы
Нет изоморфности
У команды малый опыт
Очень мало ручного контроля
Непонятно
Сможем ли быстро мигрировать?
Сможем ли быстро развернуть архитектуру под это решение?
Data Driven Application
Часть 3: Интерьер
Плюсы
Хорошая документация
Flux из коробки
Изморфность из коробки
Минусы
Небольшое коммьюнити
В некоторых местах мало ручного контроля
Есть правила о которых нужно помнить
Handlebars из коробки
Есть возможность быстро мигрировать
Data Driven Application
Часть 4: Плюшки
deck
By Kirill Kaysarov
