Ordering composition with css prop

[tavoyne]

I'm working on a Slot component that passes down props to children.

Implementation looks something like that:

function Slot({ children, ...rest }: React.HTMLAttributes<HTMLElement>) {
  return (
    <>
      {React.Children.map(children, (child) =>
        React.isValidElement(child) ? React.cloneElement(child, rest) : child
      )}
    </>
  );
}

Example usage:

export default function App() {
  return (
    <Slot css={{ color: "red" }}>
      <p css={{ color: "blue" }}>Hello</p>
    </Slot>
  );
}

The problem here is that the styles attached to the Slot element takes precedence over the ones attached to the children. In other words, the above code results in a red text.

I know this is by design as, from @emotion's perspective, the <p> element seems to have been styled before the Slot element, but I want to know how I can revert this behaviour in my Slot implementation (i.e. for the text to be blue)?

CodeSandbox link

Thanks a lot 🙏

[srmagura]

Legitimate question and unfortunately I do not know the answer.

I may be playing devil's advocate here, but is this complex code truly necessary for your use case? Been doing React professionally for 5 years and have never used cloneElement.

[Andarist]

In the case of this Slot it, indeed, seems like to child prop "wins":
https://codesandbox.io/s/fragrant-night-2lptvi?file=/src/App.js

And it's an explicit decision:
https://github.com/radix-ui/primitives/blob/4ee9d362fcd5e32edbce9f43f1d41f1bf1a015c1/packages/react/slot/src/Slot.tsx#L80

I'm not sure though how we could support the inversed priority order in Emotion.

it's the most elegant way to build type-safe polymorphic components

It might be elegant... but I don't see how this is type-safe. Slot has no idea (at the type-level) what kind of a child it receives and thus Slot's props type can't take the type of those props into account. Slot is not generic so it only accepts a narrow set of HTML attributes:
https://github.com/radix-ui/primitives/blob/4ee9d362fcd5e32edbce9f43f1d41f1bf1a015c1/packages/react/slot/src/Slot.tsx#L8-L10
but since it accepts them... we can render an unsafe tree, like here:
https://codesandbox.io/s/focused-water-3r4pzi?file=/src/App.tsx

[tavoyne]

Slot has no idea (at the type-level) what kind of a child it receives and thus Slot's props type can't take the type of those props into account.

That's absolutely true, but that's not a problem. The Slot component indeed only accepts the narrowest set of HTML attributes (React.HTMLAttributes<HTMLElement>), but you can pass element-specific (e.g. a, button) attributes to the child element itself.

For example:

<Button variant="contained">
  <a href="#">Hello</a>
</Button>
<Button variant="contained">
  <button onClick={() = {}}>Hello</button>
</Button>

A proper generic (with a traditional as prop) is too resource intensive (read this) and in the vast majority of cases not even needed.

I agree that @radix-ui's implementation is not perfect, that's why I'm writing my own.

[tavoyne]

The only alternative is some kind of render prop, but I personally hate it as it kills composition, IMO.

[tavoyne]

but since it accepts them... we can render an unsafe tree, like here:
https://codesandbox.io/s/focused-water-3r4pzi?file=/src/App.tsx

That's a fair point, not sure how we can prevent it.

[tavoyne]

After some consideration, I abandoned the whole Slot idea. You were absolutely right, @Andarist, on the fact that it's not 100% type-safe.

I ended up setting up a classic render prop and using the ClassNames component from @emotion/react. Everything works great, including composition. Here's what it looks like: https://codesandbox.io/s/crazy-diffie-2kvyqw.

Thanks a lot for the various examples you provided and for maintaining this fantastic library.

[Andarist]

This is mentioned in the docs: https://emotion.sh/docs/css-prop#style-precedence

Note that css gets translated to className within the jsx pragma - so this section of the docs describes your situation at hand.

[tavoyne]

Thanks for your reply. As I said, I understand that the behaviour I'm observing is the expected one. But I'm wondering if there's any way to reverse the style precedence? I don't see that mentioned in the linked article.

[Andarist]

The only way to change this would be to reverse it on your own:
https://codesandbox.io/s/misty-morning-qnwu7n?file=/src/App.tsx

But this only works if the cloned children have css directly on this element. This won't work when you can't "observe" its value.

[tavoyne]

Brilliant! Thanks so much.

[Andarist]

Just note that this can break really quickly:
https://codesandbox.io/s/headless-hooks-968ej0?file=/src/App.tsx

[tavoyne]

Actually, I just noticed that it doesn't merge the styles...

https://codesandbox.io/s/funny-smoke-q93jgl