If you move the data (the M and the C) entirely out of react, and only pass it in via props, there would be only one place — the root react node — where the props could get into react. Is this what you have in mind? Or are you envisioning multiple root nodes?
That is the classic Flow model or Redux model (if you prefer the common implementation name over the Facebook paper name). Build a central store. Pass the single store down to all necessary components via prop-drilling, then later Contexts (and HOCs) to skip layers as a nice-to-have.
Redux is a lot less fashionable today, but hasn't entirely disappeared as an M and C option.
Well, i've always been a fan of the island architecture that effectively mounts root nodes as little islands of isolated state, yes.
Mainly this avoids the hell that global state SPA patterns produce: redux, reducer patterns in general, and 8 thousand context providers.
I do think there's use cases that warrant global in-memory state, but it's such a pain in the ass to maintain and evolve, i'd always plan against it. Every html node in your app does not need to know about literally everything going on and react instantly to it. it just doesn't.
Just make another page!
Also: so the islands pattern can be as fancy or rudimentary as desired. they can bootstrap themselves via async endpoints, they can be shipped as web components even, or they can be static, pre-hydrated in some manner.
Do you need react at this point? Isn’t it just html/css/components?
I remember the birth of React was because Facebook had a problem - you would add a comment and your notification bar would sometimes not get updated.
They had so many bugs with normal html / css that they wanted to solve this on the application layer - to make inconsistent UI elements unrepresentable.
So they came up with react with global state - because in their use case changing one thing does affect a bunch of other unrelated things, and they all need to sync together.
I mean honestly that’s what I use React _for_ - especially with contexts it’s very easy to express all of this complex interconnected state of a webapp in a consistent way.
And of course there are other ways to solve it - for example with elixir/phoenix you just push all that complexity to the backend and trust in websockets and the BEAM.
I just feel that if you really don’t need global state, then react kinda isn’t needed as well…
> I just feel that if you really don’t need global state, then react kinda isn’t needed as well…
I don't know, in my mind "re-render (efficiently) when state changes" is the core point of react and similar frameworks. That requirement still stands even if I have a smaller, local state.
The islands pattern is underrated for maintainability. I've found the biggest win isn't even the state isolation — it's that each island can have a completely independent upgrade path. You can rewrite one island from React to vanilla JS (or whatever comes next) without touching anything else.
The global state SPA pattern fails for a more fundamental reason than just being painful to maintain: it creates an implicit contract between every component in the app. Change one reducer and you're debugging side effects three layers away. Islands make the contract explicit — each one owns its data, full stop.
The one gotcha I've hit is cross-island communication. PostMessage works but gets messy. Custom events on a shared DOM ancestor end up being the cleanest pattern for the rare cases where islands genuinely need to coordinate.
I think the parent wants to separate the V from the M/C. If you smuggle signals inside of components to avoid prop drilling, you would be coupling the M/C and the V. I suppose that's not what the parent has in mind.
In practice, the entire JS ecosystem enjoys flying off the rails, every season, but it's not strictly react's fault.
To answer your question, however those props get into the component is up the the M & C. can be async server, or shoved in as json in the script tag.