You can see how App is still a function that takes state and outputs the entire UI.

Why is this significant? Because it’s simple and predictable. You can think of each smaller part of the application as yet another function. And all of these functions are pure and stateless. They take some arguments, return some UI. It’s easy to reason about each such function.

Changing state

What we saw so far is all great and good. But there’s a catch. In real world applications, the state changes all the time. For example:

So what if we create an update function that updates the state and rerenders our UI. We can then pass this update function to our components and they can call it whenever the state needs to be updated.

Bam! Whenever some app component needs to update the state it can do so using the update function. For example, incrementing a counter after user clicked a button. Or storing a server response for other components to render. Calling update from anywhere in turn causes the entire application to rerender with the new state.

This single state store approach is what libraries such as redux or tiny-atom help you utilise effectively. With tiny-atom this same example would look more like:

This is the same principle we’ve already seen. We have a place to store all our state (atom), we have a way to update this state (increment action) and the app will rerender whenever the state changes (because Counter component is listening to store changes thanks to the useAtom hook).

In practice, in real world applications it’s more convenient and efficient to read values from the state using helper functions like this example instead of passing state and update or actions around as React props.

Thanks for reading and I hope this was interesting if you haven’t come across this idea before:

UI=fn(state)

UI development has never been so simple, thanks to React.

Read Next

I recently had a pleasure of using Next.js, the server side React framework, for building a small product — a free global tech job board. You can see it live at https://spaceboard.tech/ . I generally approach Server Side Rendering (SSR) with caution, because of it’s performance… Continue →