Thomas Roch

The way you implemented it, you memoize the last rendered output of a component as opposed to memoizing the last rendered output per component instance. Below was my attempt at...

Yeah in fact I meant to shallow compare props, not models ^^ ``` javascript const defaultShouldUpdate = (model, prevModel) => !equals(model.props, prevModel.props); ```

Great! > getProps would work similar to the connect function in Redux > > The next piece of optimization I'm thinking about is with local state, and it ties in...

> In contrast, deku v2 asks you to dispatch a store action instead it doesn't need to be an action, and it doesn't need to be sent to a store....

> ...But for any dispatch to be useful, it needs to re-render the tree (ie, call render() again), which you don't need at that point. This is just one of...

Render needs children, don't know if lifecycle methods would benefit more from attrs or props (maybe both)?

There is still something I trip over: in React the whole tree is re-evaluated on each setState / mutation, but i`setState` marks nodes as dirty, forcing their render function to...

It will be performant if `getProps` just selects what it needs from context, you can leave expensive stuff to the render function. Once your props are selected out of attributes...

Another idea, going down the path of memoized render functions: - `path` is used as an ID for memoization - only memoize last result - Marking a component dirty causes...

If a component needs context, it exports a `getProps`. A leaf is part of a subtree, or a subtree itself if it has its own `getProps`. When updating a leaf...