nested theme-ui providers

[RwwL]

TD;DR question: are there any potential problems/gotchas with nesting one ThemeUIProvider inside another?

EDIT: oh, hey, I had missed the existence of this Nested Providers page in the guides section: https://theme-ui.com/guides/nested-theme-providers — sounds like it's an expected usage pattern so unlikely to cause problems.

Context:

Our team has a component library built on top of theme-ui v0.16.0 that we use in multiple customer-facing and internal apps.

We have one customer-facing legacy app in production that is not a full React app but it does have certain spots where it uses standalone React roots.

We recently produced a more complex shared component, managed in its own repo and published as a package, that uses a lot of the library components, and it gets used in both the React and non-React apps. This package specifies our component library as a peerDependency so it should always be using the consuming app's specified version of the library.

We're undecided, though, if it makes the most sense to make sure this packaged component includes a ThemeUIProvider at its root or not. This would slightly simplify the integration in the non-React app, but in the React apps that already wrap a ThemeUIProvider at the root of the application, it would result in a nested provider in each place that we use this packaged component.

Interested to hear the opinions of the maintainers/community about this.

[hasparus]

Yes, nesting providers is expected, but don't overdo it. Every context provider and consumer has some impact on perf.

You also may want to use the ThemeProvider from @theme-ui/core whenever you're nesting and want to only merge contexts without any of the other setup.

https://theme-ui.com/packages/core#theme-uicore

If this component is Button or similar often used part of the design system, I wouldn't wrap it. If it's something like BugReportForm or EmailComposer which's gonna be used once, wrapping it for convenient use in your other roots is definitely a valid move.

[RwwL]

Thanks, that's a really helpful answer — our case lies somewhere in between, it'll definitely be used a bunch of times in our main React app but definitely not with the ubiquity of something like a Button. For now, I think we'll leave it unwrapped, it's not that big a hassle to create a provider for each root that needs it in the non-React app.