It isn’t just
v-model. When any reactive dependency of the template changes the entire template will re-run.
Templates are compiled down to
render functions. Dependency tracking for
render functions is very similar to tracking dependencies for
computed properties. The tracking is started before
render is called and anything that is read is added as a dependency. There is no attempt to keep track of precisely how that dependency was used. If the dependency subsequently changes, the
render function will be called again, running in its entirety.
render function itself creates VNodes, which are used to generate and update the desired DOM. If the VNodes haven’t changed then the DOM won’t be touched. The overhead of running the
render function is typically small compared to the cost of changing the DOM.
On the rare occasions that the
render function itself is a performance problem, the first strategy to improve that is to split it up into multiple components. Separate components have separate
render functions and each one will only run if a dependency has changed.
render function will call any methods it needs. This happens every time it runs. It isn’t limited to specific elements, all the methods from the template will be called every time it runs.
render functions are expected to be free of side-effects. They should reflect the current state, not change it. While you haven’t explicitly stated what
getAsyncOptions does, its name implies it has side-effects, so it wouldn’t be appropriate to call it from a template.
In general, if you find yourself calling methods during rendering without passing any parameters then you should probably be using
computed properties instead. Again, everything is assumed to be free of side-effects.
If you need side-effects then they should be triggered in other ways. e.g. In lifecycle hooks, watchers, event listeners or setters.