Data management principles

# Data management principles ## State is part of the tree In SSR the same app runs for multiple users, globally declared state works great in the browser but have several problems specially in SSR: - Difficult to test (it can not be easily replaced and mocked) - Global is hard to serialize, Qwik is HTML-centric - Qwik Render in async, meaning that several apps can run at the same time, a global state would just not work. - Even without async, having state declared outside the tree can be a security vulnerability in SSR, since some data might leaks between runs. ## The reactive primitive is the store For Qwik is critically important to serialize, so applications can resume. - Serializing objects is easy, serializing functions is costly. - The reactive primitive in Qwik is the object, not functions (similar to Preact Signals) - Signals are just single valued stores `{value: XXX}` ## Separation between data and implementation - Conceptually the idea of classes is an anti-pattern in Qwik, not from DX perspective but from bundling together the data, initial values, and logic to transform the data. - Data can be globally available across the tree, but processing of data should be async and in-demand. ## Rendering is idempotent Applications should never rely on the render function being called, Qwik will ensure that the template matches the DOM, but it deserves its right not avoid calling the render function. - render function might be called 10 times or 0 times, developers should never rely on it. ## Fight one battle Other reactive libraries introduces exotic new APIs to achieve reactivity, different libraries make different tradeoffs: - Solid: render runs only once, weird at the beginning, heavy transform. - Voby: very clean model, zero magic, lots of functions and boilerplate that seems like an implementation detail. https://dev.to/fabiospampinato/voby-simplifications-over-solid-no-babel-no-compiler-5epg Qwik already introduces exotic APIs: - The $ methods - The counterintuitive execution model Writing templates should be as natural as possible, just like you would in react. I will argue that react is the most natural one, because it's the most naive, the transform is very 1 to 1 of what the original code does. ## Components are not context aware Authoring of components should not have to make assuptions about how the component is going to be used. - When writing a component, developers don't have to think (or decide) if a prop value will be static or change, it's up to the consumer of the component. ## Strong async guaranties Writting async code is hard: - things that are not supposed to happen in parallel do - things execute in strange order - intermediate state is presented to the user - debugging becomes complicated At Qwik anything that gives stronger guaranties to async code is part of the scope of the framework: - Ensure consistent execution of watches - Ensure data is ready when used - Ensure no intermediate state is showed Enable developers to get full benefit of async programming but without the negative side effects. ## Composable Developers should be able to write their custom utils, their custom `component$()`, custom state tools, custom hooks, custom `$` methods, custom events... Ie, the compiler can introduce magic, but the magic should not be unique to internal methods. Svelte suffers from this problem. ## Qwik compiler is an optimizer Qwik does not need a build step to run an app, all the compiler tooling is merely an optimization step that enable better performance and serialization. ## Avoid javascript when possible Qwik cares about building sites, that includes JS, HTML and CSS. Qwik is opiniated about how styling should work in a site. - A lot styling solution out there depend too much in javascript: dynamically generated styles for example - Most of styling solutions are compatible with streaming, they need to add styling after render. While we encourage developers to discover new patterns, the core team have strong opinions about not emiting extra JS to solve problems that are already solved by CSS, CSS variables and scoping. ## Dont be opiniated about data flow Unidirectional data flow is usually a good practice, but Qwik will not enforce this, it's up to third party libraries built on top of qwik primitives to stablish new restrictions. For Qwik, props and context is used to pass stores/signals down the tree, but reactivity flows freely. ## Dependency Injection is hierarchical The context API (`useContextProvider()` and `useContext()`) is the only API for DI in Qwik. Parents components can inject context accessible by any descendant. ## Template description is sync, but rendering is async The render function must return syncronously a JSX tree, ie, the render function can not return a Promise, however, the render tree might contain promises or lazy loaded components. ## DOM writes are sync Even thought the qwik render is fully async, the DOM writes will be committed to the DOM in a fully sync way: - Avoid flickering - Avoid incomplete UI - Avoid errored UI (in case of rendering the whole queue of DOM operations can be dropped safely) ## App state never escapes the container Every qwik app is a HTML-container, notice the `<html q:container="paused">`, multiple containers can live within the same document, they can even be nested by state objects can not live in two containers at the same time. Inter container communication is still a work in progress, but it will follow a message-passing paradigm, not memory-sharing. Ie, we could even support reactivity across container by keeping two containers syncronized, rather than actually sharing the same reactive object.