{"action":"created","issue":{"url":"https://api.github.com/repos/facebook/react/issues/4595","labels_url":"https://api.github.com/repos/facebook/react/issues/4595/labels{/name}","comments_url":"https://api.github.com/repos/facebook/react/issues/4595/comments","events_url":"https://api.github.com/repos/facebook/react/issues/4595/events","html_url":"https://github.com/facebook/react/issues/4595","id":100162479,"number":4595,"title":"Umbrella: Externalize the State Tree (or alternatives)","user":{"login":"sebmarkbage","id":63648,"avatar_url":"https://avatars.githubusercontent.com/u/63648?v=3","gravatar_id":"","url":"https://api.github.com/users/sebmarkbage","html_url":"https://github.com/sebmarkbage","followers_url":"https://api.github.com/users/sebmarkbage/followers","following_url":"https://api.github.com/users/sebmarkbage/following{/other_user}","gists_url":"https://api.github.com/users/sebmarkbage/gists{/gist_id}","starred_url":"https://api.github.com/users/sebmarkbage/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sebmarkbage/subscriptions","organizations_url":"https://api.github.com/users/sebmarkbage/orgs","repos_url":"https://api.github.com/users/sebmarkbage/repos","events_url":"https://api.github.com/users/sebmarkbage/events{/privacy}","received_events_url":"https://api.github.com/users/sebmarkbage/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":15,"created_at":"2015-08-10T20:32:19Z","updated_at":"2015-09-16T20:58:14Z","closed_at":null,"body":"React provides the notion of implicitly allowing a child component to store state (using the `setState` functionality). However, it is not just used for business logic state. It is also used to remember DOM state, or tiny ephemeral state such as scroll position, text selection etc. It is also used for temporary state such as memoization.\r\n\r\nThis is kind of a magic black box in React and the implementation details are largely hidden. People tend to reinvent the wheel because of it, and invent their own state management systems. E.g. using Flux.\r\n\r\nThere is still plenty of use cases for Flux, but not all state belongs in Flux stores.\r\n\r\nManually managing the adding/removing of state nodes for all of this becomes a huge burden. So, regardless you're not going to keep doing this manually, you'll end up with your own system that does something similar. We need a convenient and standard way to handle this across components. This is not something that should be 100% in user space because then components won't be able to integrate well with each other. Even if you think you're not using it, because you're not calling setState, you still are relying on the capability being there.\r\n\r\nIt undermines the ecosystem and eventually everyone will reconverge on a single external state library anyway. We should just make sure that gets baked into React.\r\n\r\nWe designed the state tree so that the state tree data structure would be opaque so that we can optimize the internals in clever ways. It blocks many anti-patterns where external users breaks through the encapsulation boundaries to touch someone else's state. That's exactly the problem React's programming model tries to address.\r\n\r\nHowever, unfortunately this state tree is opaque to end users. This means that there are a bunch of legitimate use cases are not available to external libraries. E.g. undo/redo, reclaiming memory, restoring state between sessions, debugging tools, hot reloading, moving state from server to the client and more.\r\n\r\nWe could provide a standard externalized state-tree. E.g. using an immutable-js data structure. However, that might make clever optimizations and future features more difficult to adopt. It also isn't capable of fully encapsulating the true state of the tree which may include DOM state, it may be ok to treat this state differently as a heuristic but the API need to account for it. It also doesn't allow us to enforce a certain level of encapsulation between components.\r\n\r\nAnother approach is to try to add support for more use cases to React, one-by-one until the external state tree doesn't become useful anymore. I've created separate issues for the ones we we're already planning on supporting:\r\n\r\n#4593 Debugger Hooks as Public API\r\n#4594 Hibernating State (not the serialized form)\r\n\r\nWhat else do we need?\r\n\r\nPinging some stake holders:\r\n\r\n@leebyron @swannodette @gaearon @yungsters @ryanflorence"},"comment":{"url":"https://api.github.com/repos/facebook/react/issues/comments/140892534","html_url":"https://github.com/facebook/react/issues/4595#issuecomment-140892534","issue_url":"https://api.github.com/repos/facebook/react/issues/4595","id":140892534,"user":{"login":"briandipalma","id":1597820,"avatar_url":"https://avatars.githubusercontent.com/u/1597820?v=3","gravatar_id":"","url":"https://api.github.com/users/briandipalma","html_url":"https://github.com/briandipalma","followers_url":"https://api.github.com/users/briandipalma/followers","following_url":"https://api.github.com/users/briandipalma/following{/other_user}","gists_url":"https://api.github.com/users/briandipalma/gists{/gist_id}","starred_url":"https://api.github.com/users/briandipalma/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/briandipalma/subscriptions","organizations_url":"https://api.github.com/users/briandipalma/orgs","repos_url":"https://api.github.com/users/briandipalma/repos","events_url":"https://api.github.com/users/briandipalma/events{/privacy}","received_events_url":"https://api.github.com/users/briandipalma/received_events","type":"User","site_admin":false},"created_at":"2015-09-16T20:58:14Z","updated_at":"2015-09-16T20:58:14Z","body":">what you really want which is: \"change a variable, views update automatically\".\r\n\r\nOnly in some cases. In more complex cases it's more like \"action occurred, execute business logic with new state and possibly update *n* components.\r\n\r\n@jimfb Do you have any documentation/gists explaining state hoisting?"}}