Investigate using Redux for pseudo-local component state

[gaearon]

As @slorber notes, once you go single-treeish, local component state begins to bother you.

I don't feel strongly about it (I'm fine with some local component state here and there), but it would be interested to explore API and implementation-wise the idea of replacing React local component state with state backed by Redux with “ephemeral” reducers whose data is erased when their owner component unmounts.

I'm not sure if I'm actually making sense here.. Let's say that the litmus test is:

• Have some API that looks similar to React's local state API. For example, a container component that injects state and setState as props.
• Unlike React's local state API, under the hood, it works by emitting actions like { type: SET_LOCAL_STATE, ownerComponentId: '42424242' }
• There is a reducer that handles these actions. The container component subscribes to the slice of the state governed by that reducer
• (The nice part) By default component IDs are unique but you can specify a function that generates the key from props. This lets components “mirror” the same state or “transplant” it across the tree. (cc @chenglou)

Related: rethinking React's key and state.

[gaearon]

Note that I think all of this can be implemented totally independent from Redux in a separate repo. Anybody wanna try?

[gaearon]

The tricky part of course is to figure out when (and whether) to erase such state. This may be a bad idea after all, see @jimfb's comments in this gist. But I still think we ought to give it a try..

[gaearon]

I think a great first approximation is to make it work so that the “pseudo-local” state is always destroyed when the component unmount. The set of “actions” would be MOUNT_LOCAL_STATE, SET_LOCAL_STATE, UNMOUNT_LOCAL_STATE. This is already cool because this enables time travel and logging at Redux level even for “local” state.

[gaearon]

Here's something interesting. This is totally implementable outside core as long as the user doesn't forget to include our “local state reducer” in their global reducer. Doesn't this sound similar to what I wanted in #113? It's the same “third party” state and “third party” actions all over again. It sounds like there's a special sort of functionality many plugins want to have: the ability to write to a custom slice of sub-atom that user is not managing explicitly. @acdlite

[dariocravero]

@gaearon we're almost doing that in panels (a runtime to run independent apps with a very particular (mobile focused) UX). However, because each app is meant to be independent, we isolate its flux instance in what we call contexts which is part of the runtime's atom. I should be in a position to show you what I just described in real code sometime around the conference if you're interested. I'm interested to see how this unfolds and how I can help shape it. :)

[gaearon]

Cool, see you at the conf then!

[dariocravero]

Definitely :)

[matystl]

Similar ideas in clojurescript http://blog.circleci.com/local-state-global-concerns/

[steida]

After actions as pure functions, initial state, state-less flux, another stuff I'm using in http://github.com/steida/este Do we follow the same logic steps?

I'm calling that pattern globalized local state: https://github.com/steida/este/blob/13c59be76c39ecfabbf6f8ada17e8ffde0e59cbf/src/client/components/editable.react.js#L101

[iammerrick]

I don't know that it makes sense to couple transient state with the component. Maybe I'm misunderstanding but really I want transient state that potentially spans multiple components....

[gaearon]

I don't know that it makes sense to couple transient state with the component. Maybe I'm misunderstanding but really I want transient state that potentially spans multiple components....

That's exactly what I'm suggesting. :-)

By default component IDs are unique but you can specify a function that generates the key from props. This lets components “mirror” the same state or “transplant” it across the tree.