I don't know about your state management or tech stack but this is the approach we took for a really big react-redux application: dev.to/jovidecroock/modular-redux-...
Essentially when evaluating an approach you have to aim at achieving a good level of cohesion and close to no coupling between modules (except your normal commons like your Button abstraction,...).
Logical cohesion is what we strived for in the article I mentioned earlier, at the moment we group everything for example like this:
Our project has objective so we have a folder "project" with a few submodules and one of those is objectives.
This makes it so that we can lazy load modules and their data requirements, this also implies that for example an npm module we only use in module x won't be required initially until we load in module x.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't know about your state management or tech stack but this is the approach we took for a really big react-redux application: dev.to/jovidecroock/modular-redux-...
Essentially when evaluating an approach you have to aim at achieving a good level of cohesion and close to no coupling between modules (except your normal commons like your Button abstraction,...).
Logical cohesion is what we strived for in the article I mentioned earlier, at the moment we group everything for example like this:
Our project has objective so we have a folder "project" with a few submodules and one of those is objectives.
This makes it so that we can lazy load modules and their data requirements, this also implies that for example an npm module we only use in module x won't be required initially until we load in module x.