WhoBuilt

State Management in React Native

Jan 25, 2023· 1 h 2 min· 2.6K views·Watch on YouTube

Speaker

Ola Des Moines, a software engineer at Callstack and author, discusses React Native state management with a host on The React Native Show podcast.

Why apps need shared state

As front ends grew into interactive apps, developers needed ways to share changing data such as themes across distant components. Passing values and update functions through many layers can become cumbersome. React Native shares this challenge because it uses JavaScript and React.

A practical way to compare libraries

Ola built a small social app with a feed, liked images, conversations, and settings. Liking a photo had to update both its modal indicator and the separate liked images screen. Ola implemented the same app with each library to compare its workflow and mental model.

Flux, proxies, atoms, and state machines

Ola groups libraries into Flux, proxy, and atom approaches: Redux represents Flux, MobX uses reactive proxies, and Jotai uses small atoms. XState models behavior as a state machine, while React Query treats server data as a separate cache. Ola notes that XState can make loading, success, and failure states explicit, though complex interactions can cause state explosion.

Tradeoffs across popular libraries

Ola describes Redux as widely used and battle-tested, while noting that Redux Toolkit reduces boilerplate and uses Immer to preserve immutability. MobX State Tree groups state and actions in a tree and worked well for the example app. Jotai felt lightweight for a small app, and React Query keeps fetched server data in its own cache rather than copying it into app state.

Choosing and learning a solution

Ola mentions Zustand, Valtio, and Legend State as additional options, and says teams and apps differ. Documentation and community support matter because they shape how easily developers can use a library. The book's examples and companion repository compare libraries using the same app.

Takeaways

  • Choose state tools around the app’s needs and the team’s preferred mental model.
  • Use shared state when related screens need to reflect the same change, such as a liked photo.
  • Consider keeping fetched server data in a query cache instead of duplicating it in app state.
  • Try a small, representative feature with a library before adopting it across a larger application.
  • Check documentation and community support as part of evaluating a state management library.

Mentioned in this talk

Search inside this talk

What was claimed 14

Show all 14 facts

Related talks