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

[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.

[cmawhorter]

There are some other comments here that overlap a bit, but I think it's worth re-stating the issue: Despite the title, this has nothing to do with astro islands or sharing state across components (in astro parlance).

This issue is more about astro template syntax and how it works in conjunction with the underlying integration renderer, which in the case of OP and me, is astro/react.

Tabs is technically separate components as far as astro is concerned but as far as I'm concerned, it's just one:

---
import { Tabs } from 'whatever';
// Leads to errors because Tabs.List expects to be contained within Tabs.Root, etc.
---
<Tabs.Root>
  <Tabs.List>
    <Tabs.Trigger>Tab Title</Tabs.Trigger>
  </Tabs.List>
  <Tabs.Content>Tab Content</Tabs.Content>
</Tabs.Root>

There just needs to be a way to tell astro render this fragment altogether as one thing. I think what people are actually after here is something like this:

---
import { Tabs } from 'whatever';
---
<RenderFragmentTogether>
  <Tabs.Root>
    <Tabs.List>
      <Tabs.Trigger><slot name="label" /></Tabs.Trigger>
    </Tabs.List>
    <Tabs.Content><slot name="content" /></Tabs.Content>
  </Tabs.Root>
</RenderFragmentTogether>

Of course, that's still of very limited usefulness since obviously, you'd want to pass N label/content combos... but that's another issue, I guess.

The prevailing suggestion of "create an astro wrapper" I think demonstrates the issue isn't well understood, and I'm hoping this provides some clarity.

[matthewp]

Yes, thanks for bringing up this point. There really are two asks here:

1. What you are suggesting, somehow make the templating be framework specific in parts of it.
2. Share context in islands.

You are referring to (1). I'll say that what you're asking would be extremely difficult to pull off without simply converting all of Astro to become to React JSX. It seems probably impossible to do it framework agnostic.

I know it sounds reasonable on the surface, but Astro syntax is Astro syntax. Even your suggestion of "render this fragment altogether" is not actually happening in your example: <slot name="label" /> is not React syntax, it's Astro.

What you're really asking for, I think, is to partially render this block but don't render the components (we'll pretend like inserting an Astro component in here is not allowed) and then later wrap the components inside of another (in your case React) component.

Doing this in a renderer agnostic way seems very challenging to me, because most of the work is done inside of the renderer. But it's probably not impossible.

I think to have such an API, you would want something like your <RenderFragmentTogether> that acts like a sort of compiler mode switch, so that the insides compile to something else. Currently component calls all compile to a renderComponent function, but here they'd need to compile to a renderBlock or something.

Like I said, this seems pretty challenging, but not necessarily impossible. You'd probably not be able to have "render props" that are React. Hopefully that is not a problem. If someone wants to take a crack at this idea but submitting a PR that would help determine if it works well enough to warrant inclusion.

[cmawhorter]

What you are suggesting, somehow make the templating be framework specific in parts of it.

Yes, sortof. The suggested astro way to handle this type of thing is to create an astro wrapper for the component's particular implementation on a page:

---
import { IHaveTabs } from './_IHaveTabs';
---
<h1>I have tabs pages/i_have_tabs.astro</h1>
<!-- many components wouldn't require client:load but OP's example probably would -->
<IHaveTabs client:load />

Of course, you could make that wrapper component more generic/reusable by accepting props (e.g. Props { tabs: Tab[] }), but I've found that to be more trouble than it's worth and I end up with needing consider and maintain two component interfaces.

I guess my question is -- and I know this is a big question -- why does astro require that second file?

Based on my entirely ignorant understanding of astro internals, it seems like this would be solvable in a framework agnostic way if there were some way to treat stuff within an astro template as though that second file existed. So yes, framework specific parts, but in my mind that makes it sound more complex than what I'm after.

TBH, I think I'd be mostly happy if <Fragment> somehow accepted a render function and allowed me to inline the IHaveTabsComponent content so it exists in the same file as its usage:

<h1>I have tabs</h1>
<!-- 
i'm not familiar with the other frameworks astro supports, but i imagine 
you could get syntax highlighting and all that working for them with this? 
-->
<Fragment framework="react" client:load>
  {() => (
    <>
      I'm not IHaveTabs, but I do the same thing and astro can think of of as _IHaveTabs.tsx internally if it wants
      <Tabs.Root>
        <Tabs.List>
          <Tabs.Trigger>I</Tabs.Trigger>
          <Tabs.Trigger>Have</Tabs.Trigger>
          <Tabs.Trigger>Tabs</Tabs.Trigger>
        </Tabs.List>
        <Tabs.Content>One</Tabs.Content>
        <Tabs.Content>Two</Tabs.Content>
        <Tabs.Content>Three</Tabs.Content>
      </Tabs.Root>
    </>
  )}
</Fragment>

I just find myself side-stepping all this (and losing half of astro's features) by making my page.astro a thin entry to a client:load react component that actually does all the work. This is better in terms of DX than creating all those wrappers and has been the best bad path I've found, but still results in two files for every page and some ugly file structure.