Anthony Short

> Effectively, this means 30 components can call setState() in one render pass, but re-rendering will only happen once. This is good, because it means we don't re-render 30 times...

An example of the higher-level component that handles state: ``` js function stateful (Component) { let state = {} let pendingState = {} function updateState (path, dispatch) { return state...

For the record, even in v1, and in React, the whole tree is just re-rendered on a state change. All it did was just trigger the top-level render function action....

> cannot account for data dependencies of components down its path True. I didn't think of that. You could still mark nodes as dirty using their `path`. When a component...

Looks good to me! The pooling seems like it could exist in an another module rather than living inside Deku, but we can move this out at a later stage....

It seems like a lot of the complexity goes away if we don't have context. It's mostly just for convenience and potentially breaks the purity. Do we think the convenience...

Yeah that needs to be fixed up. If anyone wants to open a quick PR with these changes I'll get it merged

Yeah this is fine by me. It's a really small change for us. The React people would probably have a ton of stuff to update.

Can you provide a broken test case in a PR? It will be much quicker to fix this if we can get it replicated in the tests. Just add it...

Yeah it's definitely possible. At one point I had it in there. It creates a hash of the virtual tree. The part we've never had is the ability to assign...