@goderbauer this is basically the new API I added to make this work. I'm not 100% how I feel about it, but it does allow the viewport elements to just mixin a class to support the scroll notifications

You mentioned you tried mixin's (so maybe this doesn't work), but could we have something like this:

• Element._attachNotificationTree always sets _notificationTree = _parent?._notificationTree;
• a new NotifiableElementMixin overrides _attachNotificationTree to set itself as the _notificationTree and it provides the abstract onNotification method.
• Element.onNotification is removed

That way we wouldn't need the awkward handlesNotification thing...

Users would just create custom elements with NotifiableElementMixin mixed in and implement the onNotification method.

You can't apply a mixin to a type that overrides a private method. For example, the _attachNotificationTree override defined by the mixin will conflict with the _attachNotificationTree that the NotificationElement inherits from Element.

The only way around this is to make the method public. We could use a protected annotation though. I do like this API better than what I have.

You can't apply a mixin to a type that overrides a private method.

This seems to work in dartpad:

class Foo {
  foo() {
    _attachNotificationTree();
  }
  
  _attachNotificationTree() {
    print("hello");
  }
}

mixin FooMixin on Foo {
  @override
  _attachNotificationTree() {
    print("Hell from mixin");
  }
}

class Ha extends Foo with FooMixin {
  
}

main() {
  Ha().foo();
}

Ugh, never mind. This only works because Ha is in the same file...

Making it protected doesn't sound like the worst idea then...

Yeah, its not so bad - and its not the only element API that is protected too

nit: somehow this sentence sounds grammatically incorrect?

fixed

add documentation explaining when this is called.

borrowed some existing docs

nit: remove extra white space.

done

why the optionalTypeArgs annotation?

outdated, removed

Viewport -> [Viewport]

done

Maybe rename to ViewportElementMixin to keep the naming scheme?

done

We should probably link to this from some other docs as well so people implementing custom viewports find it.

What is a good place where we describe this - on Viewport itself?

added a See More section

Even though nothing broke in customer tests or g3, do you think we should leave this and mark it deprecated? I could also leave the old dispatch path and instead add a new method to do a fast dispatch

leaving this and the old dispatch in as deprecated sounds reasonable to me. I just wonder if we can find a reasonable new name for the new dispatch. fastDispatch sounds strange after we remove the regular dispatch - and what if we find an even faster dispatch in the future?

maybe I could just leave the BuildContext dispatch and deprecate the dispatch on Notification?

that is, BuildContext would have the new dispatch and Notification would keep the old

That sounds reasonable. We'd just have to check all docs pointing to it on the Notification and update them to point to BuildContext instead.

leaving this and the old dispatch in as deprecated sounds reasonable to me. I just wonder if we can find a reasonable new name for the new dispatch. fastDispatch sounds strange after we remove the regular dispatch - and what if we find an even faster dispatch in the future?