Export Root context hooks for better composability

[adityaa72]

Feature request

Summary

Expose Root context hooks for Base UI components to allow developers to access internal component state and behaviors when building custom subcomponents.

Currently, many Base UI components manage their state internally through a Root provider (e.g. open, value, active item, disabled, etc.), but the corresponding context hooks are not publicly exported. Providing access to these hooks would enable advanced composition while still leveraging Base UI’s built-in logic and accessibility features.

For example, hooks such as:

• useCheckboxRootContext()
• useSwitchRootContext()

would allow developers to build custom triggers, indicators, animations, or wrappers that interact with the component state.

---

Motivation

When building real-world applications or internal design systems, developers often need to:

• Create custom triggers or controls
• Add custom animations or transitions
• Build design system wrappers
• Access state such as:
  • open
  • selected value
  • active item
  • disabled

Without access to the Root context, developers may need to:

• Re-implement component logic

Exposing official context hooks would improve:

• Composability
• Extensibility
• Developer experience
• Design system integration

while still keeping the internal implementation consistent and accessible.

[linear]

BAS-467

[oliviertassinari]

Can you provide one example where it's needed?

[adityaa72]

Yes,

I need state in checkbox indicator to animate indicator with motion.
States such as checked, intermediate are required in indicator.

export const CheckboxIcon = () => {
  const { checked, indeterminate } = useCheckboxRootContext();
  return (
    <motion.svg
      animate={checked || indeterminate ? "checked" : "unchecked"}
      fill="none"
      initial={false}
      stroke="currentColor"
      strokeWidth="4"
      viewBox="0 0 24 24"
      xmlns="http://www.w3.org/2000/svg"
    >
      <motion.path
        d={indeterminate ? "M5 12h14" : "M4.5 12.75l6 6 9-13.5"}
        strokeLinecap="round"
        strokeLinejoin="round"
        variants={tickVariants}
      />
    </motion.svg>
  );
};

You can also see this Animate UI Checkbox

Similarly it will also be used to render indicator with children as function receiving states.
There can be pattern such as

<Checkbox.Indicator>
  {({ checked }) => {
    return checked ? <SunIcon /> : <MoonIcon />;
  }}
</Checkbox.Indicator>;

---

While many of these use cases can technically be achieved by making the Root component controlled, doing so when building custom slots or public components requires re-implementing internal logic.

For example, developers need to manually:

• Manage controlled/uncontrolled state using useControlledState
• Create a new context to share that state
• Reconnect the custom slots with that context

However, this logic already exists internally in Base UI. If Base UI exposed the corresponding Root context hooks, developers could reuse the existing state and behavior instead of re-implementing it.

Providing these hooks would make it much easier to build custom compositions and design-system abstractions on top of Base UI while still relying on the library's internal state management.

[mj12albert]

I need state in checkbox indicator to animate indicator with motion.

This is already possible, the recommended way is using the render prop where the state contains all the state that you would need:

<Checkbox.Indicator
  keepMounted
  render={(props, state) => (
    <motion.svg
      {...props}
      animate={state.checked || state.indeterminate ? "checked" : "unchecked"}
      fill="none"
      initial={false}
      stroke="currentColor"
      strokeWidth="4"
      viewBox="0 0 24 24"
      xmlns="http://www.w3.org/2000/svg"
    >
      <motion.path
        d={state.indeterminate ? "M5 12h14" : "M4.5 12.75l6 6 9-13.5"}
        strokeLinecap="round"
        strokeLinejoin="round"
        variants={tickVariants}
      />
    </motion.svg>
  )}
/>

For checked ? <SunIcon /> : <MoonIcon /> see this demo: https://base-ui.com/react/components/toggle

@adityaa72 Do you have a use-case where this isn't sufficient?

[adityaa72]

Thanks for the explanation. You're correct that this is possible with the render prop, but there are still use-cases where context hooks provide a better developer experience.

The render prop only exposes state within the render callback. This makes it difficult to build reusable components that consume the component state elsewhere in the subtree.

For example:

function MenuAnalytics() {
  const { open } = useMenuRootContext()

  useEffect(() => {
    if (open) track("menu_open")
  }, [open])

  return null
}

Usage:

<Menu.Root>
  <Menu.Trigger />
  <Menu.Content />
  <MenuAnalytics />
</Menu.Root>

With the render prop approach, this logic must live inside a slot render function instead of an independent component.

While this could technically be implemented by using a render prop on Menu.Root, it would require restructuring the component tree and moving unrelated logic into the render callback, which makes reusable abstractions and separation of concerns harder.

---

Another advantage of consuming state through context is that it keeps component composition simpler.

For example, your suggestion works well when the logic stays inside the render callback. However, in many cases we want to compose custom components directly as children:

<Checkbox.Indicator keepMounted>
  <MyCustomIcon />
</Checkbox.Indicator>

Where MyCustomIcon can internally read the state:

function MyCustomIcon() {
  const { checked, indeterminate } = useCheckboxRootContext()

  return checked || indeterminate ? <CheckedIcon /> : <UncheckedIcon />
}

This allows the component tree to remain declarative while keeping the state-dependent logic inside reusable components.

With the render prop approach, the logic must remain inline in the render function, which makes extracting reusable components harder and couples the implementation more tightly to the slot.

[mj12albert]

We don't support this in favor of the render prop

<Checkbox.Indicator keepMounted>
  <MyCustomIcon />
</Checkbox.Indicator>

For the other cases like "MenuAnalytics", you should use controlled mode

We may consider providing context access in the future, but IMO it's unlikely we will do so in v1

[adityaa72]

Thanks for the clarification and discussion.

I understand the render prop approach works for many cases. I wanted to share the scenarios where context hooks could provide a cleaner composition and allow reusable components to consume the state without relying on slot render functions.

If this doesn't align with the design goals of Base UI, feel free to close the issue. I just wanted to document the use case in case it becomes relevant in the future.

[CiscoFran10]

Just adding some context for future consideration, since I noticed a similar pattern while looking at the upcoming Calendar component work and thought it was relevant to this discussion.

In Calendar, the current approach is to expose Calendar.useContext() inside the subtree so custom parts can read state like visibleDate and call actions such as setVisibleDate().

That seems related to the feature being requested here. If this kind of API is ever considered in the future for other components, a similar context-based approach could be one way to support those composition use cases.