[apsurd]

react can be pure functions that take in props. Given a set of props, ideally data primitives, the outputted view is guaranteed. it's nice.

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.

[azangru]

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?

[apsurd]

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.

[WorldMaker]

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.

[tim1994]

With signals you can avoid the prop drilling. I think signals can help a lot with this approach