Scoped Global IDs for Elements (Astro templates)

[snewell92]

Summary

Globally scope any ids found on a DOM node in an astro component, similar to css, so it is even easier to reference them in client side <script> tags.

Important

If per-instance behaviour is desired, inline might be used to opt out of the normal script processing, but that has other footguns due to opting out.

A half joke tweet inspired this.

Background & Motivation

Astro should be the easiest framework to get started right away with web development. Imagine if we didn't even need querySelector / jQuery / or a framework at all to do the example below.

Goals

• Immediate access to the DOM
• Faster dev cycle to sprinkle small interactions
• Instance scoped direct DOM access
• (optional) Strongly Typed access to the DOM

Example

Example.astro

---
interface Props {
  title: string;
}

const { title } = Astro.props;
---

<h1>{title}</h1>
<p>This is a <span id="adjective">great</span> idea</p>
<button id="btn">Cycle</button>

<script>
  /* Can astro generate and provide types? Global vs local? */
  declare global {
    const adjective: HTMLSpanElement;
    const btn: HTMLButtonElement;
  }

  const adjectives = ["great", "bad", "fantastic", "dubious", "superfluous"];
  let currAdjectiveIdx = 0;
  const MAX_IDX = adjectives.length - 1;

  function cycleAdjective() {
    currAdjectiveIdx++;
    if (currAdjectiveIdx > MAX_IDX) {
      currAdjectiveIdx = 0;
    }

    adjective.innerText = adjectives[currAdjectiveIdx];
  }

  btn.onpointerdown = cycleAdjective;
</script>

The ids would be scoped per component instance so the following would work:

Page.astro

<Example title="first" />

And then consider the inline case, so add

+ <script is:inline>
- <script>

And then duplicating works:

<Example title="first" />
<Example title="second" />
<Example title="third" />

Related

Relates to #549 (comment)

We could extend/mix the above with scoped IDs to use some well known symbol Astro compiles away for us, unsure how you would have multiple IDs like I have in my example, tbh I find more value in the global scoped IDs I still manually create and name, rather than an opaque single use symbol/identifier.

[delucis]

One issue here is that id is only valid for a single component instance, whereas it's pretty common to have multiple instances of a component on a page.

I usually recommend reaching for custom elements to help simplify this kind of pattern: https://docs.astro.build/en/guides/client-side-scripts/#web-components-with-custom-elements

Agree it would be cool if Astro's editor tooling could know what's in the template!

[snewell92]

This proposal would necessitate that exact scenario working. I would imagine the implementation would be some kind of prefix hash on each id for each instance of the component, so that the following code would work from the Example.astro above. I'll add this as more explicitly desired in the proposal

<Example title="first" />
<Example title="second" />
<Example title="third" />

[delucis]

Ah right, but then your <script> would also need to execute multiple times right? Once for each component instance?

[snewell92]

oh maybe an inline deal or variant to opt in to this behaviour then: https://docs.astro.build/en/guides/client-side-scripts/#script-processing

yep hmm. ok. the added value of a quasi-client-side component can probably be dropped, but that makes this far less valuable imo. But that's what web components or frameworks are for. Astro can basically provide some nice type safe id access for things like <div id="root"></div> then and some light use cases, otherwise inline footguns would abound

[snewell92]

I would recommend using @bholmesdev 's simple query: https://simple-stack.dev/query

It's got everything and more!

[bholmesdev]

Ah, thanks so much! I was going to share my work in here, since it sounds like we're circling the exact same use case. I did make a few choices with that library to address Chris' suggestions, namely using custom elements to allow multiple instances of the same component.

Would love to treat Simple Query as a place to iterate on this idea, so we can one day propose an Astro core API. Definitely give it a try and share any rough edges you hit.