4 ms·

Thanks for Mithril - we're experimenting with it vs react.js for production use. There's a lot of very smart design decisions there expressed in very terse code

by m0th87 12y ago

Thanks for Mithril - we're experimenting with it vs react.js for production use. There's a lot of very smart design decisions there expressed in very terse code. One thing that threw me off was startComputation() / endComputation(). It seems you have to be explicit about when properties are being updated for views to update. I worry this might be error-prone vs react.js - if you forget an endComputation(), or an exception occurs outside of a try/finally, your views will freeze forever, no?

lhorie 12y 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 12y ago
  At 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 12y ago
    The 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.

by m0th87 12y ago

lhorie 12y 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 12y ago
At 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 12y ago
  The 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.