Enforce client directives to be added statically

[matthewp]

In order to improve the build we want to prevent scanning the generated HTML to find JavaScript usage in order to bundle.

One aspect of doing that is knowing which client directives to build. If we can assume that they are static within the .astro file, we can know which directives to build. For example:

---
import MyComponent from '../components/Mine.jsx';
---

<MyComponent client:load />

Using this information we know that both /src/components/Mine.jsx and astro/client/load.js need to be built. If we assume that this attribute cannot be added dynamically.

For example:

---
import MyComponent from '../components/Mine.jsx';

let attrs = {
  'client:load': Math.random() > 0.5
}
---

<MyComponent {...attrs} />

We would not know that this component is using the client:load directive.

Rough proposal

1. In the compiler, collect which client directives are used as part of the compiled outputs $$metadata (this export already exists to collect hydrated components).
2. Mark elements that use client directives using some extra attribute like client:statically-added
3. At runtime, check that a client directive is pair with the marking. If not warn the user in dev.

• Note that steps (2) and (3) are necessary to provide good warnings/messaging on dynamic usage. Other ideas are welcome here.

Alternative

One possibly workaround that would enable having dynamic usage of client directives would be if we always bundled the client directives. This would mean that:

• client:load
• client:media
• client:idle
• client:only
• client:visible

Would all be built to the dist/ folder and at runtime the right one would get used.

[FredKSchott]

Sounds good! I'm +1 generally and don't have any strong opinions on implementation in the compiler. Will leave that to @natemoo-re and others. I'm not sure I follow the need for client:statically-added but I'm assuming that's an implementation concern that I'm just not familiar with.

If there's no push-back, I'd love for this RFC to state that all Astro directives must be static in the template. I think that's easier to document across all directives vs. only some, and I think more often than not a directive is meant as a signal/instruction to the compiler that would be hidden if applied dynamically.

[matthewp]

The statically-added idea is to provide a warning when a directive is added dynamically. Basically it's a way of the compiler to signal that it saw the directive. Would love a better idea on how to achieve this.

[FredKSchott]

I think @natemoo-re had an idea of how to handle a similar problem where list:class was used but then class was added dynamically. Might be useful to you here.

[innermatrix]

@FredKSchott I believe that there is a viable way to achieve the same result without the directive attribute itself being dynamic; specifically

---
import MyComponent from '../components/Mine.jsx';

let attrs = {
  'client:load': Math.random() > 0.5
}
---

{attrs['client:load']
? <MyComponent client:load />
: <MyComponent />
}

(And I think this would remain available under this proposal.)

This seems like it would be sufficient unless I am failing to imagine some case where multiple dynamically selected directives lead to a combinatorial explosion of cases.

@matthewp If I understand the proposal correctly, this code would end up bundling MyComponent even in the case where client:load ended up being false, because the true case would be seen by the static analyzer?

[matthewp]

@innermatrix Yes, MyComponent would be bundled in this case, but it would be bundled as its own entrypoint, which means it wouldn't add any weight to your page unless you use the component.

[FredKSchott]

Yup, exactly. Bundling & serving your JS by component instead of by page is something that I'm really excited about as a way to improve bundle efficiency, that no one else is really doing today!