DEV Community

Discussion on: Architecting React Apps Like it's 2030

Collapse
 
ekeijl profile image
Edwin

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?

Collapse
 
mabouhha profile image
боженька-нерд

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?"