Вопрос: как пользовательские контейнеры Redux и CSS обычно обрабатываются через NPM?
Приведенная ниже структура не работает с традиционными платформами распространения пакетов, такими как NPM, поскольку мне нужно редактировать пользовательские файлы, такие как контейнер Redux и CSS, в разных проектах.
> Component root dir
> Component.js
> Component.css
> Component_container.js
> Component_custom.css
Например:
App.js
=> Component_1_container.js
=> Component_1.js
=> Component_2_container.js
=> Component_2.js
Это здорово, поскольку позволяет мне отделить пользовательский код от общего кода, я могу обновлять Component.js и Component.css во многих проектах, не касаясь кода в пользовательских файлах. Однако пользовательский контейнер и файлы CSS не могут управляться через NPM.
Я легко вижу, как CSS можно извлечь в отдельную папку. Контейнеры Redux сложнее, потому что на них ссылаются другие компоненты как на зависимости, как в приведенной выше структуре. Перемещение их из NPM в другую папку проекта затруднит управление ссылками между компонентами.



![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)


Я думал об очень похожей проблеме, и я думаю, что вы могли бы создать отдельный модуль (независимо от того, модуль npm или просто папку в вашем проекте, помеченный как модуль) с именем ui-kit, и все компоненты будут бесплатно Redux, поскольку клиент эти компоненты могут использовать другой магазин или работать без них.
Кроме того, у вас будет папка component или что-то, что у вас есть сейчас, и ваш компонент высокого уровня (App.js) будет знать только о вашем составная часть, который будет знать о ui-kit
Состав:
app
-> Components (containers)
-> Component.js
-> Component.css
-> ui-kit (Redux free components)
-> Component.js
-> Component.css
App.js (High-level component)
Ссылка на файловую структуру этого проекта: github.com/react-boilerplate/react-boilerplate/tree/master/a pp
Спасибо, это было весьма полезно.
Пройдя через множество руководств и примеров репозиториев, кажется, что лучший подход к этому - иметь всего несколько элементов контейнера, находящихся на более высоком уровне, контролирующих многие связанные компоненты.
Я чувствовал, что для каждого компонента было бы неплохо иметь индивидуальный доступ к магазину с его собственным контейнером, который может меняться от проекта к проекту, но это неуправляемое решение.
Главный вывод здесь состоит в том, что презентационные компоненты никогда не должны вызывать компоненты контейнера в качестве зависимости.
Выделив файлы контейнеров и пользовательских стилей из каталога компонентов, достаточно просто создать компоненты NPM, содержащие только повторно используемый код.
Вопрос в том, сколько контейнеров использовать в приложении. Вот хорошее резюме того, как сгруппировать компоненты по контейнерам, что я нашел полезным при ответе на этот вопрос: http://www.thegreatcodeadventure.com/the-react-plus-redux-container-pattern/
Да, это своего рода потенциальное решение, единственная проблема заключается в том, что компоненты NPM имеют перекрестные зависимости друг от друга, ссылаясь на элементы контейнера других компонентов. Если они расположены где-то еще в вашем проекте, как будут точно указаны ссылки на другие компоненты?