Implicit Template Updates
This example demonstrates how mutating stores automatically update the templates.
During SSR rendering the server needs to render all of the components in the application. As it is rendering the components the bindings in those components perform reads on store properties. For example, when <DisplayA> reads the countA property from the store, Qwik records that as a subscription. Qwik now knows that if countA changes then <DisplayA> needs to be re-rendered. Rendering templates will automatically set up subscriptions on the store. Each time the template re-renders the old subscriptions are thrown away and new subscriptions are created. This means that the template can change the set of things it is listening to during its lifecycle.
Currently, the buttons don't do anything. Implement the buttons to increment the respective store properties.
Once you make the buttons work, notice that even though all state is stored in a single store, the updates are very focused. a++ button will only cause the re-rendering of <DisplayA> and b++ button will only cause re-rendering of <DisplayB>. The fine-grained re-rendering is an important property of Qwik. It is what allows Qwik applications to stay lean and not download too much code unnecessarily.
Template subscriptions are automatically created and released when the component is removed. There is no need to keep track of them or release them manually.
Qwik is a reactive system. All reactive systems require a single full execution of the application to create subscriptions. Qwik applications also require full execution to set up all subscriptions. However, Qwik applications perform the full execution on the server and transfer the subscription information to the client. In this way, the client knows which component needs to be re-rendered when without being forced to do one full rendering of the whole application. Doing so would force all components to be eagerly downloaded, and Qwik wants to avoid that.
Edit Tutorial