Design Patterns with React Easy State
Making a Beer Finder App
Easy State is a reactive state management library with two functions and two accompanying rules.
- Always wrap you components with
- Always wrap you state stores with
This is enough for it to automatically update your views when needed — no matter how exotically you mutate your state stores.
State management and beers
Calling Easy State a state management library is a poor choice of words. It doesn’t care about how you manage your state, instead it looks out for any kind of state mutations and updates the view when needed.
The next sections explore these patterns through a small app, which finds matching beers for your meal. I recommend you to try it out before you continue reading.
You are not familiar with Easy State yet? Don’t worry, if you read the first three sentence of the article you know enough to go on. Alternatively you can check it out here.
Sharing global state between components
setState is often enough for managing local state, but big projects tend to need more. Some information is better saved globally.
export. This makes them a perfect candidate for storing global state.
Notice how the
this.beers. It is a neat trick, which makes object methods safe to be passed as callbacks. Always use the direct object reference instead of
thisinside object methods, it will save you from a lot of headaches.
appStore can be imported and used in any file — like the below
NavBar component. Don’t worry about the dummy
fetchBeers method yet, we will smarten it up later.
We need another component to display the fetched beers. Naturally it also has to import the global
appStore to map a view to its
Easy State re-renders the above
appStore.beersmutates or changes — respectively. You don’t have to worry about this.
Let’s breathe life into the
fetchBeers method. There is not much to change: it should be turned into an
async method and it should get the beers from an API, instead of faking them.
An ideal store is only responsible of state manipulation and nothing else. Abstracting away the view related logic in the components and the networking logic in an API layer is a good practice. This could mean destructing events and props in the components’ event handlers and handling authentication and headers in a separate networking layer.
Our beer API is a simple one. It has a single function, which fetches beers — that pairs well with the passed food — from the Punk API.
Encapsulting local state
Global state is crucial for big applications, but local state can be just as handy: it improves project structure and reusability. It is your responsibility to decide when to use which.
We are still missing a
Beer component, which could use some local state to switch between two views. Putting a state store object on the component as a property is a simple way of implementing this.
Easy State re-renders the
store.detailschanges. It doesn’t matter if it is a local store or a shared global one, you could even mix the two in a single component.
details flag toggles between the two views of the beer card. It could also be stored on the beer object itself, but putting it in an isolated local store is a cleaner approach. It stores view related metadata, which should not pollute the real data.
Npm is packed with amazing tools, which simplify front-end development by a huge amount. Never hesitate to use them when you need them, but always think before you install. Sometimes you can be more productive with less tools.
I wouldn’t even call the above snippets patterns. They are just code examples, that most developers are familiar with. Still, they were more than enough for a creating small app. Take a look at the beer finder’s source code, the codesandbox demo or find a refreshing beer for your next meal.
If this article captured your interest please help by sharing it. Also check out the Easy State repo and leave a star before you go.