6 ms·

React-copy-write: immutable React state management library

57 points by xrd 8y ago

rhacker 8y ago
Seems like they lifted a bit of the react context api but made things even easier... Does anyone know when these non-redux approaches are going to get something like TT debugging?
- kn8 8y ago
  Tiny Atom integrates with Redux devtools https://qubitproducts.github.io/tiny-atom/devtools https://qubitproducts.github.io/tiny-atom/devtools and allows jumping back to any state. It also: * uses the new React.createContext * is [highly optimised](https://medium.com/@kidkarolis/tiny-atom-3-0-0-e65a50de7f4a https://medium.com/@kidkarolis/tiny-atom-3-0-0-e65a50de7f4a) * provides `<Provider>`, `<Connect>` and `connect()` for both react and preact * can be plugged in with immer * explores how to improve over Redux API by combining dispatching and mutations in actions * is small
  - rhacker 8y ago
    Thank you, will check it out!
bcheung 8y ago
You can also use a proxy object to keep state in sync between client and server. Replace verbose API calls with JS objects. Reading and writing from server become native JS mutations.
- TomMarius 8y ago
  Proxy is not yet supported widely enough, sadly.
kn8 8y ago
I quite like this approach, but haven't had a chance to try it in production yet. It seems to be performant and convenient, the biggest cost being extra bytes. In general, immer plugs in nicely to a lot of contexts, such as redux. Here's another example of how it works with tiny-atom: https://qubitproducts.github.io/tiny-atom/using-with-immer https://qubitproducts.github.io/tiny-atom/using-with-immer (disclaimer: yet another state management lib, which I wrote). An alternative approach to immer I've been using in production is http://zaphod.surge.sh/ http://zaphod.surge.sh/, which is more like an immutable lodash.
jordrake 8y ago
This is a nice library but state management libraries that rely on components in the render tree (function as a prop or children) mean you cannot access those properties in the immediate component's react lifecycle methods. Instead you have to (sometimes arbitrarily) have a child component which takes in those properties. This child can then reference those properties in it's react lifecycle methods. Fortunately this is a pretty simple problem to solve, you could introduce a higher order component which takes in your component and selectors much like redux. Infact, it seems the author beat me to it: https://twitter.com/aweary/status/1011478641320980480 https://twitter.com/aweary/status/1011478641320980480
- tjallingt 8y ago
  React team members seem to be hinting at some sort of official "adopt" (https://github.com/pedronauck/react-adopt https://github.com/pedronauck/react-adopt) api which would allow for a slightly nicer way of getting access to render prop arguments. (although you still done get access to them in lifecycle methods). In the meantime this seems pretty nice: https://github.com/Astrocoders/regenerator https://github.com/Astrocoders/regenerator
krishanath 8y ago
What is it about React, that needs you to use a state management library? I have programmed in Servlets, JSP Model 2, ASP.NET, iOS, Android, Windows. None of these require a state management library. But React developers seem to think a state management library is a must-have. Is this a cultural thing? Is it due to some limitation of React?
- applecrazy 8y ago
  The main issue is that React needs state passed around as props otherwise, which becomes unweieldy if you didn’t have a global state. I believe it also makes debugging state issues easier if you have a single source of truth. Edit: this is somewhat alleviated by the introduction of the React Context API[1], which provides some cleaner functionality but requires quite a few extra components in the render tree. [1]: https://reactjs.org/docs/context.html https://reactjs.org/docs/context.html
  - krishanath 8y ago
    >> state passed around as props Context provides a way to pass data through the component tree without having to pass props down manually at every level. https://reactjs.org/docs/context.html https://reactjs.org/docs/context.html >> single source of truth Often, several components need to reflect the same changing data. We recommend lifting the shared state up to their closest common ancestor. https://reactjs.org/docs/lifting-state-up.html https://reactjs.org/docs/lifting-state-up.html
    - applecrazy 8y ago
      I guess then I have no idea why Redux is so widely used, given now the Context API exists.
      - alexkoeh 8y ago
        Redux the library is not "state management for react". It's more of a concept that gives you a predictable structure around how state changes over time. I think what you're thinking of is specifically the `react-redux` library which gave a nice abstraction to the old & clunky React context API. The new context API was released with React 16.3 (which came out March of this year).
languagehacker 8y ago
Not bad, I like that it seems like a simple wrapper to the Context API, but I'll still probably continue directly consuming the API itself that when using Apollo GraphQL
haukur 8y ago
I haven't seen any libraries using the new context API make use of the observedBits prop (currently called `unstable_observedBits`, as its not officially supported). There's a comment in this library's codebase that hints that it will be used in the future. I wrote a bit about this API bitmask-based API a few months ago while I was experimenting with it[1], so I'm curious about its current state and whether others have experimented with it or know about its future in general. [1] https://hph.is/coding/bitmasks-react-context https://hph.is/coding/bitmasks-react-context
- acemarke 8y ago
  I'm _specifically_ hoping to use it in React-Redux v6.x, and wrote up a very extended description a couple days ago of why and how I hope to use it: https://github.com/reduxjs/react-redux/issues/1018 https://github.com/reduxjs/react-redux/issues/1018 I actually referenced your blog post as a good overview of how to use the bitmask API, so thanks for writing it! I also filed a React RFC to make the API a bit more flexible by allowing us to pass a `calculateChangedBits` function directly to a `Context.Provider` instance: https://github.com/reactjs/rfcs/pull/60 https://github.com/reactjs/rfcs/pull/60 Sebastian Markbage replied in that RFC thread, and tbh the discussion seemed a bit odd. It seemed like he was discouraging me from trying to use the bitmask API, or trying to figure out why I might actually want to use it, when it seems like the entire reason it exists is exactly for something like React-Redux to leverage it for performance optimizations.
- Aweary 8y ago
  I had a few versions of react-copy-write working with `unstable_observedBits` but I couldn't decide on the right optimization strategy. At this point I'm not sure how likely it is that this API will be released as stable, so I'm going to hold off until thats more clear.

57 points by xrd 8y ago

Seems like they lifted a bit of the react context api but made things even easier... Does anyone know when these non-redux approaches are going to get something like TT debugging?

kn8 8y ago
Tiny Atom integrates with Redux devtools https://qubitproducts.github.io/tiny-atom/devtools https://qubitproducts.github.io/tiny-atom/devtools and allows jumping back to any state. It also: * uses the new React.createContext * is [highly optimised](https://medium.com/@kidkarolis/tiny-atom-3-0-0-e65a50de7f4a https://medium.com/@kidkarolis/tiny-atom-3-0-0-e65a50de7f4a) * provides `<Provider>`, `<Connect>` and `connect()` for both react and preact * can be plugged in with immer * explores how to improve over Redux API by combining dispatching and mutations in actions * is small
- rhacker 8y ago
  Thank you, will check it out!

bcheung 8y ago

You can also use a proxy object to keep state in sync between client and server. Replace verbose API calls with JS objects. Reading and writing from server become native JS mutations.

TomMarius 8y ago
Proxy is not yet supported widely enough, sadly.

kn8 8y ago

I quite like this approach, but haven't had a chance to try it in production yet. It seems to be performant and convenient, the biggest cost being extra bytes. In general, immer plugs in nicely to a lot of contexts, such as redux. Here's another example of how it works with tiny-atom: https://qubitproducts.github.io/tiny-atom/using-with-immer https://qubitproducts.github.io/tiny-atom/using-with-immer (disclaimer: yet another state management lib, which I wrote). An alternative approach to immer I've been using in production is http://zaphod.surge.sh/ http://zaphod.surge.sh/, which is more like an immutable lodash.

jordrake 8y ago

This is a nice library but state management libraries that rely on components in the render tree (function as a prop or children) mean you cannot access those properties in the immediate component's react lifecycle methods. Instead you have to (sometimes arbitrarily) have a child component which takes in those properties. This child can then reference those properties in it's react lifecycle methods. Fortunately this is a pretty simple problem to solve, you could introduce a higher order component which takes in your component and selectors much like redux. Infact, it seems the author beat me to it: https://twitter.com/aweary/status/1011478641320980480 https://twitter.com/aweary/status/1011478641320980480

tjallingt 8y ago
React team members seem to be hinting at some sort of official "adopt" (https://github.com/pedronauck/react-adopt https://github.com/pedronauck/react-adopt) api which would allow for a slightly nicer way of getting access to render prop arguments. (although you still done get access to them in lifecycle methods). In the meantime this seems pretty nice: https://github.com/Astrocoders/regenerator https://github.com/Astrocoders/regenerator

krishanath 8y ago

What is it about React, that needs you to use a state management library? I have programmed in Servlets, JSP Model 2, ASP.NET, iOS, Android, Windows. None of these require a state management library. But React developers seem to think a state management library is a must-have. Is this a cultural thing? Is it due to some limitation of React?

applecrazy 8y ago
The main issue is that React needs state passed around as props otherwise, which becomes unweieldy if you didn’t have a global state. I believe it also makes debugging state issues easier if you have a single source of truth. Edit: this is somewhat alleviated by the introduction of the React Context API[1], which provides some cleaner functionality but requires quite a few extra components in the render tree. [1]: https://reactjs.org/docs/context.html https://reactjs.org/docs/context.html
- krishanath 8y ago
  >> state passed around as props Context provides a way to pass data through the component tree without having to pass props down manually at every level. https://reactjs.org/docs/context.html https://reactjs.org/docs/context.html >> single source of truth Often, several components need to reflect the same changing data. We recommend lifting the shared state up to their closest common ancestor. https://reactjs.org/docs/lifting-state-up.html https://reactjs.org/docs/lifting-state-up.html
  - applecrazy 8y ago
    I guess then I have no idea why Redux is so widely used, given now the Context API exists.
    - alexkoeh 8y ago
      Redux the library is not "state management for react". It's more of a concept that gives you a predictable structure around how state changes over time. I think what you're thinking of is specifically the `react-redux` library which gave a nice abstraction to the old & clunky React context API. The new context API was released with React 16.3 (which came out March of this year).

languagehacker 8y ago

Not bad, I like that it seems like a simple wrapper to the Context API, but I'll still probably continue directly consuming the API itself that when using Apollo GraphQL

haukur 8y ago

I haven't seen any libraries using the new context API make use of the observedBits prop (currently called `unstable_observedBits`, as its not officially supported). There's a comment in this library's codebase that hints that it will be used in the future. I wrote a bit about this API bitmask-based API a few months ago while I was experimenting with it[1], so I'm curious about its current state and whether others have experimented with it or know about its future in general. [1] https://hph.is/coding/bitmasks-react-context https://hph.is/coding/bitmasks-react-context

acemarke 8y ago
I'm _specifically_ hoping to use it in React-Redux v6.x, and wrote up a very extended description a couple days ago of why and how I hope to use it: https://github.com/reduxjs/react-redux/issues/1018 https://github.com/reduxjs/react-redux/issues/1018 I actually referenced your blog post as a good overview of how to use the bitmask API, so thanks for writing it! I also filed a React RFC to make the API a bit more flexible by allowing us to pass a `calculateChangedBits` function directly to a `Context.Provider` instance: https://github.com/reactjs/rfcs/pull/60 https://github.com/reactjs/rfcs/pull/60 Sebastian Markbage replied in that RFC thread, and tbh the discussion seemed a bit odd. It seemed like he was discouraging me from trying to use the bitmask API, or trying to figure out why I might actually want to use it, when it seems like the entire reason it exists is exactly for something like React-Redux to leverage it for performance optimizations.
Aweary 8y ago
I had a few versions of react-copy-write working with `unstable_observedBits` but I couldn't decide on the right optimization strategy. At this point I'm not sure how likely it is that this API will be released as stable, so I'm going to hold off until thats more clear.