Comments 5
Таким способом мы помогли заказчику избежать переписывания проекта с нуля, улучшили архитектуру имеющегося решения и сделали приложение быстрее.
Со стороны кажется наоборот, вы заказчика развели на деньги.
- вместо CRA - потратили кучу времени и создали ваш кастомный монстро-вебпак-конфиг. Таким образом "прявязали" заказчика к себе.. либо же ему в будущем нужно будет искать сеньйор-вебпак-конфигураторов.
- вместо одной зависимости mobx - взяли сборную солянку зависимостей redux, redux-observable, rxjs, immer, reselect и удтверждаете что сделали быстрее.
вместо одной зависимости mobx - взяли сборную солянку зависимостей redux, redux-observable, rxjs, immer, reselect
Думаю, автор указал этот стейт-менеджер чисто в качестве примера для мануала - redux можно заменить на mobx, effector и т.д. и т.п., суть-то о гибкой настройке процессов сборки и деплоя react-приложения (как я понял)
вместо CRA - потратили кучу времени и создали ваш кастомный монстро-вебпак-конфиг
А не будет ссылки на такой же подробный мануал, но для настройки в рамках CRA? Спрашиваю без негатива, чисто из желания узнать о данном сборщике побольше, буду благодарен за наводку)
Спасибо за комментарий. CRA не дает такой гибкости в вопросе оптимизации сборки приложения, как кастомная настройка webpack. В нашей статье мы подчеркивали, что такая конфигурация нацелена на оптимизацию крупных сложных приложений.
Redux в данном кейсе был обязательным требованием заказчика в силу его большей популярности. Сравнить его с mobx можно здесь.
Как верно подметил @DmOsinkin, выбор библиотек - не ключевая мысль данной статьи. Здесь речь идет о гибкой настройке сборки приложения и её оптимизации.
Можно пожалуйста ссылку на репозиторий данной статьи ? :)
Хотелось бы посмотреть исходники, дайте пожалуйста ссылку)
Развертывание React-приложения