This is a pretty nice way to organise stuff on a top level following a separation of concerns principle.
However, in my experience a similar organisation usually comes more or less naturally and the biggest pain points on large react projects end up being:
How to group independent infrastructure/components files once that folder become too large to manage (too many independent common components).
Similarly, how to structure the presentation layer for larger apps. This part usually follows the projects routing mechanism (i.e. contexts) and then component nesting (i.e. hierarchy), but additional grouping is often needed for complex situations.
Following the previous issue, how much coupling with components/containers can the application folder afford. If it should be avoided then the presentation layer becomes logic heavy, if the opposite is true then you can't reuse anything. As an example, where should a redirect logic be put for a specific successful action (e.g. login) and where should it be put for a common error situation (e.g. 404)?
How to handle, or rather, where to put files that are neither directly presentation or common components (i.e. files that are context specific but reused in different contexts). Imagine having something like an interactive data graph that needs to be repeated as a subcomponent on 3-4 completely different routes, but is always linked to the same API calls and Redux store, should that be in common components or in presentation?
Do you have any rules of thumb or suggestions for these situations within your example architecture?
Thanks for reading article and sharing your suggestions.
I would like to share my thoughts as per my Knowledge.
Each language have multiple paradigm and architecture and all are perfect at their boundary. Every architecture has pros & cons.
Key points is what to pick and it's again depends on your Project Complexity. There is not any thumb rule to go with specific one. I prefer React Clean Architecture what I mention here for Average - Mid Size Project.
For Complex Project I prefer Ignite BoilerPlate - That is most powerful as of now as per my knowledge.
This is a pretty nice way to organise stuff on a top level following a separation of concerns principle.
However, in my experience a similar organisation usually comes more or less naturally and the biggest pain points on large react projects end up being:
infrastructure/componentsfiles once that folder become too large to manage (too many independent common components).presentationlayer for larger apps. This part usually follows the projects routing mechanism (i.e. contexts) and then component nesting (i.e. hierarchy), but additional grouping is often needed for complex situations.applicationfolder afford. If it should be avoided then the presentation layer becomes logic heavy, if the opposite is true then you can't reuse anything. As an example, where should a redirect logic be put for a specific successful action (e.g. login) and where should it be put for a common error situation (e.g. 404)?Do you have any rules of thumb or suggestions for these situations within your example architecture?
Hey Petar,
Thanks for reading article and sharing your suggestions.
I would like to share my thoughts as per my Knowledge.
Each language have multiple paradigm and architecture and all are perfect at their boundary. Every architecture has pros & cons.
Key points is what to pick and it's again depends on your Project Complexity. There is not any thumb rule to go with specific one. I prefer React Clean Architecture what I mention here for Average - Mid Size Project.
For Complex Project I prefer Ignite BoilerPlate - That is most powerful as of now as per my knowledge.
Please checkout Ignite BoilerPlate, You will get all answers for your suggestion - kpiteng.com/blogs/ignite-react-nat...
Thanks Petar for sharing your valuable suggestion, it is adding values to everyone knowledge.
Thanks