Currently angular is re-rendering the entire download queue whenever a download's state changes.
This is inefficient, but when combined with a long download queue the frequency of websocket progress updates causes many thousands of dom nodes to be created very quickly. This causes a large increase in memory usage, which in my experience continues to worsen until the tab is closed.
This PR adds a trackBy function to the ngFor of each half of the queue to resolve this by preventing unnecessary re-rendering.
alexta69
commented
10 months ago
Currently angular is re-rendering the entire download queue whenever a download's state changes.
This is inefficient, but when combined with a long download queue the frequency of websocket progress updates causes many thousands of dom nodes to be created very quickly. This causes a large increase in memory usage, which in my experience continues to worsen until the tab is closed.
This PR adds a
trackByfunction to thengForof each half of the queue to resolve this by preventing unnecessary re-rendering.Fixes #297