Replacing Redux with Recoil in React Native Apps
A lot of people are looking for alternatives to Redux for their React Native apps these days. Newer state management solutions like Jotai and Zustand have been getting a lot of attention lately, but one I’ve heard less about is Recoil — an experimental state management library from the folks at Facebook.
Instead of teaching you the basics of Recoil here (the official docs and Jacque Blom’s free Learn Recoil Course already do a great job of that), I’m going to show you a side-by-side comparison of a very common data fetching pattern implemented in both Redux and Recoil, so you can get a high-level understanding of the differences in the two frameworks’ approaches.
First, let’s look at a very basic app implemented with Redux. This “Request/Success/Failure” action pattern should look familiar to anyone who’s worked in classic Redux.
Our post data here is fetched in a Thunk, which dispatches a success or failure action depending on the result of the API call. A Posts component maps and displays the available post data or an error.
Next, let’s look at how we’d implement this same functionality with Recoil, without a major refactor to our presentation component:
The first thing that might stand out here is how much shorter the Recoil example is. We saved over 30 lines of code. That’s due to the fact that much of the functionality we have to create manually with Redux (defining the “loading” and “error” state, for example), is essentially built in to Recoil’s concept of Loadable values. These values have a state property, which tells you if the value is 'hasValue', 'hasError', or 'loading' . You can get the actual value (whether it’s the fetched data or an error) with the contents property.
Also notice that we make our data fetching call directly in our Recoil selector. It can handle asynchronous logic out of the box, without the need for any third-party libraries (like redux-thunk or redux-saga).
By default, Recoil values are memoized and our fetch logic will not rerun each time we need to access the state it returns. If we do want to explicitly refetch that data, then we can use the useRecoilRefresher_UNSTABLE() hook, as we did on line 39 above.
I hope this post has helped you get a feel for how to approach data fetching in Recoil. Keep in mind that Recoil is still considered an experimental library, so there’s no guarantee that it will continue to be maintained. If you’re looking to replace Redux in your app because you hate all the boilerplate code it requires, I would strongly recommend you check out Redux Toolkit, if you haven’t already. In my opinion, it takes a lot of the pain out of dealing with Redux apps, and can be adopted incrementally so you don’t have to replace your state library all at once.
If you enjoyed this post, please follow me here on Medium and on Twitter @useRNrocket for more React Native content like this!
