New Creation Operator for Mutation Observer #6339
Replies: 2 comments
-
MutationObserver shares a mostly similar interface with IntersectionObserver and ResizeObserver. The latter two are currently at the working and editors draft stage respectively and don't have full browser support yet, but it may be worthwhile to have an creation operator that works with all three. I've already used my own Mutation Observable to great effect in Chrome extensions, but I expect that Intersection and Resize will end up seeing more general use. They all (unfortunately) require the handler on construction so I don't know how creating with instances would work in any case. Perhaps something like this: type DOMObservableType = "mutation" | "resize" | "intersection";
type DOMObservableOptions = {
mutation : MutationObserverInit,
resize : {box ?: "content-box" | "border-box"},
intersection: {
root ?: Element,
rootMargin ?: string,
threshold ?: number
}
}
type DOMObservableEntry = {
mutation : MutationRecord[],
resize : ResizeObserverEntry[] // Not in DOM type library yet
intersection : IntersectionObserverEntry[]
}
function fromDOM<T extends DOMObservableType>(
type : T,
target : Element, // Iterable<Element> ?
options ?: DOMObservableOptions[T]
) : Observable<DOMObservableEntry[T]>{ // Maybe pass the observer instance too like the native callbacks do
//...
} There's also PerformanceObserver and ReportingObserver. |
Beta Was this translation helpful? Give feedback.
-
+1. I’m working on a project using RxJS and I’m currently using a custom |
Beta Was this translation helpful? Give feedback.
-
I think it would be very valuable to have a creation operator for an Observable of a Mutation Observer. It used to be in rxjs-dom already but wasn't ported. I think it allows really cool and reactive ui architectures.
Rough idea: The observable is is for example triggered as soon as there is a child element added to the dom. With the trigger within the observable one could initiate a loading indicator or do some optimistic ui update, while fetching some data from an HTTP server or whatever. Thinks like endless scrolling would be amazing to implement with such an approach.
From an api perspective, I'm unsure whether it would be better to have a creation operator that accepts a mutation observer instance or just the needed parameter.
What do you think of that idea?
Beta Was this translation helpful? Give feedback.
All reactions