Как организовать большое React-приложение и сделать его масштабируемым

[theWaR_13]

Спасибо за статью, очень интересно. Такой вопрос возник. Вот вы написали, что вы группируете компоненты по области действия и у вас есть компонент CartTotal. Через какое-то время приложение выросло и этот же компонент нужно использовать в другом месте. Тут либо перетаскивать компонент в папку shared (папка с общими компонентами для всего приложения), но тогда придется также фиксить пути во всех файлах, где этот компонент используется. Либо же из того самого нового места, никак не связанного с Cart, импортировать CartTotal. И это тоже не очень правильно, ибо между не связанными частями появляется связь. Можно создать еще один такой же компонент, но это совсем неправильно, как мне кажется :)
Не сталкивались ли вы с такой ситуацией? В своих проектах я всегда делю компоненты на dumb components и smart containers, такой проблемы не возникает.

[raveclassic]

Не сталкивались ли вы с такой ситуацией?

Постоянно. Решение — не группировать в модули, иначе либо shared превратится в пышку, либо у вас появится пачка невнятных связующих модулей, либо просто модули будут ссылаться друг на друга.

[SPAHI4]

С перемещением компонента нет никаких проблем. IDE (Webstorm, например), сама меняет все импорты.

[DeLaVega]

PropType depricated в рамках реакта. Он отдельным модулем сейчас должен тянутся.

[seryh]

Не существует единственного правильного пути

Это для меня в свое время оказалось большим недостатком. Когда нужно было быстро стартануть в проект, запутался в огромном количестве статей и советов, один лучше другого. Вся это react мешанина превратилась в конструктор "собери себе свой язык программирования", вот тебе ФП стиль, ООП, реактивный стиль, пот тебе строгая типизация (привет flow) и ворох либ к этому на любой вкус, написанных на 3 стандартах EcmaScript. В итоге быстрей удалось стартануть внезапно в ClojureScript'овском re-frame. Хотя до этого только бекенд на Clojure трогал.

[frol]

У меня была аналогичная ситуация, голова кругом шла от этих всех вариантов. В один прекрасный день появился Next.js и для меня это было идеальное коробочное решение без необходимости первый день проекта начинать с настройки вороха компонент (webpack, babel, react, router, ...) и громоздить тонны boilerplate'ов. Даже вот через полгода мой проект на Next.js в отличной форме, да ещё и Next.js улучшает мой проект с каждым релизом без моего активного вложения времени на изучение техник связанных с горячей перезагрузкой модулей или автоматическим разделением кода по роутам. Рекомендую взять Next.js на вооружение.

[x07]

Это далеко не лучшая особенность.

[Paul_Smith]

Статья отлично помогла освежить и структурировать в голове то, чем давно пользуюсь и убедиться, что я не один считаю это верным путем, спасибо.
Только одно замечание. React — не фреймворк, это библиотека.И именно это и дает такую свободу организации кода.

[unsafePtr]

Если проект не очень большой, или не хочется выделять отдельную папку для импорта общих пакетов, то можно воспользоватся другой секцией — resolve.alias

resolve: {
        alias: {
            "notification": path.resolve(rootDir, "web/notification/SmartNotification.min.js")
        }
}

[Voronar]

Обычно, React-приложение — это SPA. Почему нет советов по организации роут-компонентов? Отдельно хранить их или все в одном файле?

[Voronar]

Или в одном файле, объединяющем несколько роутов по общей функциональной бизнес-сущности?

[VolCh]

Не во всех SPA есть роутинг, не во всех React-SPA с роутингом есть отдельные роут-компоненты, тем более в таком количестве, что нужна какая-то особая организация.

[VolCh]

Придерживаюсь подхода, при котором на первом уровне в src разделяются каталоги по функциональности, один из них (views) — для компонентов (и только для компонентов, ну может каких-то функций типа локализации и/или форматирования) Реакта. Заходишь во views и там всё про рендеринг из props/context компонента App.

[comerc]

Дополню свими изысканиями через боль по теме:

Организация компонентов в проекте

Ducks-pattern + redux-act

Альтернативный заманчивый путь mobx-state-tree

[comerc]

Flow + tcomb заменяет prop-types, прибавляя возможностей.

[comerc]

И странно, что про lerna ни слова.