More efficient DOM operation in filter component

[lukas-vlcek]

Currently, the general filter component #60 uses the most naïve implementation when it comes to DOM manipulation. In simple words it generates a new DOM fragment for relevant ListView with every change on it - especially when selecting the list items via mouse pointer (like on every mouseout and mouseenter event as so on). Then it switches the DOM nodes (drops the old one and use the new one). Although browsers seem to be fast with this (the DOM fragment in question is relatively small) there are two issues with this:

• it is creating higher memory and GC pressure (a lot of objects are created and dropped very quickly)
• when in scrolling the underlying DOM element can catch the scroll event during the DOM switch which causes visual and UX distraction

[lukas-vlcek]

The following are perf. charts from manually executed tests (charts are generated by Chrome dev tools Timeline window). We measured how the system consumes resources while we hover with mouse cursor over single ListView DOM list items and handle selected and deselected events.

Before the improvement

After the improvement

Performance characteristics and memory usage has been significantly improved.

We can see that after the improvement we create no new DOM nodes, have less memory pressure, much higher FPS rate and browser spends much more in idle time.