Keeping track of item references

[stephenwf]

A bit of bug prediction: If you have the following in a list (say a range)

items: [
  { id: 'abc-1', type: 'Canvas' },
  { id: 'abc-2', type: 'Canvas' },
  { id: 'abc-1', type: 'Canvas' },
]

And you "select" the first item to edit - all is good, we know the index (0) and know what to edit when you maybe specify a box selector for that canvas.

Similarly, if you change it's position within the scope of the editor, we update the pointer to the new index. BUT - if you were to change the order outside of the editing scope (the one that's editing the selector) then it will could see a notification of change like this:

items: [
  { id: 'abc-1', type: 'Canvas' }, <-- which 
  { id: 'abc-1', type: 'Canvas' }, <--
  { id: 'abc-2', type: 'Canvas' },
]

So all it has is this list, and an index of 0 to go by. The only piece of information that might be available is a reference equality check (===) on the object, but.. that could also technically change from the outside.

Options:

• Close the right-panel if things are re-ordered or changed (confusing?)
• Add an internal _id or something to each reference in these list to uniquely identify them (lots of work)
• If the list changes like the above, then we "drop" the selector editing from the right panel until it's reselected (confusing?)
• Implement a "lock" on the list if you're editing a target preventing outside edits (maybe lots of work and confusing)
• Make sure the reference equality check is reliable and sanity check that our index + identifier matches before updating

The core issue:

• Item references in a list are identifiable by their type/id and their index
• Id/Type can be duplicated in the same list
• Indexes can change

[stephenwf]

Having reviewed this further, I think it should be done at the IIIF Parsing level - with an internal _id added to each reference. This can be used to uniquely identify resources. It would need to be added to helpers that create references so that it is deterministic (for server vaults + undo/redo).

However, the reordering seems quite stable now. So a low priority issue.