Question
Qwik Optimizer: Transitioning from standard JS closures to serialized state
Mira Indigo
0 reputation · 08 Mar 2020, 15:42 UTC
97.3K views
Loading…
0 reputation · 08 Mar 2020, 15:42 UTC
Qwik's resumability architecture relies on the optimizer to transform functions marked with the $ suffix into lazy-loadable QRLs. This process ensures that the browser can resume execution without a full hydration phase by serializing the application state directly into the HTML.
A technical challenge arises when integrating legacy JavaScript patterns or third-party libraries that rely on closures to maintain state. Because the optimizer extracts these functions into separate chunks, standard closures that capture local variables may not persist across the serialization boundary, potentially forcing the framework to fallback to hydration-like behavior or causing runtime errors.
Given the requirement for granular code splitting in Qwik, what is the recommended strategy for handling state that must persist across lazy-loaded function boundaries without breaking resumability? How should developers identify when a closure has inadvertently bypassed the optimizer's serialization logic?
35275 reputation · 08 Mar 2020, 20:40 UTC
The recommended strategy is to avoid implicit closure capture. Instead, make the state an explicit argument to the function marked with $ and pass it through the QRL. For mutable or complex data, store it in a Qwik reactive store (useStore or useSignal) and serialize the store’s JSON representation into the DOM. The lazy‑loaded function receives the store reference via QRL parameters and can read or mutate it after resume.
When a closure captures a local variable, the optimizer cannot serialize that value into the HTML. The captured variable is effectively a runtime reference that the browser cannot reconstruct after the initial load, forcing a fallback to hydration or causing a runtime error when the function is invoked.
qwik
javascriptfunction myHandler$ (state) { … }.
const counter = useStore({ value: 0 }); and pass counter as a QRL argument.
$ suffix so the optimizer can extract it into a separate chunk.
During a build, the optimizer emits a warning when a closure captures non‑serializable state. Check the build log for messages such as Unserializable state detected. In development, Qwik devtools will list QRLs that include serialized payloads; any function that appears without a payload is likely not being serialized correctly.
export function onClick$ (store) { … }.
{createQRL(onClick$, store)}.
npm run build and look for Unserializable state detected.
To refine the recommendation, could you share whether your build output contains any optimizer warnings about unserializable state? This will help determine if a closure is inadvertently bypassing serialization.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 08 Mar 2020, 17:08 UTC
To prevent closures from breaking resumability, developers must move state from lexical variables into Qwik's reactive primitives like useSignal or useStore. When the optimizer extracts a $-suffixed function into a separate QRL, it loses access to the original execution context, leaving only what is explicitly serialized into the HTML.
A practical way to identify when a closure has bypassed serialization is to inspect the serialized state payload in the DOM. If a function relies on a variable that is not present in the "qwik-data" or script block, it will likely encounter an undefined reference or throw an error upon execution.
For legacy third-party libraries that strictly require internal closures, consider initializing the library within a useTask$ or useVisibleTask$ and passing necessary state through signals to ensure it persists across the serialization boundary.