feat: focus loading indicator in rac tree #8270
Conversation
| @@ -1172,11 +1171,11 @@ describe('Tree', () => { | |||
| await user.tab(); | |||
| expect(document.activeElement).toBe(rows[0]); | |||
| await user.keyboard('{PageDown}'); | |||
| expect(document.activeElement).toBe(rows[20]); | |||
| expect(document.activeElement).toBe(rows[21]); | |||
|
|
|||
| // Check that it didn't shift the focusedkey to the loader key even if DOM focus didn't shift to the loader | |||
I think it should be handled here. That said, async loading isn't currently supported in Table but we can try to see how it works in GridList |
There was a problem hiding this comment.
LGTM, nice work figuring out the lack of data-collection on the loader. I'll pull this into the async tree loading branch I have to test the case where the loader disappears. Now that we have this working in tree (and by extension other components that use ListKeyboardDelegate), we'll want to propagate these changes to other collection components that support async, but that can be followup/separate ticket
|
just a heads up: tested in my PR for multi loader support and found some odd behavior where the focus seems to remain on the loader when loading is complete, but keyboard navigation no longer seems to work, digging into what might be happening |
Seems like the issue was that in the
getKeyPageBelowmethod in ListKeyboardDelegate,this.layoutDelegate.getItemsRect(nextKey)was returningnullwhen the nextKey was the loading indicator. When taking a closer look at thegetItemRectmethod, we were early returningnullfromgetItemElementsince there wasn't[data-key]or[data-collection]on the loading indicator.✅ Pull Request Checklist:
📝 Test Instructions:
Should check the following things:
Use the RAC Tree stories
🧢 Your Project: