Explanation: Shell Hydration Lifecycle

The Framework M Shell uses a backend-driven hydration strategy to ensure it remains "zero-conf" across different deployment environments. This process injects critical runtime configuration directly into the HTML payload before the JavaScript bundle executes.

The __FRAMEWORK_CONFIG__ Payload

When the browser requests the /desk/ route, the backend desk_routes handler prepares a JSON payload and injects it into a global variable on the window object.

Injected Data

Key	Purpose
apiBaseUrl	The primary endpoint for all framework API calls.
metaBaseUrl	The endpoint for fetching DocType and UI metadata.
frameworkMode	Tells the shell whether it's in MONOLITH or MACROSERVICE mode.
serviceName	The identity of the current backend service.

The prewarmCore Phase

Before the Shell renders its first component, it enters a prewarmCore phase. This is an asynchronous blocking step in the FrameworkMShell component.

1. Read Config: The shell reads the __FRAMEWORK_CONFIG__ from the window.
2. Initialize SDK: It sets the base URLs in the PluginRegistry.
3. Core Discovery: It triggers the DiscoveryClient to resolve essential system services (typically auth and settings).
4. Bootstrap: Once core services are resolved, the shell sets isCoreWarmed = true and renders the layout.

Why this matters

This lifecycle allows the same Docker image/build to be deployed in:

• Local Dev: Hitting localhost:8000.
• Production Monolith: Hitting api.example.com.
• Macroservice Cluster: Hitting namespaced endpoints via a gateway.

The Shell never needs to be "rebuilt" for different environments; it just adapts to the config injected by the backend that serves it.