My issue isn’t with the scheduler, it’s working perfectly fine, each second it increments the counter by 1.
My issue is with the .debug() formatter that should execute only once, because it’s not linked to the scheduler, but here, it keeps running with no reason, and waay faster that the delay on the scheduler (it’s about 100 console.log per second and even though scheduler should not impact it)
App Connect evaluates all expressions each time data was updated, the scheduler also triggers your expression with the debug formatter. The evaluation of the expression is done internally on each update, it is to see if the output value was changed and if it needs to update the dom.
If i understood well, when the scheduler changes a state on the page, that would trigger all the formatters because some data has changed, if that’s the case, does it make sense that the formatters are triggered in a different tempo than the scheduler ?
I observed that the formatters will execute in a tempo 100 times faster than the scheduler (tried a delay of 10 secs and the formatter executed 10 times per second, when the delay is 1 sec it exectues 100 times per second), is that something normal ?
Also could it impact the performance on larger pages with a decent amount of formatters ?
Internally the scheduler updates each animation frame and updates the progress (percent data binding). There is a noprogres attribute that you can add to prevent it updating on progress and that would prevent the many executions. I checked in Wappler and it seems that the option is missing on the UI, we will see that we add it to the UI.
When you have large pages with lot of expressions and formatters which also updates a lot then you will certainly notice that in performance. Trying to keep data changes and the number of expressions to a minimum will be good practice. The evaluation of the expressions are fast and cached, but having too many can cause performance issues. An other optimization that can be used on large pages is the usage of conditional regions, the conditional regions removes its content from the dom when the condition is false and that also prevents the expressions within from being evaluated. Hidden content like with dmx-hide will still update in the dom and all expressions within will be evaluated while it is not visible to the user, but will impact performance.