1. 11

  2. 3

    Incredible article. This is going to save me so much time, being new to redux and all.

    1. 3

      I’ll save you even more!

      Don’t use Redux. Write your own little framework where you pass messages through something like a stream that leads to something modifying your “state store” and then something rendering your app.

      Redux is simple in principle, but somehow accumulates massive complexity and reams of indirection around it. Reducers are too boilerplatey, sometimes you do want nested state, and you want more control over when/how rendering happens.

      Avoid all the dependencies you can. Even react-router.

    2. 2

      I find it very interesting that normalized state tables are recommended in Redux. Recently, I’ve been hearing a lot of about redux and similar stores that suggests they are becoming very similar to client side databases without persistence needs.

      1. 2

        Yes, I do think that is somewhat true. I personally have been thinking of them as very organized caches, but that’s pretty much the same thing that you’re describing.

      2. 2

        I usually have two trees in my redux: ephemeral, resources. Ephemeral hosts ui, session, etc. Resources are where the jsonapi data goes. I’ve even written functions specifically for this kind of structure: https://www.npmjs.com/package/@unction/treeify

        1. 2

          You know, I very much do the same. Maybe it’s the case that if you’re focusing on persisting only raw data in the state, you’ll end up with a similar structure. I might add that to the article.

          1. 3

            Great insight.

        2. 1

          This is an awesome post! Thanks for sharing :)