You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -26,14 +26,14 @@ export function Counter(props: {step?:number}) {
26
26
}
27
27
```
28
28
29
-
Note that the components view, state, and handler are all inlined together. The implication is that all of these parts (view, state, and handler) have to be downloaded, parsed, and executed together. This severely limits our lazy loading capability.
29
+
Note that the components view, state, and handler are all inlined together and heavily rely on closing over variables in parent scope. The implication is that all of these parts (view, state, and handler) have to be downloaded, parsed, and executed together. This severely limits our lazy loading capability.
30
30
31
-
The example above might be trivial, but imagine a more complex version of the above, which requires many KB worth of code to be downloaded, parsed, and executed together. In such a case, requiring the view, state, and handler to be eagerly loaded together might be a problem. Let's look at some common user usage patterns to get a better idea as to why this is an issue:
31
+
The example above may be trivial, but imagine a more complex version of the above, which requires many KB worth of code to be downloaded, parsed, and executed together. In such a case, requiring the view, state, and handler to be eagerly loaded together is a problem. Let's look at some common user usage patterns to get a better idea as to why this is an issue:
32
32
33
33
**User interacts with a component by clicking on it:**
34
34
35
35
- some of the `handler`s are needed: Only the specific handler which is triggered needs to be downloaded. All other handlers are not needed.
36
-
-`view` is **not needed**: View may not be needed because the handler may not cause a re-render on may cause a re-render of a different component.
36
+
-`view` is **not needed**: View may not be needed because the handler may not cause a re-render or may cause a re-render of a different component.
37
37
-`state factory` is **not needed**: The component is being rehydrated and so no state initialization code is needed.
38
38
39
39
**Component state is mutated:**
@@ -56,161 +56,92 @@ Qwik solves this by only downloading and executing the code that is needed for t
56
56
57
57
It is not possible to "tool" our way out of this. It isn’t possible to write a statically analyzable tool that can separate these pieces into parts that can then be lazy loaded as needed. The developer must break up the component into the corresponding parts to allow fine-grain lazy loading.
58
58
59
-
Qwik has `qrlOnRender`, `qrlOnMount` and `qrlHandler` marker functions for this purpose.
59
+
Qwik has `qHook` marker functions for this purpose.
Compared to other frameworks, the above is wordier. However, the cost of the explicit break up of components into their parts gives us the benefit of fine-grained lazy loading.
83
+
Compared to other frameworks, the above is a bit wordier. However, the cost of the explicit break up of components into their parts gives us the benefit of fine-grained lazy loading.
97
84
98
85
- Keep in mind that this is a relatively fixed DevExp overhead per component. As the component complexity increases, the added overhead becomes less of an issue.
99
86
- The benefit of this is that tooling now has the freedom to package up the component in multiple chunks which can be lazy loaded as needed.
100
87
101
88
## What happens behind the scenes
102
89
103
-
`qrlOnMount`, `qrlHandler`, `qrlOnRender` are all markers for Qwik Optimizer, which tell the tooling that it needs to transform any reference to it into a QRL. The resulting files can be seen here:
90
+
`qHook` is a marker for Qwik Optimizer, which tells the tooling that it needs to transform any reference to it into a QRLs. The resulting files can be seen here:
In addition to the source file transformation, the optimizer removed any static references between the view, state, and handlers. Optimizer also generates entry point files for the rollup. These entry points match the QRLs above.
141
-
142
-
**File:** `chunk-abc.js`
143
-
144
-
```typescript
145
-
export { onRender } from'./my-counter';
146
-
```
147
-
148
-
**File:** `chunk-pqr.js`
149
-
150
-
```typescript
151
-
export { update } from'./my-counter';
152
101
```
153
102
154
-
**File:** `chunk-cde.js`
155
-
156
-
```typescript
157
-
export { onMount } from'./my-counter';
158
-
```
103
+
In addition to the source file transformation, the optimizer transformed references between the view, state, and handlers into QRLs. Optimizer also generates entry point files for the rollup. These entry points match the QRLs above.
159
104
160
-
The important thing to note is that Qwik has great freedom on how many entry files should be generated, as well as which export goes into which entry file. This is because the developer never specified where the lazy loading boundaries are. Instead, the framework guided the developer to write code in a way that introduced many lazy loading boundaries in the codebase. This gives Qwik the power to generate optimal file distribution based on actual application usage. For small applications, Qwik can generate a single file. As the application size grows, more entry files can be generated. If a particular feature is rarely used, it can be placed in its own bundle.
161
-
162
-
Once Rollup processes the entry files, the resulting files are as seen below:
Notice that Rollup flattened the contents of files into the entry files and removed any unneeded code, resulting in ideally sized bundles.
137
+
The important thing to note is that Qwik has great freedom on how many entry files should be generated, as well as which export goes into which entry file. This is because the developer never specified where the lazy loading boundaries are. Instead, the framework guided the developer to write code in a way that introduced many lazy loading boundaries in the codebase. This gives Qwik the power to generate optimal file distribution based on actual application usage. For small applications, Qwik can generate a single file. As the application size grows, more entry files can be generated. If a particular feature is rarely used, it can be placed in its own bundle.
200
138
201
139
### Constraints
202
140
203
-
In order for the tooling to be able to move `qrlOnRender`, `qrlOnMount`, `qrlHandler` around the usage of these methods is restricted. (Not every valid JS program is a valid Qwik program.) The constraint is that all of the marker functions must be a top-level function that is `export`ed.
141
+
In order for the tooling to be able to move `qrlOnRender`, `qrlOnMount`, `qrlHandler` around the usage of these methods is restricted. (Not every valid JS program is a valid Qwik program.) The constraint is that all functions which are enclosed in `qHook`must be moveable into different files. In practice this means that functions can only close over symbols which are:
204
142
205
-
Examples of invalid code:
206
-
207
-
```typescript
208
-
import { someFn } from'./some-place';
209
-
210
-
function main() {
211
-
const MyStateFactory =qrlOnMount(() => ({})); // INVALID not top level
212
-
}
213
-
```
143
+
1.`import`able (i.e. the symbol was `import`ed.)
144
+
2.`export`ed (i.e. the symbol is already exported so that it can be imported from the entry file.)
In typical development, when discussing object lifespan, it is clear that objects either exist or they do not. Either an object has been instantiated, or it has not yet been instantiated (or it has been instantiated and has since been garbage collected. Hence it no longer exists.)
0 commit comments