feat: Allow each extension to add a change handler.

[laurensvalk]

The basics

• I validated my changes

This is a draft PR for discussion; see notes below. Also still needs tests.

The details

Resolves

I was having some difficulty "merging" several onchange handlers, i.e. adding one to a block that already uses one as part of another extension.

Originally posted by @laurensvalk in #7483 (comment)

Yeah there's not a good way to do this at the moment :/ we have similar problems with other mixins.

Originally posted by @BeksOmega in #7483 (comment)

Proposed Changes (and proposed next step)

Implement Block.addOnChange. Similar to Block.setOnChange but adds them to a list, and later calls them in the same order they were added.

Block.setOnChange is kept to preserve backwards compatibility, though some duplicate code could be merged. The handler set by setOnChange could always be called first (even if it was set later) for backwards compatibility.

In practice, this means users can easily enforce the order when they fill the extensions[] list on the block specification.

Reason for Changes

When a block already has an onChange handler, calling setOnChange from another extension currently overrides it.

This makes it difficult to keep extensions small and local, i.e. an extension that deals with a field's final value as discussed in #7483, combined with some other extension on the block.

Similarly, it means onChange handlers can't easily be used with blocks that already use them internally, like those in block-shareable-procedures.

Test Coverage

TBD

Documentation

TBD

[BeksOmega]

Hello! Before reviewing this, just want to check if using a non-mixin extension with a call to this.workspace.addChangeListener works for your use-case?

[laurensvalk]

It seemed useful more generally since you mentioned running into the same problem, but I'm happy to try it another way.