Building a Custom Component Library – Fast

Hi everybody. I'm TJ, and today I want to talk to you about building custom component libraries fast. And by component libraries, I essentially mean a series of UI controls that can be anything from buttons and inputs to more complex things like daypickers and autocompletes.

Now, me personally, I've been building component libraries like this for a long time, maybe too long. Back in the day, I was a member of the jQuery UI team, if you remember that. I still have this sweet hat to show for it. And more recently, I'm now a member of the KendoUI team. And because I've been doing this for many years, I've developed a series of opinions or hot takes about component libraries that I'm going to start by sharing, because I think you'll find them interesting and also useful.

And then I'll move on from that to show how you can put these things into action and give you some recommendations on how you can build your own component library. So to start, my first sort of opinion or hot take is that I think every company, I think your company should have its own standard set of UI controls. And the reason for this is really consistency. So you apply some visual consistency so that instead of having 30 different button designs, you create a button in a component library that sort of has the one true way of building buttons for your organization. But you also get consistency in terms of things like technologies. Say a component library is sort of a forcing function to choose, help you choose a limited set of text that you want to push out and sort of promote throughout your organization. You also get consistency in terms of accessibility. Accessibility can be hard, but if you can get it right within the components within your library, you can sort of then spread those accessibility benefits to other parts of your organization. So I think every company should have its own UI component library.

And I also think that companies shouldn't build the harder parts of those libraries themselves. And by complex components here, I'm not talking things like inputs and buttons. I'm talking about the harder stuff. The date pickers, combo boxes, auto-completes, data grids, things like that. Because these components are harder than they might first seem. So take the date picker for example. And you don't just have to build a calendar here. When you're building a reusable component, you have to take into account all sorts of other things. How are you going to make this accessible? How are you going to make sure it works like you expect on mobile, that TypeScript works, that you're going to document all of this so other people understand what you did and that it's extensible and all of these things. And these are solvable problems. You watching this, I can see it through the camera. You are a smart person. These are problems you can solve.

But you as a software developer, also your time is very valuable. Your time is almost always better spent on things that are unique to whatever it is your business is doing, than reinventing the wheel and solving some of these UI component problems that have been solved by a lot of libraries for a long period of time. It's just a better use of your time.

So I think companies should have their own component libraries. I think you should not build the harder parts of these libraries yourself. And I also think that you should lean towards using components that are specific for a framework that you like to use, like a framework like Angular, Vue, and React, than a framework that's sort of framework agnostic and tries to work across the board.

Now, this is a hot take that I share with Brandon Dale, an ex-member of the React team. I think he phrased his explanation more elegantly, so I just stole a quote from him. He says that compatibility always comes at a cost, and that cost is always going to be something like performance or bundle size or framework ergonomics. And in the majority of cases, those things are going to be more important than the compatibility itself.

Now, this is something we believe quite strongly on the Kendo UI team, so strongly, in fact, that we've built four separate component libraries for different frameworks. And we do this because, as you might imagine, it's quite a bit of work because our users consistently tell us that they are more successful, they are more productive when they use components that are built for their framework of choice specifically.

So I think companies should have their own standard set of UI components. I think they shouldn't build the harder parts of that themselves. And I think that, in most cases, you should lean towards using components that are built for your framework, for your tool chain of choice.

So how do you take these things and put them into action? Well, I recommend starting by just setting up a development environment that you can use to build components in a place that lives outside any of your existing apps. So what I like doing is I like to have an environment where I can both develop on the components and then also have a demo application where I can then test those components in a live running app and see how they work. And then also having a few scripts that let me take my components when I'm all set with them, package them up, bundle them up, and distribute them so that they can be used throughout my organization. And I'll give a link, if you're interested in this, at the end of this talk, so that if you want to see my preferred workflow in detail, you can walk through that. But just start by having this development environment.

And from there, I would then recommend having a go-to library that you're going to reach to for some of these more complex widgets or really anything that you don't want to build yourself. And for that, I would look for a handful of things in this third party library. I would start by looking for comprehensiveness. You don't want to be pulling components from five different places throughout the Internet and trying to make them together. Usually you'd have one library that provides as much of this as possible. You want to look for accessibility because, again, you want to bake in good accessibility to your components by default. You want to look for framework-specific components or at the very least something that works really well with the tool chain that you like using. And you also want to look for extensibility. The thing about a component library is that people are going to find ways of using your components in a lot of different ways. So you want to find third party components that are very adaptable that you can tweak and theme and change things about every little piece of them.

So I'd recommend having this third party, this go to third party library. And then I'd recommend creating wrappers of any of the components that you want to use from these third party components. And the reason for that, and we'll just show an example. So you want to use the kendo react date picker. Well, instead of encouraging developers to use the kendo react date picker API directly, instead in your component library, you could create a wrapper of that date picker with your own API. And the reason for this is again, to enforcing consistency, because you have this wrapper, you now have a place that you can consistently implement things for date pickers throughout your organization.

So say your designers come back and say, Hey, we need all our day pickers. We need a small little visual tweak, we can be like, Oh, Hey, I have this wrapper. I can consistently apply this class name. I can make some CSS tweaks. And I have still have this control where I can consistently make changes to this component throughout my organization while still not having to build the hard part of these components themselves.

So to wrap up again, I'd recommend starting by just setting up a development environment, make it outside of your existing applications. From there, I choose a go-to library for building or for bringing in third party, more complex components. And then I create wrappers of these third party components that you bring in. And really, if you take just one thing out of this talk, in general, I would say your company should have a standard set of UI components. There are just a ton of benefits, but it's totally okay, perhaps even preferable to build a lot of that, a lot of that functionality on top of an existing library.

So hopefully you found this interesting. If you did, if you want to learn anything more, you can head to bitly slash components dash fast. There, I have the full development environment that I talked about on an earlier slide, as well as some articles that walk through the arguments I made here today in quite a bit more detail. So my name is TJ Ventol. Feel free, if you want to reach out on Twitter desk, any questions or ask any questions through the conference as well.