Call OnUnselected and OnSelected when removing a selected tab item#5986
Call OnUnselected and OnSelected when removing a selected tab item#5986redawl wants to merge 4 commits intofyne-io:developfrom
Conversation
andydotxyz
left a comment
There was a problem hiding this comment.
I think this assumes that the selected item is being removed.
It may be more of an optimisation rather than an actual error, but I think it should be checked.
Thanks for noticing that. The code no longer assumes that the selected item is being removed. I also uncovered another problem, as well as an existing bug. Added unit tests for both cases:
|
| // Current doesn't exist, select last tab | ||
| selectIndex(t, count-1) | ||
| if selected == count { | ||
| // If selected is exactly equal to count, it still exists, |
There was a problem hiding this comment.
I don't understand this sorry. if we are replacing 2 items, where the second (index 1) is selected and then replace with 1 we get:
count = 1
selected = 1
Your comment seems to say that item 1 still exists (which it doesn't) but then sets selected to count - 1 (which is 0). The comments here do not seem to be consistent with the code.
Also should it not just be another case in the select rather than an if/else?
There was a problem hiding this comment.
selected is the index of the selected item, it does not refer to a specific tabitem. State before and after setItems:
Before: [ item1, item2]
After: [item2]
From the tabs perspective, selection is tracked via index, so selected index needs to be moved down by 1 so that item2 still appears to be selected in the ui. However we do not want to call OnSelected since the selected tabItem didn't change (just its index).
Agreed about the if statement can just be two switch cases.
There was a problem hiding this comment.
Hmm, I think I found another existing bug...
If you have 4 doctabs with the last one selected, and you remove tab 2, then tab 3 is selected instead of tab 4
There was a problem hiding this comment.
I may be reading it wrong, but this appears to be inside setItems - so the assumption that it's a removal of any particular item doesn't hold...
There was a problem hiding this comment.
Correct. However, if selected >= count we know an item was removed. There is no other way for the new list to be shorter.
Description:
Fixes #4985
Checklist: