Inconsistent order around disconnectedCallback()

[danwulff]

Between two docs pages I see inconsistent documentation around the order of calls surrounding super.disconnectedCallback().

On the lifecycle docs. I see the super call come before other code is run:

disconnectedCallback() {
  super.disconnectedCallback()
  window.removeEventListener('keydown', this._handleKeydown);
}

On the events docs. I see the super call come after other code is run:

disconnectedCallback() {
  window.removeEventListener('resize', this._handleResize);
  super.disconnectedCallback();
}

Is there a correct order? My assumption given the context is that the super call should be made at the very end of the callback.

[justinfagnani]

The order doesn't matter in most cases. For connected and disconnected there's little in the superclass implementations that you could depend on.

Order matters for overriding update() (changes to reactive properties before super.update() become part of the current batch, changes after enqueue a new batch) and I thought we pointed that out, but I can't find it. @kevinpschaaf do you remember where that is? We should clarify that in the lifecycle docs.