Ability to manage Events and Schedule Rendering

Context: We have been prototype using Maquette with dgrid considering using it for the next major version. We have found a few things that we see as challenges for us in adopting it. @kfranqueiro, @maier49, and @edhager have been working on the prototyping.

Problem Description

In certain cases, the application is aware that certain DOM Events of which it has listeners for do not equate to any mutations of the DOM, but currently Maquette will always schedule a render on any listener provided via the VDOM.

Also, we are unsure if the intent of Maquette to potentially manage these events. While the code documents the projector option of eventHandlerInterceptor the actual code will always overwrites this option with one that always schedules a render. (We suspect this is a defect)

@pdfernhout brought this up in #31, but we have had some further experience with this.

Impact

We noticed in our prototypes a significant amount of “jank” when the list was scrolled. Part of that “jank” we us actually some coding issues in our implementation and we were able to get the performance to improve to a great degree, but we highly suspect that in certain situations under certain environments, a schedule render for every scroll event would make the performance unacceptable.

Discussion

We suspect the eventHandlerInterceptor is potentially a defect.

On the wider topic though which was discussed in #31. The application “knows” that only an aggregate scroll movement of X actual would cause the DOM to need to be updated and that often takes 10x the DOM events to equal something the application actually cares about, so for 9 of those events, we have recalculated the whole of the VDOM which results in a noop for actual DOM mutations. The feeling I get from the discussion in #31 was “let’s discuss real problems, versus potential ones” which, to me, makes a lot of sense. I think we have come up with a use case though that can cause real problems. Implementing a custom eventHandlerInterceptor could resolve this issue (or as suggested in the other ticket, a custom Projector). In both those cases though, it would mean we would have to become the “experts” at VDOM versus and something we are reticent to do.

We hope given a compelling use case, we can find a way to improve Maquette to be able to manage DOM events bubbled up to the application more efficiently.

[CitrusFruits]

@johan-gorter I apologize, I missed your previous comment. I will test it out today.

[CitrusFruits]

@johan-gorter That sounds good to me.