Until now, changing any input field marked every view in the editor as out of date, so views that had nothing to do with the field you edited were recomputed too. That made apps feel slower than they needed to be.
From now on, each view has its own set of input parameters: the fields of the parametrization that the view actually uses. VIKTOR derives this automatically by analysing your view methods. When a user edits a field, only the views that use that field are recomputed (or marked out of date, for slow views). The rest keep their result.
A concrete example: an app with a number field for a beam length and a text field for the project name. The view that draws the beam is no longer recomputed when someone edits the project name.
Three things worth knowing:
- The analysis is deliberately conservative. If it can’t determine with certainty which parameters a view uses, it falls back to the full parametrization and the view is recomputed on any change.
- Every view now has an update button plus a timestamp showing when its result was last updated. Use it to recompute a view without touching the input.
- Views that don’t depend on any parameter are calculated once and remain static afterwards
For more information see: App execution flow (Jobs) | VIKTOR Documentation
Curious to hear how this feels in your apps.