fix(focusZone): handle complex child reordering #1225
Conversation
🦋 Changeset detectedLatest commit: 9a68576 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/primer/primer-components/4es6ua5MQRcponcibKFZ2vGwezcz |
| expect(document.activeElement).toEqual(firstButton) | ||
|
|
||
| // move secondButton and thirdButton to the end of the zone, in reverse order | ||
| focusZoneContainer.appendChild(thirdButton) |
There was a problem hiding this comment.
TIL (from Node.appendChild() on MDN):
If the given child is a reference to an existing node in the document,
appendChild()moves it from its current position to the new position (there is no requirement to remove the node from its parent node before appending it to some other node).
| @@ -7,6 +7,9 @@ async function nextTick() { | |||
| return new Promise(resolve => setTimeout(resolve, 0)) | |||
| } | |||
|
|
|||
| const moveDown = () => userEvent.type(document.activeElement!, '{arrowdown}') | |||
There was a problem hiding this comment.
Verified the magic string '{arrowdown}': https://github.com/testing-library/user-event#special-characters 👍
Using
focusZoneinSelectPanel, I have noticed scenarios where filtering causes items to still be present, but reorder based on similarity to the filter. In these scenarios, focusZone currently has a tendency to mix up the focus order. This happens when two items are moved, but put back in opposite order. To avoid this confusion, we can simply handle all removals first, then handle additions.Merge checklist