The on('mutation', ...) listener allows call-backs to fire if any nodes were added to or removed from a node-list, but it doesn't provide more granular information describing exactly what happened. Except where performance is a concern, this is a better approach since it leads to simpler code, but there almost certainly will be use cases where performance does matter, and where a more granular description of the change will be necessary.
However, similar call-back APIs created in the past have often required the receiver of the events to write translation code before the events can be processed by the receiving code. From memory, I think there have been a few reasons for this:
- Describing nodes that have been added and removed is tricky since the indexes have all changed.
- It's possible to describe the set of actions that would be necessary to modify a similar list ordered in the old way, so that it's now ordered in the new way, but I'm not sure that's always helpful.
- It's possible to describe the set of node movements that occurred, but that's almost never useful.
Instead, I propose we wait until we have a few instances of concrete code to look at, so that we can experiment with different approaches, and see what works best in practice. In the meantime, implementations will be able to figure out the movements that occurred by caching the old values and comparing.
The
on('mutation', ...)listener allows call-backs to fire if any nodes were added to or removed from a node-list, but it doesn't provide more granular information describing exactly what happened. Except where performance is a concern, this is a better approach since it leads to simpler code, but there almost certainly will be use cases where performance does matter, and where a more granular description of the change will be necessary.However, similar call-back APIs created in the past have often required the receiver of the events to write translation code before the events can be processed by the receiving code. From memory, I think there have been a few reasons for this:
Instead, I propose we wait until we have a few instances of concrete code to look at, so that we can experiment with different approaches, and see what works best in practice. In the meantime, implementations will be able to figure out the movements that occurred by caching the old values and comparing.