Test for #1146

[barneycarroll]

No description provided.

[dead-claudia]

Ugh...this looks ugly.

[pygy]

@barneycarroll said

This works in practice (the original problem case jsbin visibly just works), but not in theory — I couldn't get any lifecycle tests to pass this. I guess I'll have to invoke the autoredraw API…

The problem was with DOM events... mounting only draws the tree being mounted.

Specifically, run() is a throttled version of the callback defined a few lines above.

I'm not sure it makes a lot of sense to redraw everything on mount...

[barneycarroll]

I'm not sure it makes a lot of sense to redraw everything on mount…

It does if we consider that the first draw is synchronous and redraws are global in nature, but these are assumptions from v0 and may no longer hold. I'll rewrite this with an explicit lifecycle sequence.

What continues to baffle me is that granular redraw has effectively been introduced as an implementation accident without a usable API :)

[pygy]

I'd be surprised if root.redraw = run was an accident (hence #1157 which makes it slightly nicer to use).

I agree the lack of fanfare is surprising, even though they still aren't as granular as #743 (but introducing that probably necessitates a dependency on api/throttle.js, either static through require (unlikely given the fact that render/render.js currently stands on its own) or injected).

[lhorie]

root.redraw is really just a reference to a function so that it can be unsubscribed (to avoid memory leaks). It can only really be used as a function call in some restricted cases: as root in m.mount where the component does not take arguments, or as the root in m.route, where the topmost vnode creation is handled by the router

It can't handle granular redraws (i.e. it doesn't handle components w/ arguments and non-component vnodes)