updateComplete tuning or additional API in lit-virtualizer

[Westbrook]

When working with LitElement based web components I am accustomed to being able to rely on await el.updateComplete in order to know when the render process of said element has completed a pass. When attempting to rely on this same interface with lit-virtualizer, particularly when attempting to run DOM snapshot testing with a reasonable amount of stability, the promise seems to resolve sometimes when the DOM is first written, sometimes after the initial scroll management occurs, and sometimes after the items have been applied. I'm not 100% sure but this seems to be due to the number of wrapped await Promise.resolve(); that occur various intersections between lit-virtualizer, LitScroller, LitRepeater, et al. It is possible to tune the resolution for it to be more predictable? If not, would it make sense to provide an alternate API that outlined when the initial batch of items (or lack of items) has been stamped?

[graynorton]

Sure, I'll take a look at what might work best for this use case.

[usergenic]

FWIW, in the virtualizer tests for now, I am essentially using await until(() => /* eventually expected state */) instead of await el.updateComplete