Post

I didn't get any credit for the `as` prop back then, which is fair since I didn't invent it. I borrowed it from a library called Semantic UI. But I'd be sad if the same thing happened with the `render⁠=⁠{⁠<⁠Comp⁠ ⁠/⁠>⁠}⁠` API. I invested a lot of time in that.

2 reposts35 likes

We already had it in Reach when I took over but I have no idea where it originated. But I did credit you in our types because I’m ever grateful for not having to figure that shit out myself 😆

not a brag, but I've been using an `element={<Comp/>}` prop in some of my stuff before I've seen _any_ library use it 🤭 although it didn't support an alternative function variant, and I actually wasn't too confident about it generally, until Ariakit and others validated it 😊

Yes, it's mentioned here: bsky.app/profile/haz.... Naming is important, though. And I believe the best aspect of this API is that it's optimized for change whenever you need it. High-level: <A> Mid-level: <A render={<B />}> Low-level: <A render={props => <B {...props} />}>

Haz@haz.dev

So, this `render={<Comp />}` API comes from the as prop, asChild, and the original render prop composition pattern, which I believe originates from React Router. Here's how I see it:

I mean, there's no need to mention me all the time or anything. Just don't let history be forgotten 🥲

Alright, before this escalates, let me clarify that I'm just thinking out loud about a minor issue. I dislike this kind of drama and would hate to be involved in it. I enjoy discussing API design and history, though. So here's a good follow-up:

Haz@haz.dev

Yeah, Semantic UI was the first component library I saw that used this prop as a core API for all its components. I created ReAs (React As) as an experiment around this (github.com/diegohaz/reas). This project eventually became Ariakit.

I have a draft blog about all the component replacement APIs we considered for Base UI and why we settled on render prop. Will give credit to the people who came up with those APIs in the post. Will post it after xmas.

i love learning about API history, would love to read how you came up with render={<Comp/>} and what were your inspirations then

No, just this particular version, which is an alternative to Radix's asChild. I believe the original render prop comes from React Router, but I'm not sure.

ahh didn't mean to be snarky 🙈 was actually just trying to sort out the concepts for myself, to know whether that would be considered a render prop and whether that was what Diego was meaning, or whether it was a sub-pattern of that overall pattern

The idea of using the `render` name was to leverage people's familiarity with the functionality. Even if the API is slightly different, they will likely understand its purpose just by reading it. Anyway, Ariakit supports the original render prop API as well (ariakit.org/guide/compos...).

i hear you, ppl replace the word radix in their vocab with shadcn, even when they completely restyle it. others copied impl details we spent ages on, but i learnt to find it flattering. the swedish have a great word for this and it contributes to why they rank so high on global happiness—Jantelagen

reality is, we don’t _know_ if our work was the inspo. render prop has been around forever & ppl often reach same conclusions through their own exploration. reach ui tried to claim credit for radix compound design for ex, but i’d built comps that way for years and had no idea reach even existed lol

i’d be surprised if they didn’t take inspo here tho tbh, but ariakit is competition for them so it prolly wldn’t be the smartest business move to mention it front & centre in such a saturated comp market—the USPs are limited haha

My concern is about quietly fading into obscurity as I hate drama. Base UI might get so popular that other libraries start copying its API, similar to Radix. I want to be remembered for my small contrib without going full Ryan. Maybe this is unfounded, and I won't feel so bad if it happens.