Follow the *Observer pattern more closely

[kenchris]

As currently specified we differ somewhat from other *Observer's on the platform:

Each instance of the Observer class is constructed with a callback, and optionally with some options to customize what should be observed.

Actually only IntersectionObserver takes options as part of the ctor, all others as part of calls to observe()

Instances begin observing specific targets, using a method named observe(), which takes a reference to the target to be observed. The options to customize what should be observed may be provided here instead of to the constructor. The callback provided in the constructor is invoked when something interesting happens to those targets.

We don't have a special target - we don't allow targetting a specific CPU core or similar. We might allow GPU in the future, so we could make this be an enum instead like "cpu" or "gpu". It might make sense to allow observe to change the options.

Callbacks receive change records as arguments. These records contain the details about the interesting thing that happened. Multiple records can be delivered at once.

Yes, all existing observers do that. That might make a lot of sense for us as well, maybe even with timestamp.

The author may stop observing by calling a method called unobserve() or disconnect() on the Observer instance.

We currently use unobserve() - maybe disconnect() is better and also makes more sense if we allow changing options on the fly.

Looking at examples:

[Exposed=(Window)]
interface ResizeObserver {
    constructor(ResizeObserverCallback callback);
    undefined observe(Element target, optional ResizeObserverOptions options = {});
    undefined unobserve(Element target);
    undefined disconnect();
};

I see that you can observe multiple elements and disconnect stops all observations. Now this makes sense thinking about CPU and GPU etc

    enum ComputePressureTarget { "cpu", "gpu" };

    undefined observe(ComputePressureTarget target, optional ComputePressureObserverOptions options = {});
    undefined unobserve(ComputePressureTarget target);
    undefined disconnect();
};

Optionally, a method may be provided to immediately return records for all observed-but-not-yet-delivered occurrences.

This is the takeRecords() method other observers support. With batching that makes sense supporting

End result:

enum ComputePressureTarget { "cpu", "gpu" };
callback ComputePressureObserverCallback = undefined (sequence<ComputePressureObserverEntry> entries, ComputePressureObserver observer);


[Exposed=Window]
interface ComputePressureObserver {
  constructor(ComputePressureObserverCallback callback);
  undefined observe(ComputePressureTarget target, ComputePressureObserverOptions options = {});
  undefined unobserve(ComputePressureTarget target);
  undefined disconnect();
  sequence<ComputePressureObserverEntry> takeRecords();
};

IntersectionObserver also takes thresholds and actually expose those set on the object:

readonly attribute FrozenArray<double> thresholds;

For error handling, I see that MutationObserver observe() throws TypeError