Change event element registry

[ewpatton]

Is your feature request related to a problem? Please describe.

In App Inventor, we have an option to arrange the parameters of definition blocks (events, procedures) either horizontally or vertically. Because this changes the block, we want to leverage Blockly.Events.Change to record the operation in the undo/redo stack. However, there is no way to support new elements in the Change event without modifying core.

Describe the solution you'd like

I propose the following API:

Blockly.Events.Change.elementRegistry_ = {};
Blockly.Events.Change.registerElement = function(element, callback) {
  Blockly.Events.Change.elementRegistry_[element] = callback;
};

so that we could then call in our code:

Blockly.Events.Change.registerElement('parameter_orientation', function(event) {
  // handle event here
});

The whole of the switch in Change.run could be rewritten using this API, or we could just have it as a lookup in the default clause. I have no preference either way, but the former might be useful if people want to further tweak the behavior of Blockly core behavior.

Describe alternatives you've considered

Alternatively, we can monkeypatch the run method, but that doesn't really help much.

Additional context

[rachel-fenichel]

@samelhusseini did your change fix this? If so, is there documentation that we need to write as a follow-up?

[samelhusseini]

Not quite, my change now allows us to support any number of registered events in Blockly. This however is specifically for Change events. @ewpatton aside from better grouping of events, what benefit does using a Block Change event give you? As opposed to creating a new event type that is specific to your Change (eg: ParameterBlockChange) with it's own run method.

[ewpatton]

1. It seemed logical to group it along with similar events that change the appearance of a block (collapse, etc.) without introducing a whole new event--where we are in the Blockly history has a grand total of 5 event types...
2. At the time, there wasn't any way to register new events without patching because of how fromJson was implemented. My guess without having looked too deeply at it (read: at all) is that your change plus a new event type would probably be sufficient to cover this use case.

[cpcallen]

We probably need to rethink block change events entirely; at the moment we more or less rely on the block implementation itself to fire them at the appropriate time, and to provide information about the change encoded purely as extra state, and this leads to all kinds of difficulties, including but not limited to:

• There is no way to encode a block change that does not result in a change to the block's extra state.
• The code that generates the event needs to have saved the block's extra state before it begins the mutation.

It would probably be better to have a set of events that are mechanistically fired any time a block's list of inputs (and external connections) changes, but there are a lot of details to consider e.g. do we fire such events when adding inputs at block creation time (probably not?).

See also #1036 and #1717.