Runtime implementation for Lavash LiveViews.
Handles:
- State hydration from URL params
- Ephemeral state initialization
- Dependency graph computation
- Action execution
- Assign projection
Summary
Functions
Update combination-based subscriptions based on current filter values.
Layer-1 entry point that wraps the user's render output if the
optimism extension is loaded. Delegates to
Lavash.Optimistic.RenderWrapper.wrap_render/3 when that module
exists; otherwise returns inner_content unchanged.
Functions
Update combination-based subscriptions based on current filter values.
For reads with invalidate: :pubsub, subscribes to a single combination topic
based on which filters are currently active (non-nil). Uses the resource's
notify_on configuration to determine which attributes to track.
Unsubscribes from old topic when filter values change.
Layer-1 entry point that wraps the user's render output if the
optimism extension is loaded. Delegates to
Lavash.Optimistic.RenderWrapper.wrap_render/3 when that module
exists; otherwise returns inner_content unchanged.
The optimism wrapper produces a
<div phx-hook="LavashOptimistic" data-lavash-state=...> shell
around the user's content. A layer-2-only build that omits the
Lavash.Optimistic.RenderWrapper module gets no wrapper, no
hook, and no embedded JSON state — pure server-authoritative
rendering. See docs/ARCHITECTURE.md punchlist item #8.
Why Code.ensure_loaded? vs function_exported?
function_exported?/3 returns false for modules that haven't
been loaded yet, even if they'd be loadable on demand. Phoenix
LiveView renders run after the module compile cycle, so the
optimism module is reachable but may not be loaded into the BEAM
in the rare case it was tree-shaken. Code.ensure_loaded?/1
forces the load attempt and then function_exported? confirms
the symbol exists.