Watcher support for elements not within the DOM

[lynchbomb]

Spaniel v2.4.6 does not provide support for elements being watched that are not within the DOM. Currently the ElementScheduler caches getBoundingClientRect which is set during the watch phase. Elements not yet within the DOM return default values on getBoundingClientRect which are then cached within the ElementScheduler.

spaniel/src/metal/scheduler.ts

Lines 176 to 188 in f2c580b

	watch(el: Element, callback: (frame: FrameInterface, id: string, clientRect?: ClientRect) => void, id?: string): string {
	this.startTicking();
	id = id || generateToken();
	let clientRect = el.getBoundingClientRect();
	this.queue.push({
	el,
	callback,
	id,
	clientRect
	});
	return id;
	}

Thoughts on exposing a method within Spaniel to force a revalidation of cached getBoundingClientRect on elements being watched? Either on the Watcher or exposing the W (window proxy).

[stefanpenner]

Thoughts on exposing a method within Spaniel to force a revalidation of cached getBoundingClientRect on elements being watched? Either on the Watcher or exposing the W (window proxy).

To make sure we solve this correctly, do you mind providing 1 or 2 examples of needing this functionality. That way we can make sure we are solving the right problem.

e.g. in what valid cases should we try to watch a detached element. Often times, I can see that being an error, in what cases is it legit?

[lynchbomb]

The seemingly legit use-case is via lazy loading images with fixed dimensions and ghosting. Something like leveraging Ember-Spaniel#onInViewportOnce for implementation which would leverage the Spaniel#ElementScheduler.

[lynchbomb]

DM with @stefanpenner:
So one question would be, in theory could Ember-Spaniel#onInViewport be leveraged only when the lazy loaded image is in the DOM? Assuming it was properly detached. Hypothetically this would work around the IE11 bug entirely (#75).

In addition we may actually want to consider making Spaniel (in dev) explode if Watcher tries to watch something detached from the DOM.

[stefanpenner]

I believe that is safe, and would be an "honest" cross browser implementation, as it would only support what it could safely support across its browsers. Eventually if IE11 is dropped, we could choose to loosen.

thoughts @asakusuma / @krisselden

[lynchbomb]

After DMing with @krisselden another proposed solve would be removing the caching of getBoundingClientRect during the init of ElementScheduler#watch. Keeping the ideal of nothing in the read queue should cause a run loop, set() or manipulate the DOM. Nothing outside the queue should read from the DOM only memoized state from read queue.

https://github.com/linkedin/spaniel/blob/v2-release/src/metal/scheduler.ts#L162-L188

If we set clientRect to null here: https://github.com/linkedin/spaniel/blob/v2-release/src/metal/scheduler.ts#L179

and memoized clientRect within the ElementScheduler#applyQueue (read queue) this issue should be solved.

[lynchbomb]

This PR: #79 should address this issue.