I got curious about implementation because of padding.

Specifically the fourth message in a thread about whether a card’s inner spacing was 16px or 20px. I have had some version of that conversation on every project I have worked on, along with the ones about type scale, and border radius, and which grey. All of them cost a lot of time, for designers and developers both.

We make those decisions in design. They get translated in code, and translation is where they go missing. I wanted to carry one all the way through, so I decided to explore React.

Early in the docs there is a page called “Thinking in React”. I opened it braced to be lost, and spent most of it recognising things. It lays out five steps for turning a design into working code. Three described work I already do. The other two were new, and those two are most of what I have to say.

Three of the five were already the job

The docs open by telling you to break the interface into a hierarchy of components. Decide what’s a component, what nests inside what, where the line falls between a card and the list it sits in.

That’s the layers panel. I have been doing it for years and calling it organising my layers.

Then they tell you to build a static version first. No data, no behaviour, everything hard-coded, and resist adding interactivity until the static version holds up. That’s the Figma file. Designers get that discipline for free, because the canvas puts that constraint on us.

Here’s the part that actually stopped me. I have a button in our library with three properties. Size, state, and a switch for the leading icon. Set those three and you get the button you need. Turns out that is what a component’s props are. I had been building those for years, knowing someone else would pick them up and use them.

Some of that overlap is deliberate. Figma’s slots, the areas inside a component you can fill without detaching the instance, are the same idea as children in React.

However, what escaped me was the cost. On the canvas, adding a fourth property is one more frame. In code it multiplies against everything already there, and someone has to hold that arithmetic in their head every time they touch the file. That’s why the answer to “can we just add one more variant” is slower than it looks from my side.

The canvas has no time

There’s a page in most of my files where I start building my components, and it is mostly just states. Default, hover, loading, empty, error. All side by side, all equally true, none of them in each other’s way.

That’s the canvas doing what it does. There’s no time on the canvas and no data, so nothing ever has to be responsible for anything. Everything is simply true, forever, all at once.

I have found that React can’t do that. It shows one thing at a time, and something has to decide which. So it made me ask myself something about that page I had never had to ask. Which of these are real, and which ones are just what happens when something else is true?

Our empty state is the results list with nothing in it. If I let it become its own thing in code, I have built a second way for it to be empty, plus a bug for the day the two disagree. Loading is real, and it belongs somewhere else again, with whatever is doing the fetching.

Then comes the part with no canvas equivalent at all. Once you know what the real states are, something has to own them, and the owner sits above whatever you’re looking at.

Take a filter panel and a results list. On my canvas they’re siblings, sitting side by side, neither one inside the other. So when someone picks a filter, where does that choice live? The list needs it as much as the panel does, so it moves up to the nearest thing holding them both, and gets handed back down to each.

That has a name. Lifting state up. The vocabulary was new, and the instinct is one designers already have, because it’s the argument we have about tokens every time someone hardcodes a hex. One owner, everything else pointing at it.

Which, it turned out, is also the padding thread. That argument happens because the number lives in two places, my file and their code, with neither one pointing at the other, so both stay true until somebody notices they disagree. Dabbling in React made me ask who owns this often enough that I started asking it about my own files.

Thinking it isn’t writing it

The title of this post only goes so far, and this is where it runs out. I can look at a screen now and work out the hierarchy, sort the real states from the ones I drew, and tell you roughly where that filter choice needs to live. Then I open an empty file and none of it types itself.

The styling I can handle. That’s the CSS talking, and it’s the part that carries over most cleanly, though I gather it stops carrying the moment I get to React Native, where there’s no cascade and styles are just objects sitting on the component. Everything else is a skill I am still paying for. The syntax, the hooks, the six ways to do one thing and the opinion my codebase has about which one.

So should you learn it?

If you want to build what you design, then yes, and you are starting further along than the docs assume. The component thinking is already yours. What you are buying is the part about time, which the canvas never asked you to think about, and then writing the code itself.

That half shows up in real work more than it sounds like it would. When developers plan a build, one of the first things they settle is which parts of a screen are real and which fall out of something else, which is step three of that docs page happening in a meeting instead of a tutorial. I watched two experienced developers do it on a call recently, taking a design apart into components and deciding where each part got its value from.

You can run the same pass on your own work today. The react.dev page runs in the browser with editable examples, so there is nothing to install, and it builds one small thing across the five steps. Read it with a few of your own screens open beside it. Take one you have drawn several versions of, the empty one, the loading one, the error one, and ask the same question of it.