Improving the selection of the next active tree after tree deletion

[MichaelBuessemeyer]

This PR improves the selection for the next active tree after deleting a tree.
For further information: Link to Discuss

URL of deployed dev instance (used for testing):

• https://betteractivetreeaftertreedeletion.webknossos.xyz

Steps to test:

• open a skeleton tracing
• create a few trees (can be empty)
• After the deletion of a tree in the middle of the tree list, the next active tree should be the tree above the deleted tree.
• After the deletion of the first tree in the tree list, the next active tree should the first in the list.
• After the deletion the last tree in the tree list, the next active tree should be the tree last tree in the list.

Issues:

• fixes Activate next tree in list after tree deletion  #4323

---

• Updated changelog
• [ ] Updated migration guide if applicable
• [ ] Updated documentation if applicable
• [ ] Adapted wk-connect if datastore API changes
• [ ] Needs datastore update after deployment
• Ready for review

[MichaelBuessemeyer]

@daniel-wer Could you please review this PR?

[daniel-wer]

Nice, worked well in my tests 👍

One thing I noticed is that this method doesn't work if users sorted trees by name (and technically it's not even correct if trees are sorted by timestamp, which is the default, because the code is looking at ids [but id and timestamp order mostly corresponds]). I also see, however, that choosing the correct tree in these circumstances would be harder since the sorting state is most likely component state. Do you have an opinion on this @philippotto?

[philippotto]

One thing I noticed is that this method doesn't work if users sorted trees by name (and technically it's not even correct if trees are sorted by timestamp, which is the default, because the code is looking at ids [but id and timestamp order mostly corresponds]). I also see, however, that choosing the correct tree in these circumstances would be harder since the sorting state is most likely component state. Do you have an opinion on this @philippotto?

I'd say, taking sorting by name into account would be nice to have, but given that the prior behavior was tolerated for so long, this PR should be a sufficient improvement. Since id and timestamp order corresponds, the major use case should be covered by this.

However, groups are probably disturbing the behavior, too, right? In that case, the global sorting is neither by id nor by name. But as I said: this PR should be an improvement, nevertheless, and we have other issues with higher priority in my opinion :)

[MichaelBuessemeyer]

I just noticed that react was complaining because the key prop was missing. I just added it here, as an own PR for this change would be overkill.

[MichaelBuessemeyer]

@daniel-wer Could you please check my newest changes?

[daniel-wer]

LGTM 👍