Little Bits of Iterative Component Design

♪♪ ♪♪ ♪♪ ♪♪ ♪♪ Hey, everybody. My name is Daniel, and I like rocks. In fact... It's a picture of me in Iceland with somebody that collected a lot of rocks. Not me. I'm a design system leader at Personia and something that I do like that is also a bit nerdy is math. I like math. Why do I like this nerdy thing? It's because in some way, it's a very exact science and I like that there's usually an optimal solution to everything we do. I guess software engineering... Yeah. There's so many opinions, always. There's many ways to solve a problem.

For example, let's say we wanted to build a drop-down component like this one. One way to build it in an API is to make it with props. I have the props have label. This is simple, and I think most engineers will use this because I feel that engineers like props. It's just very direct. The next possible way could be composable components. You could have this drop-down, have these sub-components and then just put them together. What's really nice is that you can mix and match them. I'm seeing this more often in design systems. Which one is better? Which one do you think is better? Senior engineer answer would be, well, it depends. Right? Let's analyze. Props are really good with TypeScript. When I'm writing it, it's really nice to see what's happening. I need to put a value here and then, okay, it appears. You can easily, on the fly, understand it. On the other hand, composition... You could have other types of components. You could create other types and put them and still work.

Let's say I want to wrap it in a tooltip. I can do that. It will still work. You can see that there's a lot of mixing and matching happening. On the other side, with the props, it will be a bit difficult. You end up creating these huge objects to be able to get the same thing. You can see a bit of the differences in approach. What I mean by this, there's always pros and cons, even on the little things. Also, on the big things, there's a lot of pros and cons.

If anybody knows, this is a masonry layout. Recently, there's a CSS masonry API proposal. This is the discussion that's happening between Apple and Google on what is the best API for CSS masonry. It's just a lot of edge cases to handle. Even bigger situations have trouble deciding what's the best API for work. We go back. Software engineer has a lot of answers. What kind of strategies can I use as an engineer for making my own decisions? One that I know and probably you all know is this one called YACNI. You hear YACNI there, YACNI that. Whenever somebody asks you why this is happening, you can just tell them YACNI. For those that don't know, YACNI means you ain't gonna need it. You just build exactly what you need and just ship it. You just ship fast, really, really fast. Your performance review comes out really exceptional. As you guessed, over time, this creates tech debt.

One example of using YACNI on this simple component that has an icon is now I need a flag, I add a flag prop. Now I need some error and a warning and a color maybe, and I need to add a tooltip and then have some boolean for some special situation so that this component behaves well. You can see that this ends up being a Frankenstein component over time. If you make a little bit of effort and make this reusable, it can go a long way in terms of API. For example, this component could have an accessory that can receive flags, icons, and other stuff that not only does, and the colors could be semantic. And we can have a reusable tooltip component that can be used in other areas as well.

And then the special situation that you want to handle just handling outside. So why should we care about this? At some point in my career, I was using a lot of YACNI and I started to work at Shopify in an open source project and I started to care about the APIs that I released because they are supposed to enable people to do the things they want to do and if it doesn't happen, then it's really sad. And now I work at Personio. It's the same with design systems. It's figuring out how can I make the API to work well. The problem as well is that if you make an API that is not good, there's a cost to it. It's really difficult to roll back. Your peers get extremely frustrated and you look bad.

So for example, UseEffect is an example of an API that a lot of people get frustrated. Imagine trying to remove UseEffect from your code base. That's going to be pretty difficult. So you can see how once you create an API it sometimes sticks forever. So how can I make good APIs? I tell myself. Let's see some of the big ones. TC39, they are the group that's actually creating the new JavaScript APIs. Just like AsyncAwait. So they go through a really big process because they want to make sure that the API is good. They have an idea, a proposal, the draft, so many things. They released AsyncAwait and they took four years to finish that. We don't have that time. When we are building APIs, we are not going to just wait four years. We are going to get it out. Let's say that we probably want to do APIs between Yagni and TC39, somewhere in between. I made my own process that I call iterative component design where I try to figure out what is good enough for a release before putting it out. Let's just go through it really quick. The step one is to prototype. When Remix got acquired by Shopify, we started to build all these e-commerce components on top of Remix. As soon as I started to do Remix, you realize that they have a concept of loaders and other concepts that are not normal React. Basically without prototyping, it's difficult sometimes to understand how the technology can be used for the API you're building. A lot of engineers just prototype the first thing and release it.

And this is, again, doing Yagni. I think you can have better APIs if you follow a proper process. Second step, I usually write an RFC. What this means is like this one, this is a card RFC. You write exactly what you're going to do. When you do this, you realize what parts of your API sound really weird to explain. And that's usually a code smell that something is funny the way you're explaining things. You could go back and iterate on here.

And the final step here is to share. It's the third step. And sharing is difficult because sometimes we have pride as developers and we don't want to take feedback and we just want to release immediately. But the problem with not getting feedback is that when you're working with a problem, what happens is you're looking at it so close that you are unable to see objectively anymore. It's like when you paint and you think your paint is looking great but then you look after and it's not so great. I thought it was something like that. Sharing is good.

For example, the React team, they had the React compiler, they do early releases. They share with everyone what they're going to do even if we don't like it sometimes. So once we get enough confidence, it's good enough, we iterate on this and then we release the component, we can celebrate finally and then sail into the sunset. But wait a minute. Has this ever happened to you when building APIs? Spoiler alert. All the APIs, there's never a state of nirvana for APIs. There's always feeling like something is not right, something is broken here. All my time working, I felt that we never got there and probably we will never. So all you can do is probably enjoy the process of creating APIs. And that's my final advice. Thank you. That's my link three, I don't know what it's called. Keep in touch. Bye.