4 ms·
That topic was brought up here: https://github.com/lhorie/mithril.js/issues/68 https://github.com/lhorie/mithril.js/issues/68 Generally, you only need to manu
by lhorie 13y ago
That topic was brought up here:
https://github.com/lhorie/mithril.js/issues/68 https://github.com/lhorie/mithril.js/issues/68
Generally, you only need to manually call start/endComputation when integrating to 3rd party code that needs to update Mithril managed bindings.
In the latest release, I tweaked the rendering aggressiveness to allow redraws after exceptions in event handlers, and I updated the docs wrt `try/finally` blocks in integration scenarios.
One other thing people could do that I don't think should go in Mithril core is to call m.redraw inside window.onerror.
Of course, I'm open to other suggestions, if you have any.
- m0th87 13y agoAt least in my application, views are always bound to either an `m.prop` or an immutable value. What if you tracked when an `m.prop` was updated and queued up a redraw automatically? Redraws would be rate-limited via requestAnimationFrames/setTimeouts as usual. I imagine this could have a significant performance impact, but don't know the mithril internals well enough to say. EDIT: Thinking about it, the virtual DOM must be re-constructed on every redraw since the props aren't tied to a view. This probably wouldn't work well then.
- lhorie 13y agoThe topic of side-effect incurring getter-setters was also brought up a few times in various forms. I wrote about my thoughts on it here ( https://github.com/lhorie/mithril.js/issues/78 https://github.com/lhorie/mithril.js/issues/78 ) As far as redrawing impact goes, Mithril does rate-limiting, so even attempting to subvert m.prop to force it to spam redraws should still perform ok.