Don’t require <astro-root> for client directives.

[jonathantneal]

I like Web Components. I’ve been slowly trying to carve out a space for them in Astro. ^{1 2 3 4 5}

Of maybe two roadblocks left; one of them is <astro-root>.

What is <astro-root>?
— Strawman

<astro-root> is an element that wraps any component using client directives.

Why is there an <astro-root>?
— Strawman

The <astro-root> element exists so that frameworks needing a container for hydration get one.

Do Web Components need an <astro-root>?
— Strawman

No, Web Components don’t need an <astro-root> container at all.

Then why do Web Components get <astro-root> anyway?
— Strawman

Web Components get <astro-root> because Astro forbids components from automatically hydrating themselves. To hydrate a component, we have to add a client directive. And when we add a client directives, the component gets the <astro-root> wrapper.

Am I convinced this is a problem?
— Strawman

Yes.

Listen, the <astro-root> element can be helpful to frameworks like React and Vue, but it’s not helpful to frameworks like Lit, Atomico, or... the web platform. See the unnecessary <astro-root> in framework-lit.

I’d like to change renderers so <astro-root> is optional.

AFAIK, there isn’t resistance to this.

Allowing renderers to control when hydration occurs would allow them, on purpose or not, to defy the directives and load in a different way. I think this would be a big mistake for us. Plugability is a feature, but not the primary one, of Astro. astro-root though, is something we could solve in another way, without an RFC, just by knowing that the type of renderer being used doesn't need one of those.
— withastro/astro#1766 (comment)

[matthewp]

I don't think the premise here is quite right. The <astro-root> element exists because in many frameworks (such as React), a component can be a fragment, meaning there is no single root element. We tried to implement hydration without <astro-root> but couldn't quite figure it out. Happy to revisit that implementation if there's another way to do it.

For custom elements there is a single root element. It's possible (even likely) that some other non-WC frameworks also require a single root element, in which case astro-root wouldn't be needed there either.

I think this is simply an implementation detail we can change without an RFC. We can have a flag on a renderer, something like fragment: true/false that is used to indicate if astro-root is needed (defaulting to true for backwards compat). Then we can set fragment: false in the Lit renderer (and any 3rd party renderer that doesn't need the astro-root can as well) and make it so astro-root is not used.

[jonathantneal]

Excellent. You’ve mentioned before that this might not need an RFC, but it wasn’t clear to me before how I wouldn’t end up in the same rut. The fragment idea was the missing piece.

A nit:

I don't think the premise here is quite right. The element exists because...

The premise states that <astro-root> exists to serve 'frameworks needing a container for hydration'.

... in many frameworks (such as React), a component can be a fragment.

This is why <astro-root> exists, correct? I think we’re in accord here, but maybe talking about it from different perspectives?

[matthewp]

Yeah we are in agreement on that, but I read from your initial post that <astro-root> is related to a renderer's inability to control its own loading. This is the part I don't agree with, we can get rid of <astro-root> when its not needed without handing over loading to renderers.

Web Components get <astro-root> because Astro forbids components from automatically hydrating themselves.

This is the part I was commenting on. I should have quoted it directly in the first place, sorry for the confusion.