iAPI: Review the initialization logic

[DAreRodz]

What problem does this address?

Currently, the Interactivity API initialization relies on the correct order of modules to function as intended. All modules that register a store should be evaluated before the hydration process begins. Similarly, the Interactivity API Router depends on the initial page to be hydrated beforehand; it fails if the module is enqueued directly.

What is your proposed solution?

We need to ensure everything works okay without having to rely on the order or the order these modules are enqueued or imported.

[luisherranz]

The order should be:

1. Any initially enqueued script module that is executed on page load calls store.
2. The Interactivity API hydrates the regions.
3. Any script module that loads after page load because it was lazy loaded can still call store.

We'd have to think about these things:

1. What technique to use to await until all the initially enqueued script modules have had time to call store to do the hydration.
   • Can we assume that these are always synchronous? (sometimes they are not because of how webpack handles the static/dynamic module imports, but that's a webpack's problem we should solve).
2. How to organize the initialization steps so that it's clear what's happening.
3. Fix how the router gets the initial vDOM.

[DAreRodz]

I've been playing with a possible solution in #71123.

Another idea I've come up with is to have regions wait for the stores they depend on to exist before hydrating. 🤔

In principle, a page rendered with server-side rendering already has the correct HTML. If a region depends on a namespace to be interactive, it would only need to be hydrated when a user wants to interact with it. It could only be interactive if the actions and callbacks it requires have been defined with the corresponding call to store(). Of course, the call to store() made during initialization of the initial state should be ignored.

I'm not considering calls to store() with fragmented or partial initializations, which could add state or actions needed at a later time. Asynchronous calls to store() would still need to be supported.

I'm also not considering regions that share state and depend on each other. In principle, if both consume the same namespace, but one of them depends on another namespace that hasn't been defined yet, hydration would happen later for this second region, which could display inconsistent data on the screen.