DEV Community: Francesco Sardo

Share state using custom hooks

Francesco Sardo — Tue, 17 Aug 2021 14:04:25 +0000

Many articles have been written about React state management strategies for React, and yes, this is yet another one of them. But rather than talking about a new library and how everyone should adopt it, I want to talk about two different philosophical approach to state: centralised vs decentralised.

The decentralised state paradigm

Decentralised state has been the battery-included solution since the first version of React. Class components can edit local state to trigger a re-render, and functional components can accomplish the same with the useState hook.

Local state is very intuitive to manipulate because it sits near the component that uses it for display and side effects, it's allocated when needed, and disappears when the component is unmounted.

The centralised state paradigm

Keeping all mutable state in one place is an approach championed by Elm, ClojureScript and Redux: a single data structure (usually a tree) contains all the state needed to render your React application. When a branch of that tree changes state, the relevant components in your React hierarchy re-render displaying the new information.

A single point of reference for the entire app state is a very neat idea and feels like a natural evolution on top of React itself: React abstracts DOM changes with components, the app state abstracts component changes with a big JSON value.

Since all changes are represented with data, the logic that transitions the app through different states is very easy to express and to test: it's just a function f(currentState, event) => newState. It's also easy to generate many valid UI screens by mocking the app state.

speccards generates random valid UI states based on a spec

Problems with decentralised state

Local state becomes problematic when two components need to watch and act on the same state. Think about a simple currency converter where the user can edit either currency text input.

In this case the naive solution is to "lift the state up" to the closest parent and give all children callback functions to manipulate the state.

Lifting State Up in vanilla React

This rarely scales for bigger applications, so something like Recoil might be needed for more powerful sharing.

Problems with centralised state

You can easily get started with centralised state with the useReducer hook and keeping all state inside the top <App/> component, passing down state as props wherever they are needed. What you'll find soon enough, though, is that components far away from the root will require forever more information, and you'll have to drill all the props through the tree until they reach the correct component.

This, again, doesn't scale for large applications, so some forms of subscriptions to parts of the state tree are required to keep the app performant and easy to extend. You might need something like the hook version of Redux

How the two compare in terms of Developer Experience

I have always been a huge advocate of the centralised approach. It appealed to me because of its functional purity and how it made accessing and manipulate state much easier in the pre-hook era. I have since changed my mind, and I'd like to explain why.

Centralised state gives you the illusion of correctness. The state neatly transitions from one pure value to another thanks little functions that encapsulate your business logic. You might even have tests for those functions that say something like:



- When button is clicked
- Set the loading indicator to true
- Clear the input field
- Send an http call to the server

Except that when you actually run the app, the behaviour is not what you expected. The problem is that your logic is far removed from your UI components, and while sound and correct in principle, it doesn't play well with your render code. It might be because the state has a different shape, but more often that not, it's because the intended values are not added to the state at the right time.

Modelling your app as a succession of states works well when you deal mostly with synchronous interactions, like a game, but starts to show its limit with more asynchronous behaviour, like fetching new data over the internet. It's easy to describe how the data changes but not how the data gets there in the first place. So you might end up with an infinite spinner because an action has not been triggered or received at the right time (e.g. when the user navigated to a new screen).

Annoying when that happens eh?

Colocating state, effects and ui

Advocates of the centralised state approach have a great argument: UI should not care about state management and side effects, it should just care about displaying values. Extract the logic somewhere else and test it.

While poignant in principle, this doesn't work well in practice. The reverse tends to be true: it's useful to think about components as fragments of the screen with a well defined behaviour. They can trigger actions, listen to events and manipulate state that affects other components.

Over the last year I've been writing components with complex behaviour, fully expecting things to break and knowing I'll be refactoring them with some centralised solution. To my surprise, this nontrivial, large app, kept on getting bigger and accumulating new features without getting significantly more complex. I would even say it scaled in ways that Redux, ClojureScript or Elm apps haven't been in the past, even with less "formal proofs" (tests, types) of correctness.

A hook with a name

Consider this component



function ItemList() {
 const { auth } = useUser()
 const { itemsPerPage } = usePreferences()
 const { searchQuery } = useSearch()
 const items = useItems({ auth, itemsPerPage, searchQuery })
 return <ul>{items.map(...)}</ul> 
}

To me it clearly communicates its dependencies (inputs) and how it uses them for display. Moreover, these inputs are not just static data but a combination of state and effect.

useUser returns the current user info if logged in, otherwise it triggers an authentication flow
usePreferences gets saved data asynchronously from IndexedDB
useSearch extracts the query parameters in the current url
useItems ties everything together, getting the items server side and caching them for future uses.

When each one of these dependencies change (the url parameters, or the local storage being cleared, or the user token expiring) the hooks will take care of re-fetching and re-rendering the component.

Custom hooks that encapsulate caching are also a great way to share data between components: user, preferences, and remote data all reside in-memory and only need to be fetched once. The first component that uses the hook triggers the async behaviour and all the other components can subsequently access it free of charge.

You can even go one step beyond and wrap this behaviour in a hook itself:



function useSearchItems() {
 const { auth } = useUser()
 const { itemsPerPage } = usePreferences()
 const { searchQuery } = useSearch()
 const items = useItems({ auth, itemsPerPage, searchQuery })
 return items
}

So you can have the same list of items in two different part of the application (say: the list itself and a Count indicator somewhere else).

Hooks can be seen as a dependency graph: what they "require" (other hook calls) and what they provide (the returned value). Editing this graph is really easy if you stick with React hooks and don't go outside of it with centralised state management.

This patterns composes really well and scales as you create new components. Need another components to access this list? It's a one line change. Don't need access to that data anymore? Removing the hook or the component itself means it's not fetched in that screen anymore.

State (what's cached), behaviour (which effects load and invalidate the data) and UI can be closely linked together again, so they evolve organically together with your app.

There's an app for that

Writing hooks manually that load, cache and invalidate it's obviously time consuming, and there's no need to do that when there are great libraries out there already.

React Query obviously stands out with its incredible DX. It works with http, graphql and any asynchronous behaviour really (e.g. IndexedDB).

This library alone gives you so much leverage it might be the only solution you need. If we're talking about state sharing without asynchronous behaviour, then Recoil might be a good addition too. If you're using custom hooks with a descriptive name, it won't really matter which library you use underneath.



// Prefer this

const repos = useRepos()

// To this

const { data: repos } = useQuery('repoData', () => fetch('https://api.github.com/repos/tannerlinsley/react query').then(res => res.json()))

A real world example

It's always best to show how ideas are implemented in practice rather than just talking about them so I've created firebuzz.app

Players can buzz to answer questions and receive points

You can browse the source code (and it particular the hooks folder) over here https://github.com/frankiesardo/firebuzz.

Steal these ideas (from ClojureScript) right now

Francesco Sardo — Tue, 05 Jan 2021 14:41:54 +0000

Clojure(Script) is a delightful language and learning it will make you look at familiar concepts in a completely different way. Its emphasis on data transformations gives you immense clarity in understanding a problem: code syntax fades away when you think about how the data flows through the system.

I recently started working on vanilla React projects, and it surprised me that some hard-earned lessons in the cljs ecosystem that I take for granted have not reached the wider React community. ClojureScript and React have been working together really well since the beginning, and cljs devs have scaled very complex UIs thanks to some tricks that I think will benefit everyone growing a React application.

Let's have a look at an example shall we, it will be easier to explain the concepts with some code running in front of your eyes. You want to create a simple component that fetches the Github repos for a given username. You open up your editor and quickly come up with something like this (well, probably looking prettier than this)

What's the problem with it? Well, nothing really. A strong selling point of React is how well it adapts to different styles, whether functional or more object oriented. Here we just want to throw something together and seeing that it works, and the problem is simple enough that we don't need anything more complex that a few stateful components.
But let's imagine for a moment that we're working on a bigger app, and, while still using the same example for simplicity's sake, we want to scale things up a bit. Let's hear what advice we can take from cljs.

🗃️ (1) Keep the state all in one place

That is probably the first thing you're going to hear from any Clojure developer. Stateful components are notoriously harder to understand, debug and scale, precisely because they hide complexity inside them.

Here's David Nolen, author of the hugely influential library om.

And if you're not convinced yet, please do watch Rich Hickey's The value of values.

Imagining the application state as one big "memory database" is what allowed concepts like Pure Components, Global Undo, and Time Travel Debugging to become popular.
Centralising app states greatly simplifies things. Think about it: would you prefer to connect to one database or a hundred different databases?

We also start to see the idea of your components being nothing more than a function that maps data to UI.

Component(data) => UI

In many React circles this idea quickly became popular and that's how Redux came to be (inspired by Flux and The Elm Architecture) and is now part of React itself with the useReducer hook.

We can rewrite our simple example like so:

This also has the benefit of making the UI more modular: we can extract a Form component from the previous example because it can just use and update the state independently of other components.

🌶 (2) Make your app Hot Reloadable

Years ago I used to build Android Apps and the OS had this mechanism called onSaveInstanceState() where Android asks every little piece of stateful UI: "hey, what's your current state?" so that it can save it temporarily when your app is killed by the system. It is quite an annoying thing to implement. I even wrote a library for it.

Imagine how easy it would be for Android if the state of your app was all in one place. Implementing save & restore would be one line of code. And that's why ClojureScript had the first and still the best experience of Hot Module Reload that anyone has ever seen.

Hot Module Reload is not just about updating a function or two: it's about changing the UI behaviour but preserving its state. Watch the talk and see what happens when Bruce Hauman changes the game logic as he plays it: if it doesn't blow your mind, nothing ever will. Oh, and once you recover from the shock go ahead and watch Bret Victor's Inventing on principle for other inspiring ideas. You'll never go back to the old ways of working.

If you want to tweak the RepoItem view that we have in our example, every time you make a change you'll need to fetch the repositories again, and you'll quickly hit Github rate limits. Why can't the UI stay on the RepoItem page while you work on it?

There are some solutions in React that enable a similar experience, but they're not quite there yet, and it's definitely not beginner friendly. Instead, every cljs project has hot reload enabled from the start.

We can hack something together quite easily if we write to local storage every time the state changes, and then read it from the storage on reload.

Whatever strategy you use, I strongly suggest you have something, anything, in place that enables HMR without losing state, so that you can experience the joy of live reloading.

🎯 (3) Surgically update components

Some of you might complain that passing the entire state down to the exact component that needs it takes a lot of work. And you will be right. It also forces all the root components to re-render whenever a leaf changes its properties.
That's why all cljs libraries tried to come up with a solution that makes this approach more efficient: om had cursors, reagent had reactive atoms.

A real breakthrough came with the introduction of re-frame, and with the best README you'll ever see.

You want your components to react only to specific changes of the "memory database". The concept is similar to Materialised Views: they represent a particular view of the underlying database and they update only when the data they're interested in changes.

I can't find a talk from Mike Thompson, author of re-frame, but he convinced all of us to watch this video, and you should probably watch it too.

Recently, Recoil introduced similar concepts to most React users and its design is heavily inspired by re-frame (a selector is a particular view on an atom and through hooks you subscribe to its updates).

Recoil is quite smart in its implementation, and nicely enough, you can use the reducer pattern inside of it: we can keep all the state inside an appAtom and useRecoilSetState to update it.

Here appAtom in our main db and the other selectors (reposView, repoItemView etc) provide the materialised views. Recoil does the rest, triggering an update when needed. If you click a RepoItem and set its nested state to isOpen:true, only that element will rerender (if you enable this flag).

Again, I'm over-engineering our example to illustrate how these concepts work, but creating a new selector for each component seems to be quite a common pattern. And I love how business logic (imagine a "is repo actively maintained?" concept) sits in the selector and the UI just consumes it.

🎢 (4) Side effects as data

Last point, I promise.

We seem to have it all now: centralised state, consistent hot reload, smart updating views. What more, I hear you say?

In all the examples above, when it's time to perform a side effect we just go ahead and do it. On the click of a button, we go ahead and hit the network, or persist to local storage, or manipulate the url. Seems easy enough.

Except that performing the side effects straight away makes it harder to track down what's happening at any given point in your application. Remember the official Architecture Diagram in the re-frame README?

A side effect can trigger more side effects and/or state changes. It's a first class citizen of our application. And I think we should create an Effect data structure to represent it, similarly to how we create a reducer Action to transition the state.

This is a concept strongly advocated by The Elm Architecture and the Command pattern, and many libraries, including re-frame, have it. There are a few ways to implement this "effects queue" but the simplest is to keep it in the app state, along the "memory db" that holds the data to be visualised by the components. So now we have two top level keys: db and effects.

Recoil, again, makes it pretty clean because your app can just subscribe to the dbView which holds the ui data as we now it, and a different part of your app can subscribe to the effectsView and perform the side effects.

Notice three things:

We don't need to call useEffects everywhere in our application: there is just one at the root, and all effects are performed there.
When we execute a branch in the reducer, we no longer just specify how the app state changes, we also declare which side effects will triggered. This is an amazing way to understand the behaviour of your application: "When I click this button I display a loading indicator and start to fetch the data". This is how we humans talk about these concepts, and they're nicely reflected in our code.
Side effects execution is now explicit. You can inspect it, monitor it, pause it, replay it, persist it, rewind it (play Daft Punk song here) because it's just data™. For example, when a button is clicked you can have a look at the effects queue and decide to remove any pending http side effects if the user is navigating to another screen.

If you model side effects explicitly you can have fantastic insight on your app behaviour: check the re-frame-10x demo or the Elm Time Travel Debugger.

I know some of you might think: ugh, is it worth the effort? And the answer is yes, believe me. And if you don't believe me, believe success of the tool you're already using: isn't React just a way to model DOM side effects through explicit data instead of executing them directly?

🕵 Conclusion: where is the library

You might be thinking: ok, interesting ideas, but you talked about all of this because you have a library to pitch, don't you? You don't expect me to write this myself, do you, so where's the download link and the Quick Start page?

Sorry, there's no library. If there was it would be called The Kappa Architecture for React, or simply reframejs, but there's no need for it. And this is not even a pitch to say: all these things you can have if you switch to ClojureScript. Because it's not a particular framework or library: it's a set of related concepts. Sure, they feel more at home in a cljs project but they work nicely in plain React too, and I used them to create this simple multiplayer buzzer app if you want to see them in action.