Radix themes with Astro

[thebrownfox]

With some components I get useThemeContext must be used within a Theme.

Here's reproducible example: https://stackblitz.com/edit/github-uiu4in?file=src%2Fpages%2Findex.astro

[thebrownfox]

For future reference, it's how astro works. You cannot use react context within multiple astro islands.

When building an Astro website with islands architecture / partial hydration, you may have run into this problem: I want to share state between my components.

UI frameworks like React or Vue may encourage “context” providers for other components to consume. But when partially hydrating components within Astro or Markdown, you can’t use these context wrappers.

Astro recommends a different solution for shared client-side storage: Nano Stores.

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

[vladmoroz]

@thebrownfox are you saying features that rely on Theme context won't work in Astro? Not sure I'm seeing a workaround there

[thebrownfox]

@thebrownfox are you saying features that rely on Theme context won't work in Astro? Not sure I'm seeing a workaround there

Yes. I can see there could be some workarounds.

1. framework level - there'd be some abstraction that would allow sharing state on higher level
2. nested theme elements using one state for configuration (wrapping every component that needs the context, which is not pretty)

[tresabhi]

I see two things that need to happen for Themes to work with Astro:

1. Theme should be interpreted solely by CSS & classes such that all children can refer to the closest Theme component styles without the need of context. In most places this already works which is why you can use Radix in fully static websites. I don't see why we can't ditch contexts within Theme.
2. Portals mount in the closes Theme ancestor so that the contents enjoy the styles of the theme instead of mounting in the body where there's no themes at all. I'm unsure why this isn't the default behavior already. It makes total sense to mount to Theme instead of duplicating the properties of Theme in the new portal.

In my opinion these are very reasonable things that should already be in Radix Themes.

Contexts should've never been used across components; only a composition of a component makes sense to be using a context (Popover.Root and Popover.Content makes sense but Theme and Popover.Content should be 100% CSS driven).

And mounting to closest theme Theme would allow for things like small windows with their own themes and popups that don't cover the whole screen but just the window. And it'd stop requiring the use of a context as you no longer would have to duplicate the Theme.

Some people like to mount Theme within Theme to override the theme in certain sections of the website. I suppose in that case we can have a portal discriminator. What I mean is <Theme portalable> will be the one to receive the portals and not the sectionally overriding Theme within.it. And once again, no context needed; we can just querySelect.

[chaance]

Not really an issue on our part since Radix Themes relies on context by design, and that only works in a single React root. We have no plans to change our design at the moment, but I'll move this into discussion to keep the conversation open in the future.