architecture and boundaries on React apps

Software architecture needs boundaries. But what does it mean?

Well. It means that when you have many things in your app - multiple classes, multiple modules etc. you don't want them to depend freely on each other:

But you want something more similar to this:

Notice that on both images there are 6 boxes. On the second image though we have clear boundaries of which modules can communicate with which other modules:

So basically you could say that I drew aggregates and aggregates roots from DDD(Domain Driven Design), but I think this approach is not limited to DDD. You don't need to practice full blown DDD to create such boundaries in your project. You could similar approach e.g. for separating groups of React components.

But what boundaries mean in React app?

State - if you're lifting state up, you lift only to the boundary of subtree

Props - if you make prop drilling, you limit this practice to boundary of "aggregate"

Context - you limit use of given context to "aggregate" (though it can be slightly more complex than that).

Events - you create event handlers in limits of aggregate (and pass them only to aggregate roots)

How we could interpret "aggregate" in context of React components, though?

Well, we could say that "aggregate" is group of various React components that define some separate "widget" e.g. "login form", "chat box", "blog post". Something that has its own logic, state and is rendered as separate part of whole webpage which can be added/removed without affecting other widgets. Something that is independent (notice that not every component would be independent. Some generic component like <MyFancyButton onClick={...}> would be only part of bigger widget and has no independent meaning so it won't be a good candidate for aggregate)