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.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.