Floating Menu Performance - HostListener

[goerlibe]

Hi,

We are working on a legacy application with a large number of editors and are noticing a severe performance impact of the floating menu. Looking at the ngx-editor source code I think the problem is the @HostListener decorator, which is known to cause extra change detection cycles - In our case: clicking anywhere on the page triggers almost 200 change detection cycles, resulting in a completely unresponsive app.

According to https://dev.to/angular/ain-t-nobody-needs-hostlistener-fg4 an alternative solution is to acces the underlying events directly and managing them using rxjs. I don't quite understand the suggested rxjs magic yet and have not been able to verify the solution, but overall it seems not too hard to implement. Is there any chance you might take a look at it?

PS: A fix for Angular 14 would be very highly appreciated. Stakeholders are pushing new features and are currently not giving us enough time to upgrade this beast of an app with its many dependencies.

[jneuhaus20]

I actually added #588 for this exact thing yesterday, with a link to a related SO question.

The recommended approach there, according to a couple answers, is to listen to document:mousedown a single time for the library and subscribe to it multiple times in a Pub-Sub pattern. Depending how you did it, you could remove the @HostListener entirely (e.g. a service would probably use fromEvent).

If you wanted to get real fancy, this sort of thing could justify a standalone library that would become a dependency (multiple projects would probably love it.) If the service's "subscribe" method takes the element, it can return an observable already piped through a filter so it only receives relevant events. You could also implement memoization if needed pretty easily, which is more or less just saving the filtered observable, keyed by the parameter, and returning it instead of making a new one.

[jneuhaus20]

As far as the rxjs magic in that dev.to article, it's surprisingly simple, just not overly clear when written like that. I like to break out those streams:

// mousedown$ is obviously "mousedowns"

// Only the moves after mousedown
const movesAfterMousedown$ = mousedown$.pipe(
  switchMap(_ =>mousemove$) // I like _ instead of () if you're not going to use the param, less parentheses to think about
);

// I don't like taps in the middle, that's literally a side effect, and those are the devil
const newPosition$ = movesAfterMousedown$.pipe(
  map(event => ({
    left: `${event.clientX}px`,
    top: `${event.clientY}px`,
  }),
);

// A little pedantic to make a dedicated stream, but very obvious what it is this way
const newPositionsThatStopAfterTheNextMouseup$ = newPosition$.pipe(
  takeUntil(mouseup$)
);

// Setting the style _is_ a side effect, but you can turn them on/off very easily if they're their own stream
const setStyle$ = newPositionsThatStopAfterTheNextMouseup$.pipe(
  tap(position => {
    this.style = position;
  }
);

// I like to just merge all (and only) the side effects.  That way it's a clear set of "outputs" (observable behavior.)
// that can be toggled off/on when needed.
merge(
  setStyle$
).pipe(
  // This is just a convenient tactic for unsubscribing on destruction. You could also use SubSink, or store the subscrption
  // as a member and call unsubscribe in ngOnDestroy
  takeUntil(this.destroy$)
).subscribe();