finalize v1.0 component script and style behavior

[FredKSchott]

• Start Date: 2021-12-09
• Status: Accepted
• Previous discussion: Finalize v1.0 with @component tag #12

Summary

Finalize the component styling & scripting behavior for v1.0. Documents existing behavior and adds 2-3 new restrictions to prevent bugs.

<style>
  @import './dep.css'; /* Vite imports supported, including npm packages! */
  h1 { color: red; }
</style>

<style global>
  /* Same as <style>, but styles are applied globally to the page. */
  body { padding: 5px; }
</style>

<script>
  console.log('included as-is in the final HTML page output.')
</script>

<script hoist>
  import cowsay from 'cowsay';
  console.log(cowsay('I am bundled with the rest of the website JS!'));
</script>

<h1>Hello!</h1>

Links

• Full Rendered Proposal

[FredKSchott]

Capturing some other feedback from @jasikpark in #12:

• A use case that I would not want to lose is scoped styles + define:vars, which it sounds like this RFC removes w/ scoped styles being behind @component + define:vars only supported via static markup. Is this not a use case that's supported today?

@jasikpark @matthewp take a look at https://github.com/withastro/rfcs/blob/style-script-rfc/active-rfcs/0000-style-script-behavior.md#deep-dive-definevars - I believe that we can keep define:vars behavior for component-level styles, with the caveat that multiple component renders may override the value globally.

• Is it a requirement that all attributes are dropped from a tag with @component? Could those attributes not be copied over to the browser?

It is currently the case that all attributes are dropped from <style> and <script hoist>. This is because they are all bundled together into the final optimized CSS and JS bundles for the page, so it's not 1:1 how many <script> tags you finally get on the page.

[jasikpark]

This looks good as a way to solidify what the current behavior is so we can work off of it towards a new rfc!

[jasikpark]

Isn't this provided by hoist?

[FredKSchott]

yes, good point. This is trying to say that we could do is:unique seperately from hoist. But I guess none of that is really in scope for this RFC anymore, so maybe best to remove entirely.

[jasikpark]

How can we test for whether it will impact many users? Once usecase I would personally use for supporting LaTeX formatting would be conditionally adding in the CSS and JS for processing LaTeX markup only on pages with "hasMath" in the front-matter. I don't know how often that's a thing, but I definitely think it's a valid usecase!

[FredKSchott]

Ah you're right, this may work given how the bundler works today. I'd assumed most use-cases for this were buggy. Let me address this in the RFC, but regardless this will be a pretty strict requirement for the build perf + SSR-readiness improvements that we need to make.

There could be other ways to solve this though, by treating that logic more like a component to be added conditionally.