BetaBetaDerive a new scope that layers fixed overrides on top of this
one. The child wins for the keys it names; every other key falls
through to this scope's own resolution (its with, then its DOM
walk from host, then the session-wide fallback).
Use it when a host-bound scope is built once and handed down, but a
per-item consumer needs to pin a few more values without re-stating
the host. A list view builds scope({ host }) once; each row action
evaluates against scope.extend({ action }).
Overrides are pinned, exactly like the with passed to
ContextRegistry.scope: they are fixed values, not reactive
providers. A value that must change over time has to come from a
provider resolved through the scope's host, not from extend. See
RuleRegistry.subscribe, which treats pinned keys as constant.
extend does not change the host; the derived scope walks the same
DOM anchor as its parent. To anchor elsewhere, build a fresh scope
with ContextRegistry.scope.
Chainable: the result is itself a ContextScope, so it can be
extended again. Later overrides win over earlier ones for the same
key.
The pinned keys join this scope's read set: the returned scope's
get accepts everything this scope could read plus every key in
overrides. Narrowing from the parent is preserved, not discarded.
Fixed values to pin on top of this scope. Wins over anything this scope would otherwise resolve for those keys.
A new scope reading TReads plus the pinned keys; this
scope is left unchanged.
BetaLook up the current value of a context key.
The context id. Must be one of the keys the scope's
consumer declared upfront (e.g. a primitive's reads), or any
ContextMap key when the scope is used through the wide
default.
The value if any provider answered, otherwise undefined.
A host-bound, typed view over ContextMap. Resolves each key its own way: by walking the DOM, by consulting a session-wide default, or by reading from a fixed value bag. The caller picks which strategy when they build the scope with ContextRegistry.scope.
One method,
get(key). A consumer that needs more than one key callsgetmultiple times.Each key resolves in order from most specific to least: a per-call override on ContextRegistry.scope wins first, then the closest DOM ancestor that registered a value through ContextRegistry.provide, then a session-wide default registered through ContextRegistry.register. If none of those answer,
getreturnsundefined.Resolution is pull-based, not reactive: a
ContextScopeanswers the current value on eachgetcall but does not notify when a value changes. Re-evaluating against a scope when its inputs change is the caller's responsibility. For reactive consumption of context values, use ContextRegistry.subscribe directly.Rules are one consumer of this contract, but not the only one. Command guards, filter predicates, and any other code that wants a "bind a host plus overrides once, then read keys repeatedly" helper builds a
ContextScopeand reads from it.Example
Building and reading from a scope
See
ContextScope.