React—And Why Designers Should Care
Did you know that React was created to support the increasing importance of design in tech? Find out how this modern framework already aligns with your design workflow.
As a designer, you may be of the camp that believes coding to be an unnecessary addition to your arsenal. But before you discount every language out there, I’m here to let you in on a trade secret: React is something special.
The first thing to understand is that React isn’t about code, not really. Yes, it’s a coding library. And yes, it’s mostly used by developers. But dare I say, writing great code is not the purpose of React, nor other libraries like it. React and its siblings were created to make better design easier to build. Let that sink in for a second. Developers everywhere are doing backflips over a toolset that makes it easier to build exciting design.
“React—and coding libraries like it—reflects a major shift of priorities within the tech industry, signaling a greater support for design goals.”
Prior to React, many designers (myself included) practically gave up on trying to create new kinds of components, patterns, and interactivity. Whether we dreamed up an interface that adapted to the user, or an exciting new UI component to solve a tricky usecase, we were often told it was impossible or too expensive to develop.
But now modern frameworks like React allow us to build interfaces that adapt and move beyond traditional pages and screens. We finally get to design things that were previously off limits, or even impossible in some cases.
In short, designers need to know about React because it was created almost entirely to support our work. It unlocks all kinds of new creative potential in interfaces that were previously closed off to us. Excited to learn more? Let’s dive into some basic React concepts from a design perspective. Note: this isn’t a guided tutorial to help you code an entire app in React. But if you’re a designer looking to take advantage of React’s power and flexibility, here's what you need to know.
Core React concepts
Alright, there’s some programming jargon and code samples coming up. But I’ll keep it simple and relevant to your perspective as a designer. Keep in mind: you don’t have to understand every line of code, just consider this an exercise in observing how each concept is relatively simple to build using just a few short lines of code. If you’re already comfortable with code, this might just be the push you need to start learning a little React.
The first thing to understand is that everything on screen in a React app is part of a component. Essentially, a React app is just components within components within components. So developers don’t build pages in React, they build components. If you’re used to designing pages, thinking in this modular way might seem like a big change. Do you use a design system or style guide? Then this might not be as big of a paradigm shift as it seems.
We designers learned long ago that it’s better to create individual elements rather than designing them page by page. Building up a system of elements that can be reused across pages and views keeps product design more consistent and easier to update. Because React is component-based, it can therefore perfectly map to the elements of your design system. So in essence, designing for React actually rewards you for thinking in a modular way. It allows you to design individual components before putting together a page or view, so you fully understand each component’s scope and purpose.
State, props, and the flow of data
Now it’s almost impossible to read one paragraph about React without coming across the idea of "state management". Developers love expounding upon this topic, but at its core, state management isn’t really as complex as it sounds.
In React, each component has its own data and this data is not always shared across an entire page or view by default. That’s a big deal because each component uses its own data to determine how it will look or behave. Each component can also load its own data asynchronously. This means that each component loads its own data separately, whenever it needs to, without slowing down the rest of the page.
A component’s internal data is known as its "props" (short for properties) in React parlance. The component’s "State" is just the current snapshot of data stored in its props. The data can change over time, so techniques to manage the way that data changes become necessary to ensure the component looks the way designers want it to, at just the right time. That’s a simplified but general explanation of State Management.
In React, state can also be tracked globally and data can be shared between components as needed. Essentially, this means that in React apps, loading data in new places is not as expensive as it is with other technologies. React apps are smarter about which data they save and load, and when. This opens up opportunities to make interfaces that use data in new ways.
Think of React components like micro-applications with their own data, logic, and presentation. Each component should have a single purpose. As a designer, you get to decide that purpose and have complete control over how each component behaves and what data is uses. You’re no longer limited by the data on the rest of the page.
In your design, you can take advantage of this in all kinds of ways. There are opportunities to present additional data that can improve the user experience or make areas within the design more contextual.
Now that you’ve learned how and why a component having its own data is interesting, let’s get to the exciting part.
When a component’s data changes, React uses that new data immediately. React components can update their visual presentation automatically, based on live changing data. This is known as reactivity.
For example, if you’re designing a map app, it can listen for new traffic data and automatically adjust a commuter’s in-progress route without requiring user interaction. Or, a weather app could notify a user that it’s about to rain as soon as that data becomes available, rather than the next time they open the app. Another example is a text editing app, where users can see each other typing in real time, in the same document.
All of these things have been possible without using React. But the point is that React was built to service these exact usecases and interfaces. Before React and libraries like it, these types of features required programmers to manually set intervals that would check for new data and implement what amounted to workarounds. In essence, they had to proactively go looking for new data. React, on the other hand, is always listening.
Just as how we are learning to think in components and move beyond designing for pages, we now also need to understand that data doesn’t only emerge from a page refresh. Thanks to React, new data can be immediate, which makes interfaces faster and vastly more useful.
Now this part gets a bit more technical but it’s still worth knowing, so stick with me. A React component has a lifecycle: it can be created, mounted, rendered, and unmounted. While this is partially related to its state (its internal data), the lifecycle is a bit different. React has internal code that loads and unloads components as needed, and a component can exist in several stages of use within that internal code.
During these stages of the lifecycle, React exposes "hooks", or opportunities for more customization, when the component is entering or exiting a stage. Each hook represents a point in a time when a designer can add something new to the interface and give the user more context on what’s happening.
One of the most important hooks is when a component is essentially recycled by showing new data rather than reloading the component from scratch. This technique makes the app run faster, but it also represents a design opportunity.
The catch is that when a component is recycled, the surrounding UI elements (or the other components on the page) will still be visible, even as the component is getting repurposed and new data is loading. Previously, users had to wait for an entire page to refresh and the entire UI to redraw before receiving visual feedback. With React hooks, designers can manage how transitions between data are visualized.
So yes—you’re finally empowered to add in all those fancy spinning loading animations. Yay, React!
But seriously, while the component lifecycle might seem uninspiring at first, clever designers can do even more than simply add loading spinners. There are all kinds of creative ways to use these transitions—add personality to your brand with illustrations, animations, instructional empty states, or simply bolstering visual hierarchy. We can use the in-between states of the app to smooth out the experience and make a stronger, lasting connection with users.
React is a designers’ best-kept secret
Hopefully I’ve helped you understand how React unlocks new potential in interface design. React is obviously a deep topic, and while I’ve summarized some core concepts (while omitting some of the nuances that developers care about), this basic understanding should help you see how you can design interfaces that make use of React’s power and flexibility.
For more inspiration on how you can leverage React features, browse some examples of designs created for React using Framer X here. Or continue your learning streak using some of the following resources: