console.log(foo)}/>
});
// Valid
component$(() => {
const foo = { data: 12 };
return
console.log(foo)}/>
});
```
##### Module-declared variables can be importable
If a function that is being extracted by the Optimizer refers to a top-level symbol, that symbol must either be imported or exported.
```tsx
// Invalid
const foo = new MyCustomClass(12);
component$(() => {
// Foo is declared at the module level, but it's not exported
console.log(foo);
});
// Valid
export const foo = new MyCustomClass(12);
component$(() => {
console.log(foo);
});
// Valid
import { foo } from './foo';
component$(() => {
console.log(foo);
});
```
## Deep dive
Let's look at the hypothetical problem of acting on a scroll event. You may be tempted to write the code like so:
```tsx
function onScroll(fn: () => void) {
document.addEventListener('scroll', fn);
}
onScroll(() => alert('scroll'));
```
The problem with this approach is that the event handler is eagerly loaded, even if the scroll event never triggers. What is needed is a way to refer to code in a lazy loadable way.
The developer could write:
```tsx
export scrollHandler = () => alert('scroll');
onScroll(() => (await import('./some-chunk')).scrollHandler());
```
This works but is a lot of work. The developer is responsible for putting the code in a different file and hard coding the chunk name. Instead, we use the Optimizer to perform the work for us automatically. But we need a way to tell the Optimizer that we want to perform such a refactoring. We use `$()` as a marker function for this purpose.
```tsx
function onScroll(fnQrl: QRL<() => void>) {
document.addEventListener('scroll', async () => {
const fn = await fnQrl.resolve();
fn();
});
}
onScroll($(() => alert('scroll')));
```
The Optimizer will generate:
```tsx
onScroll(qrl('./chunk-a.js', 'onScroll_1'));
```
```tsx title="chunk-a.js"
export const onScroll_1 = () => alert('scroll');
```
1. All that the developer had to do was to wrap the function in the `$()` to signal to the Optimizer that the function should be moved to a new file and therefore be lazy-loaded.
2. The `onScroll` function had to be implemented slightly differently as it needs to take into account the fact that the `QRL` of the function needs to be loaded before it can be used. In practice using `QRL.resolve()` is rare in Qwik applications as the Qwik framework provides higher-level APIs that rarely expect the developer to work with `QRL.resolve()` directly.
However, wrapping code in `$()` is a bit inconvenient. For this reason, one can use `implicit$FirstArg()` to automatically perform the wrapping and type matching of the function taking the `QRL`. The function passed into `implicit$FirstArg()` should have a suffix of `Qrl`, and the result of that function should be set to a value with a suffix of `$`;
```tsx
const onScroll$ = implicit$FirstArg(onScrollQrl);
onScroll$(() => alert('scroll'));
```
Now the developer has an easy syntax for expressing that a particular function should be lazy-loaded.
## Symbol extraction
Assume that you have this code:
```tsx
export const MyComp = component$(() => {
/* my component definition */
});
```
The Optimizer breaks the code up into two files:
The original file:
```tsx
const MyComp = component(qrl('./chunk-a.js', 'MyComp_onMount'));
```
and a chunk
```tsx title="chunk-a.js"
export const MyComp_onMount = () => {
/* my component definition */
};
```
The result of Optimizer is that the `MyComp`'s `onMount` method was extracted into a new file. There are a few benefits to doing this:
- A Parent component can refer to `MyComp` without pulling in `MyComp` implementation details.
- The application now has more entry points, giving the bundler more ways to chunk up the codebase.
## Capturing the lexical scope
The Optimizer extracts expressions (usually functions) into new files and leaves behind a `QRL` pointing to the lazy-loaded location.
Let's look at a simple case:
```tsx
export const Greeter = component$(() => {
return
Hello World!
;
});
```
this will result in:
```tsx
const Greeter = component(qrl('./chunk-a.js', 'Greeter_onMount'));
```
```tsx title="chunk-a.js"
const Greeter_onMount = () => {
return qrl('./chunk-b.js', 'Greeter_onRender');
};
```
```tsx title="chunk-b.js"
const Greeter_onRender = () =>
Hello World!;
```
The above is for simple cases where the extracted function closure does not capture any variables. Let's look at a more complicated case where the extracted function closure lexically captures variables.
```tsx
export const Greeter = component$((props: { name: string }) => {
const salutation = 'Hello';
return (
{salutation} {props.name}!
);
});
```
The naive way to extract functions will not work.
```tsx
const Greeter = component(qrl('./chunk-a.js', 'Greeter_onMount'));
```
```tsx title="chunk-a.js"
const Greeter_onMount = (props) => {
const salutation = 'Hello';
return qrl('./chunk-b.js', 'Greeter_onRender');
};
```
```tsx title="chunk-b.js"
const Greeter_onRender = () => (
{salutation} {props.name}!
);
```
The issue can be seen in `chunk-b.js`. The extracted function refers to `salutation` and `props`, which are no longer in the lexical scope of the function. For this reason, the generated code must be slightly different.
```tsx title="chunk-a.js"
const Greeter_onMount = (props) => {
const salutation = 'Hello';
return qrl('./chunk-b.js', 'Greeter_onRender', [salutation, props]);
};
```
```tsx title="chunk-b.js"
const Greeter_onRender = () => {
const [salutation, props] = useLexicalScope();
return (
{salutation} {props.name}!
);
};
```
Notice two changes:
1. The `QRL` in `Greeter_onMount` now stores the `salutation` and `props`. This performs the role of capturing the constants inside closures.
2. The generated closure `Greeter_onRender` now has a preamble which restores the `salutation` and `props` (`const [salutation, props] = useLexicalScope()`.)
The ability for the Optimizer (and Qwik runtime) to capture lexically scoped constants significantly improves which functions can be extracted into lazy-loaded resources. It is a powerful tool for breaking up complex applications into smaller lazy-loadable chunks.