this is a good article, but not enough for large spa (more than 1000 react components) with rich business logic. Previously, I used this approach, and everything turned into a dump. I found the solution in the Feature Sliced Design architecture. I advise those who work on large SPAS to familiarize themselves. feature-sliced.design/en/docs/intro
For business card sites, FSD is overhead.
This looks really good. I tried it a bit today, but I get confused where to place custom hooks and context, I'm not sure if hooks translate really well to this architecture.
From the example repos I deduce that data fetching hooks go in the model segment, UI related hooks in the UI segment.
When using React.Context, I have a Provider at the top level, so that needs to go in the app layer, but the Context can be accessed by lower layers to read the Context so the React.createContext goes in the shared layer?
Yes, all right.
The model segment is your little piece of domain, an aggregate (in DDD terms). Data fetching 100% should be located here.
UI related hooks - yes, they can be put in the ui segment. But first I ask myself the question: "Will there ever be a component in the application in which I can reuse this hook? Is such a component located in another segment? How sure am I?"
If the hook will be used only in one ui segment, it remains in this place.
If I'm not sure, then I move it to the lib segment.
If the hook is 100% reused, then I transfer it to shared/lib.
React.context - also depends on the usage. If you use it in several slices, then /shared. If in one slice, then put it right here. But if there is a need to use multiple slices, it's worth thinking about: "Is it certain that this data cannot be encapsulated in a single entity? Or do I really need a complete set of this data in all places? Will I benefit if I encapsulate context data in multiple entities? Is there anything to gain from encapsulating the context?"
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.
this is a good article, but not enough for large spa (more than 1000 react components) with rich business logic. Previously, I used this approach, and everything turned into a dump. I found the solution in the Feature Sliced Design architecture. I advise those who work on large SPAS to familiarize themselves. feature-sliced.design/en/docs/intro
For business card sites, FSD is overhead.
Thanks for the link you shared! I'm gonna have a look also at it!
This looks really good. I tried it a bit today, but I get confused where to place custom hooks and context, I'm not sure if hooks translate really well to this architecture.
From the example repos I deduce that data fetching hooks go in the model segment, UI related hooks in the UI segment.
When using React.Context, I have a Provider at the top level, so that needs to go in the app layer, but the Context can be accessed by lower layers to read the Context so the React.createContext goes in the shared layer?
Yes, all right.
The model segment is your little piece of domain, an aggregate (in DDD terms). Data fetching 100% should be located here.
UI related hooks - yes, they can be put in the ui segment. But first I ask myself the question: "Will there ever be a component in the application in which I can reuse this hook? Is such a component located in another segment? How sure am I?"
If the hook will be used only in one ui segment, it remains in this place.
If I'm not sure, then I move it to the lib segment.
If the hook is 100% reused, then I transfer it to shared/lib.
React.context - also depends on the usage. If you use it in several slices, then /shared. If in one slice, then put it right here. But if there is a need to use multiple slices, it's worth thinking about: "Is it certain that this data cannot be encapsulated in a single entity? Or do I really need a complete set of this data in all places? Will I benefit if I encapsulate context data in multiple entities? Is there anything to gain from encapsulating the context?"