Set configs at runtime

[brillout]

Description

Many configs, such as https://vike.dev/bodyHtmlEnd, can be set programmatically — but only at config-time, not runtime.

My gut feelings says we'll eventually need to be able to set(/override) configs at runtime. I've ideas how to enable this across all configs.

@suliemandev Definitely let me know if you stumble upon such use case.

[suleimansh]

Yes, I keep hitting this and it's always the same shape: multi-tenant, where the value isn't knowable until the
request arrives.

Concrete cases from the extensions:

• vike-themes/vike-layouts one deployment, many tenants by host/subdomain, each with its own theme / logo / nav.
  Today those are config-time (sibling key in +config), so a single build can't serve tenant A's brand and tenant B's
  brand. I'd want to resolve them per-request from the host.
• vike-i18n lang + head meta are config-time, but locale is resolved per-request. Setting them at runtime is the
  natural fit.
• vike-stripe billingSubject is config-time today, but in a real SaaS it's a per-tenant property.
• Your own bodyHtmlEnd example: per-tenant/per-locale analytics or script injection.

One design caution: this overlaps pageContext. The line I'd draw: pageContext = per-request data, runtime configs =
per-request behavior/wiring (which Wrapper, which head, which injection).
If that boundary stays crisp it's a big unlock; if it blurs, we end up with two ways to do the same thing.
The cumulative-config extensions (themes registry, locale packs) are exactly where I'd want to pilot it.

[brillout]

The idea is to piggy-back on this:

• Flat pageContext #1268

=> the user can set pageContext.theme = 'black' (in any hook at runtime) but it's actually all immutable:

• pageContext.runtime.theme holds 'black'
• pageContext.config.theme holds what was set at config-time
• pageContext.theme resolves the precedence (while pageContext.runtime having the highest precedence)

It isn't trivial though, so I'm inclined to post-pone it until we have a strong case for it from the perspective of startups.

[suleimansh]

Yes #1268's source-precedence feels like the right shape here. Putting runtime on top basically removes the
config-vs-pageContext overlap I was worried about, on paper at least.
We'll only really know once it's built for a real multi-tenant case though, so happy to park it until one comes up.
Theme/locale by host is probably what pulls it in.

One thing I'd want to figure out when we get to it: how does the runtime value get to the client for configs that
render there too (Wrapper mainly)? Auto-serialized, or does it go through passToClient? Server-only stuff like your
bodyHtmlEnd example doesn't need it, but a client-rendered config would hydrate wrong if the client only sees config.
And it makes the response per-tenant, so we lose static caching on that key.

[brillout]

how does the runtime value get to the client

Not sure. I guess either you set the value in a isomorphic hook, or via passToClient.