Capturing lexical scope

In this example, we will explore how Qwik serializes the component state. A naive approach would be for Qwik to simply save all of the state associated with the useStore(). Qwik is more intelligent about the approach and tries to tree shake the stores that are not needed by the client.

The example consists of:

• <App/>: which creates a store.
• The Store contains the largeData property. Assume that this is a large data set that is only needed on the server. An example of this is the HackerNews demo. The server must retrieve the news articles from the JSON API and then use that data to render them. The articles are read-only for the user and so the HTML response will never re-render on the client. For this reason, it would be preferable not to send the data to the client.
• A button that updates unrelated data.

Look into the HTML tab and notice that largeData was serialized into <script type="qwik/json">. This is not ideal because we are sending data to the client which will never change and will never be used for re-rendering. Your goal in this exercise is to fix this.

Why is largeData serialized

Qwik's serialization process starts by using all of the listeners as serialization roots. In our case, the onClick$ on <button> is used as a serialization root. Notice that the onClick$ closure closes over store. The fact that onClick$ closes over store gives Qwik no choice but to serialize the store and, with it, all of the child properties.

To fix this, change the onClick$ closure from store.counter.count++ to counter.count++. (We have already created a local reference for you for counter.) This change modifies what the onClick$ closure captures. Capturing more specific references allows Qwik to remove the need to serialize the largeData property.

Open the HTML tab and notice that Qwik no longer serializes largeData in this example.

Edit Tutorial