Make UI framework contexts available between islands

[danspratling]

Body

Summary

Most react based UI libraries (especially headless ones) make use of linked component nesting, where the child components rely on the parent components to exist. This does not work in astro, and the correct solution to use this kind of component are very limiting.

Previous discussion

Background & Motivation

Here's one example from RadixUI, and another from HeadlessUI.

<Tabs.Root>
  <Tabs.List>
    <Tabs.Trigger>Tab Title</Tabs.Trigger>
  </Tabs.List>
  <Tabs.Content>Tab Content</Tabs.Content>
</Tabs.Root>

In React this structure acts like slots in Astro

The proposed solution is to create a react component that wraps these react library.

// Astro
<Tabs data={data} client:load/>

// React
export const Tabs = ({tabs}) => (
<Tabs.Root>
  <Tabs.List>
   {tabs.map(tab => <Tabs.Trigger>{tab.title}</Tabs.Trigger>)}
  </Tabs.List>
  {tabs.map(tab => <Tabs.Content>{tab.content}</Tabs.Content>)}
</Tabs.Root>
)

However, this is an very limiting solution that does not provide the same level of customisation as provided by the original libraries.

Issues with this approach

• I cannot pass complex props to either Trigger or Content due to other limitations in astro - this is a huge limitation of the proposed solution

<Tabs data={{ tabs: 
  [{ 
    title: Tab 1
    content: <Form /> // This does not work in astro
  }]
}} client:load/>

• If I want to customise the content styles or element types on different pages, I have to create arbitrary components for every page/variation. This may be valid in some situations, but not always

// Default
export const Tabs = ({tabs}) => (
<Tabs.Root>
  <Tabs.List>
   {tabs.map(tab => <Tabs.Trigger className="rounded">{tab.title}</Tabs.Trigger>)}
  </Tabs.List>
  {tabs.map(tab => <Tabs.Content>{tab.content}</Tabs.Content>)}
</Tabs.Root>
)

// Underline
export const TabsUnderline = ({tabs}) => (
<Tabs.Root>
  <Tabs.List>
   {tabs.map(tab => <Tabs.Trigger className="border-b-2">{tab.title}</Tabs.Trigger>)}
  </Tabs.List>
  {tabs.map(tab => <Tabs.Content>{tab.content}</Tabs.Content>)}
</Tabs.Root>
)

^ That's a lot of unnecessary duplication for an arbitrary/one-off change, but far less important than being able to pass components as children (you could argue that this duplication would happen either way).

Goals

• Allow full support for commonly used React libraries with minimal configuration changes
• Provide support for these component libraries without creating layers of obfuscation that need to be individually managed (Astro > Tab Components > Library)
• Provide support for these components without restrictions imposed by Astro (allow other components to be passed down)

Benefits

• Allowing full support for commonly used libraries will reduce the barrier for React users into the Astro/React ecosystem
• This also provides fewer barriers for companies looking to migrate to Astro, as they can (easily) use libraries they're familiar with/trust
• Support for already built aria-friendly libraries like Radix improves accessibility for all Astro projects

[giovacalle]

The same behavior happens in Solid.js with Kobalte (as I mentioned in this issue withastro/issues/9412)

[florian-lefebvre]

@danspratling I think you could rename the proposal to something like "Make UI framework contexts available between islands"

[zhaohuanyuu]

Is there any progress? I have the same problem.

[florian-lefebvre]

No progress AFAIK

[erikdemarco]

when i read official solution regarding this problem, I'm shocked and i thought they were just kidding, slap my face and re read again. Im not dreaming. Just read it here:

https://docs.astro.build/en/recipes/sharing-state-islands/

So what they suggesting is to rebuild all popular component library like material ui, etc ourself using nano store?? all of this component library was mostly built using usecontext, even many of them just suggesting to move from Astro:

https://help.mantine.dev/q/can-i-use-mantine-with-astro

[aretrace]

Intercomponent state is a fundamental issue that needs to be solved in Astro.

[matthewp]

Any API ideas?

[florian-lefebvre]

I think that could be an option at the integration level. I guess if you want this behavior, you want it to apply to your whole project

[feelixe]

If posted this in the discord, I think an API similar to this would offer a lot of flexibility.

I'm trying to find if there's been a RFC for declaring your own island? For example if you use react components that depend on a context from parent component.
For example:

<Dialog client:load>
  <DialogCloseButton client:load />
</Dialog>

This will not work in Astro because they will be in their own islands and the close button would not find the Dialog context.

It would be nice to like make my own single island where all children goes in the same island.

<AstroIsland type="react" client:load>
  <Dialog>
    <DialogCloseButton />
  </Dialog>
</AstroIsland>

[matthewp]

Why don't you just put all of this code within AstroIsland? I thought the point of this issue is to allow it to expand seperate islands.

[feelixe]

I don't understand what you mean.