# Qwik FAQ

[deprecated](https://hackmd.io/zo9VVK4oR-6kFrq7hm7CPg)

## Objective

Collect a set of questions from the community which can be answered here giving people better insights as to why certain design choices were made.

## FAQ

### Add your questions here in this format.
> we will add the explanation.

### What is a `QRL`.
> A `QRL` is a special format URL which contains information about:
> - Chunk to be downloaded
> - Symbol/export which should be retrieved from the chunk.
> - Lexical scope of variables which were captured in the closure.

### What are a `Transient` Objects.
> Not all objects can be serialized into JSON. Examples are streams, promises, etc.. Such objects need to be re-created when the application resumes on the client. Qwik has special mental model for dealing with transient objects and API for lazy creating then. The thing to remember is that transient objects can-not survive serializations.

### What is runtime-based-optimization?
### Isn't breaking up code into too many chunks counter-productive?
> Optimizer breaks up the application into many small chunks. Too many actually. Instead we would like to group related symbols into same chunk. But how do you know which symbols should go into the same chunk? In first iteration you take a guess, but then as the application runs, you collect data on which symbols are used in which order. This data can than be used to have a sorted list of how likely it is that the application will need a given chunk. On subsequent application build you feed the sorted list of symbols into the optimizer along with an optimal chunk size. The optimizer will that group symbols which are likely to be used together into a single chunk until the desired chunk size is reached. At that point new chunk is started. This is repeated until all symbols are processed. The result is ideal chunk size based on how the users actually use the application.

### How does the optimizer 'know' that state deserves special treatment? is there something magical about the `useState` import? if the call to `useState` was behind a custom hook, what would happen?
> There is nothing magical about `useState`, and yes it can be behind a custom hook and it will work just fine. `useState` creates a special proxy objects which has a unique ID which allows the system to track it. What is special are methods such as `qComponent`, `onRender` and `on:*` properties in JSX. These tell the Optimizer that the provided closure should be transformed into `QRL` and extracted into a lazy loadable resource. You can think of these method calls as markers which tell the Optimizer that a transformation needs to happen. Every time you come across this special method you should think *lazy loaded boundary*.

### State is serialized to JSON. does that mean it can only include JSON-serializable values?
> Mostly yes.
> - Anything which is JSON serializable is OK.
> - We also have special handlers for things such as dates, and potentially even callbacks under some narrow circumstances.
> - Everything else needs to be stored in Transient objects.
> - Unlike JSON the object graph can by cyclic and Qwik will restore the graph just fine.

### Qwik core is 69kb, is that the baseline for any interactivity?
> Yes, but that is 69kb in dev mode before minification. In production the number should be closer to 20kb (before gzip). Also the same tricks which are applied to app code could be applied to the core, and so most of could be broken down into smaller chunks, but we have not been focusing on this, as we believe that in large applications core is relatively small compared to the application size.

### How do you avoid tearing? if a state change affects a component that hasn't been loaded yet, do you wait for everything to load before applying state changes?
> I think by tearing, you mean that the state somehow dissociates from the component, because it is mutated before the component is loaded? This is not an issue because components don't get hydrated in the same way as in other frameworks where the components "replay" themselves into hopefully same state. Instead Qwik components "resume". They continue execution where they left off. Take `Counter` example.
>
> ```typescript=
> const Counter = qComponent(() => {
> const state = useState({count: 0});
> return onRender(() => (
> <button on:click={() => state.count++}>
> {state.count}
> </button>
> );
> })
> ```
> The above code is broken up into these chunks
> ```typescript
> const Counter = qComponent(qrl('chunk-a.js', 'Counter_onMount'));
> ```
> `chunk-a.js`
> ```typescript
> export const Counter_onMount = () => {
> const state = useState({count: 0});
> return onRender(qrl('chunk-b.js', 'Counter_onRender'));
> };
> ```
> `chunk-b.js`
> ```typescript
> export const Counter_onRender = () => {
> const [state] = useLexicalScope();
> return (
> <button on:click={qrl('chunk-c', 'Counter_onRender_button_onClick')}>
> {state.count}
> </button>
> );
> };
> ```
> `chunk-c.js`
> ```typescript
> export const Counter_onRender_button_onClick = () => {
> const [state] = useLexicalScope();
> return state.count++;
> };
> ```
> The next thing to understand is lifecycle.
> 1. The component is instantiated on initial render, (probably SSR). This requires that we execute components `onMount` (`Counter_onMount`).
> 2. The result of `onMount` is that the component has created a state object. This object is assigned an ID and is tracked.
> 3. The component is serialized into HTML: `<div on:q-render="./chunk-b.js#Counter_onRender['stateId']">`
> 4. At this point we can execute the render function, to do initial component render.
>
> The above is pretty straight forward. What is different is when the application is sent to the client and needs to be resumed.
>
> 1. On client we decide that component needs to be re-rendered.
> 2. We look at the component `on:q-render` attribute and know that we need to load `chunk-b.js` and retrieve `Counter_onRender`.
> 3. The execution will than need to restore `state` which is identified in the QRL as `stateId`.
> 4. Once the object is identified the function can execute and return the JSX which is than reconciled against the UI.
>
> Few things to point out which are not obvious:
> - On the client the `Counter_onMount` is never executed (nor is it even downloaded.) The `onMount` runs on component creation. The mental model is that the component was created on the server and resumed on the client. We don't re-create the component on the client, we resume it.
> - The implication of the above is that the `onMount` code could contain server specific code. It also means that the the component never goes out of sync with the data.
>
> The above mental model insures that the components can be resumed at any time and continue their execution without needing them to be replayed into the correct state.

### I assume you've thought deeply about latency/offline but it'd be good to know how the framework thinks about those problems
> There are two answers to this:
> - In web-worker we can start to prefetch the code immediately. This ensures there is no latency on first interaction So as long as you can download the code into the client it can run offline just fine.
> - See runtime-based-optimization.