SideWest, ну вот видите, сами уже нашли минусы. Ревьювить и причесывать кусок кода можно бесконечно. И вкусы у всех разные. И критерии «качества» кода во многом зависят от команды и соглашений, в этой команде заключённых.
Владимир, а в вашем варианте на cdn компоненты не деплоятся? Должно быть, конденсируются из тумана вокруг серверной стойки.
И что такое основное приложение? При code splitting большого приложения с роутером обычно точка входа — это мизерный кусок js, который асинхронно загружает и рендерит компоненты в зависимости от роута. Где тут основное приложение? Модуль-загрузчик? Или все модули? В конкретном кейсе (нет прав на отображение какого-то роута) некоторые компоненты приложения вообще никогда не будут загружены на клиент.
Владимир, code splitting и инкрементальный деплой.
При code splitting’е в билд будет выпадать не один большой файл, а много маленьких. При деплое подменять изменившиеся файлы и не трогать остальные. Не забыть про кеш.
Athanor, хоть убейте, не понимаю, как ваш информацию из вашего ответа трансформировать в рабочую транспиляцию. если я пройду по ссылке, то обнаружу, что вызывается Babel.transform. окей, что мне сделать, чтобы у меня в браузере появился этот Babel.transform? и что это вообще такое?
если пройдёте по ссылке, которую я оставил в своём ответе, то неожиданно обнаружите секцию Installation, в которой подробно описано, как достичь результата
возвращаясь к вашему первому вопросу "чем это должно быть лучше" – я предоставил конкретный ответ – "возьмите рантайм-транспилятор", вы же предложили посмотреть, поискать, обнаружить, полазать по гитхабу и поискать "как же чуваки это делают". я хз, о чём вы спорите со мной.
Athanor, Я правильно понимаю, вы спрашиваете в чем преимущество использования задокументированного варианта подключения специального инструмента, перед поиском по исходникам и выдёргиванием оттуда каких-то функций? Я даже не знаю, что ответить.
Goshan41k, к моменту, когда ваше решение на хуках с контекстом станет удобным и масштабируемым, вы сами уже напишете свой редакс (на хуках и контексте, да)
только оригинальный редакс оттестирован, а в сети есть тысячи статей про редакс – люди говорят на одном языке одинаковыми терминами. когда вы попытаетесь решить проблему в своём велосипеде, вам понадобится гораздо больше сил и времени.
впрочем – вы вправе решать сами, я подсказываю путь, на котором вы набьёте меньше шишек. я не призываю отказываться от локального скейта, это на самом деле странно. но общий посыл у заметки верный: хотите разобраться "как что работает", хотите набить шишек – пишите велосипед на хуках-контексте или без контекста. хотите написать проект за деньги – берите опробованную архитектуру, в которой вам придётся придумывать меньше всего. набивать шишки полезно. но лучше не делать это за чужие деньги
Goshan41k, не редаксом единым. Есть reatom, effector, mobx — первые два переосмысливают редакс и позволяют писать меньше кода. Последний просто другой.
На редаксе да, так все пишут. Ибо когда у вас появится необходимость расширить код, то проще это сделать, когда логика приложения отделена от логики отображения.
Вот вы добавили все перечисленные фичи. Например, вам нужно показывать уведомление об успешном/неудачном ответе от сервера — в первом случае Вам придётся залезть в код каждого компонента, ответственного за сетевые соединения и изменить его. Во втором у вас будет одна middleware, которая отвечает за сетевые соединения. Потом вам понадобится в четырёх местах использовать данные о юзере — вы будете делать четыре сетевых запроса или просто четыре раза сходите в одно и то же хранилище одним и тем же селектором? Потом вам понадобится, например, выводить туду-элементы, группируя их по юзерам. Туду-элементы запрашиваются компонентом-списком, а юзеры — компонентом-карточкой с юзерами. Продолжать можно бесконечно. Редакс позволяет управлять такой сложностью и не погрязнуть в хитросплетениях компонентов. Логика отдельно, а вьюхи отдельно.
Кроме того, есть redux-toolkit (в доке к редаксу найдёте) — он позволяет писать ГОРАЗДО меньше кода.
