
React-copy-write: immutable React state management library - xrd
https://github.com/aweary/react-copy-write/blob/master/README.md
======
krishanath
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
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
>> _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
I guess then I have no idea why Redux is so widely used, given now the Context
API exists.

~~~
acemarke
Multiple reasons.

First, Redux has been around since 2015 (and won the "Flux Wars" that had been
going on for a year before that), whereas the new `createContext` API only
came out a few months ago.

Second, Redux provides a lot more guidance around how you're supposed to
structure your application. Context only provides a method for making values
available to deeply nested components in the tree.

Third, the Redux ecosystem is huge, with addons available for effectively any
use case you can think of. [0]

Please see my post "Redux - Not Dead Yet!" [1] and Dave Ceddia's post "Redux
vs the React Context API" [2] for more details on how they relate.

[0] [https://blog.isquaredsoftware.com/2017/09/presentation-
might...](https://blog.isquaredsoftware.com/2017/09/presentation-might-need-
redux-ecosystem/)

[1] [https://blog.isquaredsoftware.com/2018/03/redux-not-dead-
yet...](https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/)

[2] [https://daveceddia.com/context-api-vs-
redux/](https://daveceddia.com/context-api-vs-redux/)

------
haukur
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
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.

------
jordrake
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
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)

------
kn8
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.

------
bcheung
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
Proxy is not yet supported widely enough, sadly.

------
languagehacker
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

------
rhacker
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
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
Thank you, will check it out!

