Выбор фреймворка и основные шаги зависят от типа проекта: небольшой(до 3 месяцев) или крупный на несколько лет, от состава команды: есть верстальщик и дизайнер или нет. Основное на что стоит обратить внимание при разработке на react:
1. Самому создавать инфраструктуру для сборки, разработки проекта будет большой ошибкой. Поэтому выбирается наиболее популярный шаблон подходящий под требования из этого списка www.andrewhfarmer.com/starter-project. Если часто приходится делать небольшие проекты, то имеет смысл изучить один раз самый популярный и простой шаблон — create-react-app и везде его использовать.
2. Выбираем способ работы со стором — Redux или Mobx(mobx-state-tree). Redux имеет смысл использовать в сложных проектах и при наличии достаточного кол-ва времени, если хотим иметь четкое понимание работы приложения и возможность на 100% покрыть код тестами. В redux придется либо писать много бойлерплейта, либо изучить много мелких библиотек позволяющих строить более удобную архитектуру. Поэтому я бы сейчас в проект взял Mobx(mobx-state-tree), где уже из коробки есть функционал для нормализации данных в сторе и оптимизации вычисляемых зависимостей.
3. Дальше либо поверх css-фреймворков делаем свои продвинутые компоненты, работающие со стором, либо берем готовые из тех же ExtReact, DevExpress и пр. Обычно в приложении нужна малая часть того функционала, что реализована в таких монстрах как Ext JS, и бывает проще написать свой компонент с базовым функционалом и постепенно его допиливать, чем пытаться на Ext JS сделать что-то нестандартное.
Сделать канбан доску можно в течении 1 дня при наличии опыта в технологиях.
Времена Ext JS прошли. Современный тренд в веб-разработке — уход от грязных, ручных DOM-манипуляций и переход на декларативный способ построения интерфейса. Ext JS позволяет только поверхностно декларировать поведение своих компонентов, но когда нужно сделать сложный и оптимизированный компонент, начинается беготня по DOM, по дереву компонентов Ext JS и большим колстекам при генерации событий.
В React, Vue разработчик может полностью сосредоточится на работе со стейтом приложения, делегировав всю грязную работу с DOM самой библиотеке. Похоже в Sencha это и сами осознают и сделали версию под React — ExtReact.
По поводу велосипедов, opensource развивается очень активно, полно решений и для работы с формами и для построения гридов и для грамотной организации стора. Все вопросы гуглятся очень быстро, обучающих материалов хватает с избытком.
В примере с redux для мутаций используются spread-ы. Они достаточно медленные по сравнению с мутациями в immutable js, и годятся только для небольших проектов. Да и читаемость мутаций в immutable лучше:
Описанные проблемы успешно решаются с помощью нормализации данных. Перед тем как ложить данные в store, они разбиваются на мелкие сущности с помощью normalizr, и дальше универсальным редьюсером добавлются в стор. Если нужно отобразить объект в компоненте, то он денормализуется с помощью denormalize в каком-нибудь селекторе. При редактировании объекта лучше использовать нормализованную форму.
Плюс Mobx что там такой функционал уже есть из коробки в mobx-state-tree.
Столкнулся с похожей проблемой, когда имеется несколько крупных Container-ов, бизнес хочет с десяток копий с разным поведением, но рука не поднимается дублировать столько кода и ставить крест на проекте.
DI удобная вещь, но если используется redux подход используемый в redux-form мне кажется более логичным. Идея в том что Container, обернутый в connect, вместе со стилями css-in-js, prop-types и селекторами оборачивается еще одним HOC вида createMyAwesomeComponent. В итоге получается функция-конструктор, формирующая с помощью параметров произвольное поведение самого Container и его дочерних Presentationals.
В такой конструктор можно на вход подать кастомные селекторы, которые прогонят через требуемую логику данные из store. Можно в виде параметров передавать мелкие кастомизированные компоненты, чтобы не перегружать сигнатуру конструктора. В store для каждого инстанса Container создается свой state, и соответственно в экшенах в разделе meta указывается имя инстанса.
Если нужна кастомизация side effects, например тулбар с другими кнопками, то проще для тулбара создать отдельный Container и передать его в качестве параметра в основной Container.
1. Самому создавать инфраструктуру для сборки, разработки проекта будет большой ошибкой. Поэтому выбирается наиболее популярный шаблон подходящий под требования из этого списка www.andrewhfarmer.com/starter-project. Если часто приходится делать небольшие проекты, то имеет смысл изучить один раз самый популярный и простой шаблон — create-react-app и везде его использовать.
2. Выбираем способ работы со стором — Redux или Mobx(mobx-state-tree). Redux имеет смысл использовать в сложных проектах и при наличии достаточного кол-ва времени, если хотим иметь четкое понимание работы приложения и возможность на 100% покрыть код тестами. В redux придется либо писать много бойлерплейта, либо изучить много мелких библиотек позволяющих строить более удобную архитектуру. Поэтому я бы сейчас в проект взял Mobx(mobx-state-tree), где уже из коробки есть функционал для нормализации данных в сторе и оптимизации вычисляемых зависимостей.
3. Дальше либо поверх css-фреймворков делаем свои продвинутые компоненты, работающие со стором, либо берем готовые из тех же ExtReact, DevExpress и пр. Обычно в приложении нужна малая часть того функционала, что реализована в таких монстрах как Ext JS, и бывает проще написать свой компонент с базовым функционалом и постепенно его допиливать, чем пытаться на Ext JS сделать что-то нестандартное.
Сделать канбан доску можно в течении 1 дня при наличии опыта в технологиях.
В React, Vue разработчик может полностью сосредоточится на работе со стейтом приложения, делегировав всю грязную работу с DOM самой библиотеке. Похоже в Sencha это и сами осознают и сделали версию под React — ExtReact.
По поводу велосипедов, opensource развивается очень активно, полно решений и для работы с формами и для построения гридов и для грамотной организации стора. Все вопросы гуглятся очень быстро, обучающих материалов хватает с избытком.
Мемоизация селекторов вряд ли поможет, т.к. в них нету тяжелых расчетов.
Плюс Mobx что там такой функционал уже есть из коробки в mobx-state-tree.
DI удобная вещь, но если используется redux подход используемый в redux-form мне кажется более логичным. Идея в том что Container, обернутый в connect, вместе со стилями css-in-js, prop-types и селекторами оборачивается еще одним HOC вида createMyAwesomeComponent. В итоге получается функция-конструктор, формирующая с помощью параметров произвольное поведение самого Container и его дочерних Presentationals.
В такой конструктор можно на вход подать кастомные селекторы, которые прогонят через требуемую логику данные из store. Можно в виде параметров передавать мелкие кастомизированные компоненты, чтобы не перегружать сигнатуру конструктора. В store для каждого инстанса Container создается свой state, и соответственно в экшенах в разделе meta указывается имя инстанса.
Если нужна кастомизация side effects, например тулбар с другими кнопками, то проще для тулбара создать отдельный Container и передать его в качестве параметра в основной Container.