React and TypeScript, v2

Polymorphic Components

Steve Kinney

Steve Kinney

React and TypeScript, v2

Check out a free preview of the full React and TypeScript, v2 course

The "Polymorphic Components" Lesson is part of the full, React and TypeScript, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Steve shares a couple of use cases for creating polymorphic components that utilize a base component type system to represent common elements.


Transcript from the "Polymorphic Components" Lesson

>> So when I worked at Twilio, we had this design system paced and I was like good friends with that team. And the primitive for everything was box. Right? Box is kinda like div but everything under the hood was a box. And if some teams like well we can't use your design system cuz we need this custom thing like cool start with box, right?

And you'll see this a lot. It exists in like material UI and chakra UI. And this is super easy to implement where it's S article, right? And then under the hood, and I'll show you this code in a second. Under the hood, you can just do this little trick where it's like you've placed a tag name with whatever that was.

Right? And in a normal world like taking that and passing it to component props without ref or component parts with ref and like getting the rest of those types to come in would totally work and it can be done. And this is the question at what point do you make the call?

It can be done. However, because particularly the dom is so fast and loose, and then refs can be all sorts of different things. And a few other different children and stuff like that, which is why they were removed from functional component. Because it can be so fast. The actual I think I linked to a bunch.

Like blog posts at the bottom like a deep academic discussions on the nuances of doing it in these libraries and originally. I was yeah let's take an exploration right cuz like clearly we must do it in paste I'll just show you the simple version we will get into like the deep version cuz at one point.

I was let me go see how my buddies did it. They just hard coded all the HTML values with what they should be for like the common denominator. Cuz they're actually if you actually hovered over a section, a div and aside, they're all just base html elements. They don't actually have any special properties.

They're all boxes. So, sometimes, they didn't do all these deep gymnastics, right? They just had a list of all the properties that box supported, and it was all the common ones across that. There's a real question you need to ask yourself of, if you start nesting a like type ternary inside of another one that then flips over into a never ending one case Library code is a different story, right?

The stuff you have to do to support a wide range of generalized use cases. Absolutely. There has never been a time that I've done one of those things like when I told you that one time, I just busted out this crazy, generic and it just flowed out of me.

I don't totally remember, but I'm pretty sure I deleted that. Do you know what I mean? It worked, but, I went for a walk and a simpler, more maintainable for any junior engineer on my team version of that was the right answer. So, to the question in the chat, I think sometimes that is, that sense and that the spirit that fuels that question is I think incredibly valid, right, yeah, for if you're just mirroring a simple like button.

I use that all the time. Super helpful. We'll look at some of this but, I would say, I would tell you a cautionary tale here, right? So this is from the paste docks, right, there all boxes you can see they make you then use instead of CSS things they have their very specific properties.

Is to build you into their system so that it works with everything else. But this is what the simplest version if you just wanted to use all the standard div section paragraph, right. They have like base CSS style and that's different, but they are functionally the same is that you would basically say hey, as can be any one of these known types.

And then have it be that tag name. And then since they all have the same core set of things you can like pull it in, and this mostly works. But as you kinda get to this is what I worked out is as I was going through it, I was this is a bad idea right and kinda stopped myself right.

Because a lot of times is even though some libraries choose to just keep it a lot simpler than this. And you can go all the way, and I think that I would. Turn this more into a cautionary tale that you should probably not. Right. Can you? Absolutely. But at that point you are deep into the internals of Type Script.

I think we've wandered far just to abstract something there like the work to grab the common elements is a lot easier in that case, right? Or have two components becomes a lot easier if your goal is to build a react application. I would caution you, right? It seems good.

It seems like I should do this because abstractions are great. Except when they're not.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now