2023-07-31
3007
#react
Kapeel Kokane
51356
Jul 31, 2023 â‹… 10 min read

The modern guide to React state patterns

Kapeel Kokane Coder by day, content creator by night, learner at heart!

Recent posts:

A Guide To The React UseReducer Hook

A guide to the React useReducer Hook

The useReducer React Hook is a good alternative to tools like Redux, Recoil, or MobX.

Ejiro Asiuwhu
Oct 10, 2024 â‹… 13 min read
Using The Built-In SQLite Module In Node.js

Using the built-in SQLite module in Node.js

Node.js v22.5.0 introduced a native SQLite module, which is is similar to what other JavaScript runtimes like Deno and Bun already have.

Amazing Enyichi Agu
Oct 10, 2024 â‹… 12 min read
Understanding and supporting zoom behaviors on the web

Understanding and supporting zoom behaviors on the web

Understanding and supporting pinch, text, and browser zoom significantly enhances the user experience. Let’s explore a few ways to do so.

Fimber Elemuwa
Oct 9, 2024 â‹… 7 min read
Comedy and tragedy masks symbolizing Playwright Extra's ability to extend Playwright with customizable plugins for both stealth and interactive browser automation tasks.

Playwright Extra: extending Playwright with plugins

Playwright is a popular framework for automating and testing web applications across multiple browsers in JavaScript, Python, Java, and C#. […]

Antonello Zanini
Oct 8, 2024 â‹… 9 min read
View all posts

8 Replies to "The modern guide to React state patterns"

  1. Very interesting. UseSWR looks really cool but how well does it work across all CRUD actions? How do you invalidate the cache? And what about saving the cache locally instead of in memory as an iPhone has very small memory that gets wiped often.

  2. Thanks!

    useSWR will only handle the read operations from the API. Create, Update and Delete you need to handle yourself, but you could easily extract this into a hook of your own or use the native fetch API.

    By default useSWR will set up a refreshInterval to refresh the local cache. This property is also configurable, so you can choose your own refreshInterval when you use the useSWR hook. In addition it will revalidate the cache on page focus and network connection by default, which means that you get a lot for free in terms of cache revalidation. In the case that you need to force a cache invalidation you’re provided with a mutate method that you can extract from the useSWR hook that will let useSWR know that something changed and you need to refetch immediately. As for the memory, I believe useSWR utilizes the browser cache instead of actually keeping it in memory.

  3. I’m sorry for being that guy, but claiming that state machines are inspired by Redux is such a backward thing to say. State machines have been around for decades, long before Dan Abramov and Andrew Clark were even born…

    If anything Redux is probably inspired from state machines, like the concept of Actions to move from one state to the other.

  4. Why on earth would you be sorry for pointing that out? Thanks for clarifying that obvious error, it was clumsily formulated. In fact, what I meant was that the library XState is reminiscent to redux to the point where you can actually plug in a reducer in xstate and have a state machine with createMachine. I did not mean to imply redux was the source of inspiration for state machines.

    Great catch!

  5. The way I see it, React has too many inconsistent ways to deal with state to begin with – hooks added even more new ways to deal with state, and still, new libraries and patterns keep cropping up. There are well over 50 state management libraries, any of which build around or on top of state management in React itself.

    In my view, this is all symptomatic of React having incomplete/inconsistent state management to begin with – something that does not seem to get fixed by inventing another pattern or yet another state management library; why else would there still be another idea cropping up every two weeks? It’s because it doesn’t work well, or doesn’t do what developers need or want.

    So why don’t they fix it? Well, they can’t, because ultimately that would be a breaking change – and probably a big one, since the problem is not just implementation details, but rather the fundamental concepts; if it were just implementation details, a library would have solved it by now.

    A fundamental design change would mean existing component libraries no longer work, at which point React is no longer really React, and the community would likely split into two. This is where programming languages and frameworks get stuck, time and again. They can adjust and adapt – but they can’t truly change.

    For an example of state management that actually works, see for example Sinuous – it has a single, consistent, very simple state mechanism that works equally well for local component state and global application state. Refactoring from one to the other literally is a matter of moving lines of code from one place to another. I’ve used it quite a bit, and never felt the need for any state management library or clever patterns – it just works.

    Just an example, but I don’t believe the problem is which library or pattern you choose. I believe the problem is inherent to React itself and the state concepts it embodies.

    1. One concept i can’t really wrap my brain around is state vs database storage.

      When you want to save the state in a database or a service like firebase, you have to deal with both fetching the data from the database as well as managing state client side.

      Do you still need a state manager in that case? Or can you do everything by fetching the required data within the component that needs it? Or only fetch the complete state at loadtime and then handle it all client side?

  6. none of the libraries do what i want, especially now everything I do is in Next or Remix, where complex state lives on the server.
    So i built this to do what I need, what do you think, can it replace the complex state management solutions we already have ?

Leave a Reply