Avoid global redrawing on modular view model
how can I manage to avoid the global redraw = call to the main view function by changing the submodule view, like in the main view method of the module:
m("body", [
m("#head", {...}),
Menu.show(this),
Footer.show(this)
])
where the static show method looks like this:
function show(app)
{
if (inst == null)
inst = new Footer(app);
return inst.view(app);
}
It should now increase the already good performance if there is a way to run the sub-view method without using the main view method in case the changes in the sub-view have local effects. It makes sense?
Axel
source to share
You cannot prevent global redrawing, but you can selectively make certain parts of the view non-redrawn with subtree directives
Be aware, however, that this is a performance optimization that disables redrawing for the affected subtree, and as such you cannot update its view unless you replace the directive with the subtree again.
source to share
Redrow is a global operation in Mithril, and the structural decisions you force you to do is design. Rather than expose an API that allows granular control of the rendering process from anywhere in the application, Mithril handles the entire process through a specialized differentiating algorithm that compares iterations of the optimized virtual DOM.
Having said that, there are ways to influence different logic and implementation of an implementation depending on the context:
- Calling
m.redraw.strategy
with an argumentnone
ordiff
at the right time can completely prevent redrawing, or avoid what would otherwise be a full DOM redrawn, respectively. In my application, a particularly complex module launches and constantly reacts to route changes (multiple lists, where each element itself is a submodulated DOM structure, additional additional widgets, etc.) - by settingm.redraw.strategy( 'diff' )
in the controller, I manage to keep performance at ~ 55 fsp even when only changing DOM fragments that were different (which are big chunks nonetheless!). - Call
{ subtree : 'retain' }
on the parts of the virtual DOM that you want to remove from a different procedure. If you have large chunks of DOM and want the diff algorithm to ignore (and therefore not be affected by subsequent redraws), you can supply this special argument in the view. Note that if you later decide to remove the save subtree directive, the entire internal DOM tree will need to be re-rendered at least once, since the previous iterations will not be registered by the diff mechanism, so I would not recommend trying the second option or using this algorithm. - Use
{ key : 'uniqueIdentifier' }
to highlight items that the diff algorithm might otherwise identify as new. If you have a fragment of a view that has moved relative to its old location in the DOM between repaints, this algorithm will destroy the old one and render the new one from scratch. Specifying a uniquekey
allows him to make sure he should move the existing DOM structure and apply any fixes there. This is useful if a large and complex DOM structure has changed its location, but starts to work against performance if used on a large number of small items. For example, in my application, I added keys to each list item (each of which was a submodule with at least 8 items, event handlers, etc.) to avoid redrawing items that just moved into the list. It turned out that deletingkey
and just creating items from scratch when they improved performance by 100%.
But my advice would be to let Mithril do what he thinks is best. One of the main advantages of Mithril over other MVC-libs view components is that Mithril allows you to forget about the redraw loop 90% of the time and let it happen when needed. This is an advantage! Another thing to keep in mind is that countless people have spent countless hours of developers trying to get Javascript MVC rendering faster - and Mithril is one of the fastest. Most likely, Mithril core is probably more optimized than the second variant of its internal logic in most cases. In my experience, introducing additional code to improve performance actually working against my expectations. Mithril is incredibly fast as it is - it should set us free,to spend our ingenuity on other problems!
source to share