context from the parent web-component is not shared to its children | solid-element

[Waishnav]

Describe the bug

For Solid Hack 2024, I experimented with the solid-element API to convert Solid components into web components. I attempted to create a ShadCN-based web component library, aiming to make it particularly useful for the HTMX community. I saw this as a strong use case for Solid.js.

I tried porting an Accordion component to a web component, so that end-users could use it like this:

<accordion class="w-full" collapsible>
  <accordion-item value="item-1">
    <accordion-trigger>Is it accessible?</accordion-trigger>
    <accordion-content>Yes. It adheres to the WAI-ARIA design pattern.</accordion-content>
  </accordion-item>
  <accordion-item value="item-2">
    <accordion-trigger>Is it styled?</accordion-trigger>
    <accordion-content>Yes. It comes with default styles that match the other components' aesthetic.</accordion-content>
  </accordion-item>
  <accordion-item value="item-3">
    <accordion-trigger>Is it animated?</accordion-trigger>
    <accordion-content>Yes. It's animated by default, but you can disable it if you prefer.</accordion-content>
  </accordion-item>
</accordion>

However, since each sub-component like AccordionItem and AccordionContent was converted to accordion-item and accordion-content, I encountered the following errors:

Uncaught Error: [kobalte]: `useAccordionContext` must be used within an `Accordion.Root` component
Uncaught Error: [kobalte]: `useCollapsibleContext` must be used within a `Collapsible.Root` component
Uncaught Error: [kobalte]: `useAccordionItemContext` must be used within an `Accordion.Item` component

These errors are caused because kobalte expects certain contexts to be nested within specific parent components, but the web component conversion disrupts this hierarchy.

Your Example Website or App

https://studio.webcomponents.dev/edit/VcOP3wIWw9SP1xt0fMwf/src/components.jsx?file=https://srv.divriots.com/packd/@kobalte/core/accordion,@kobalte/core/combobox,@kobalte/core/select,@kobalte/core/text-field,clsx,lit-html,lucide-solid,solid-element,solid-js,solid-js/web,tailwind-merge

Steps to Reproduce the Bug or Issue

1. write a composable ui component using solid-element and solidjs's context api and store api.

2. it will throw error like this

Expected behavior

context should be shared b/w children in web components too

Screenshots or Videos

No response

Platform

• OS: Linux
• Browser: Chrome
• Version: solid: 1.9.3, solid-elements: 1.9.1

Additional context

No response

[ryansolid]

I'm gathering these are consumed top level outside of Solid's JSX. It's tricky because of upgrade timing we can't always assume the context isn't present. Solid's JSX sort of strong arms it but I don't think it completely works properly in this case. If you have an example somewhere we can see where it falls down and maybe there is a way we can patch in a certain way. It's just tricky wrangling web component lifecycles which we don't control the timing of.

[Waishnav]

If you have an example somewhere we can see where it falls down and maybe there is a way we can patch in a certain way. It's just tricky wrangling web component lifecycles which we don't control the timing of.

Thank you for your insights. Yes, the components are being consumed at the top level outside of Solid's JSX. The timing of upgrades and ensuring context presence is indeed challenging. I have created an example demonstrating the issue here. It shows the errors related to context not being shared correctly between parent and child web components.

I was thinking we could use a Context API in the global context, making it accessible to any component via a unique identifier attached to the respective parent DOM element where the context is created. I'm not entirely sure if this is the best approach, though. I’d love to hear your thoughts or any suggestions you might have for improving or patching this.

[alexgleason]

I built a small demo showing that it's possible to use Solid components in React by first converting them to Web Components:

• Demo: https://alexgleason.github.io/solid-react-demo/
• Code: https://github.com/alexgleason/solid-react-demo

I tried expanding on this by adding Kobalte components and got the exact same issue (useAccordionContext must be used within an Accordion.Root component). In my case I was trying one big component with the provider in it, so I think might be a general issue of context in solid-element, not just when broken up like that.

[ryansolid]

I was thinking we could use a Context API in the global context, making it accessible to any component via a unique identifier attached to the respective parent DOM element where the context is created. I'm not entirely sure if this is the best approach, though. I’d love to hear your thoughts or any suggestions you might have for improving or patching this.

The trickiest part is trying to link the trees so that they can see each other. It isn't global as it needs to trace up its conceptual parent, and to link it I write information via Solid's JSX compiler on to the nodes. That way when they wake up we can grab it and relink. The context symbol is global but the lookup is hierarchical by design. So even if there was a more simplistic service locator pattern here it would still break stuff like Kobalte or any library using Solid's context since it hierarchical.

So I am not sure there is much to do here realistically. Most frameworks will only let you share context within a single render root. We have expanded that so we can share it through web components assuming they are rendered in Solid (via our JSX).

In absense of that we'd need to develop another protocol I suppose maybe around native events. We could fire a custom event that passed a callback as its details. Being like.. hey I'm a Solid Element and I'm here, and when a parent Solid Element catches it passes its owner context to it so it can render itself. That way we wouldn't have to rely on JSX transform. Maybe that is a better path.