Escape focus inside of GridList

[akeohanePing]

Hi there,

I am looking to implement a GridList that allows for inputs, and components with overlays, to be placed inside the GridListItems. This is working almost perfectly out of the box.

however there is an edgecase where when focus gets to an input, left and right keys move focus left and right instead of moving the curser left and right within the input.

Is it possible or advisable to wrap the textinput in a escape focus element, so that when going left and right through the row, focus gets to the wrapper, but not directly to the text input unless enter is pressed? Adjusting tab index does not seem to impact whether or not something can receive focus from left and right arrow keys.

my implementation is custom using the hooks from react-aria and react-stately, but is functionally nearly identical to this:

Thanks for your help and the excellent package.

https://codesandbox.io/p/sandbox/modest-forest-9jh68k

[snowystinger]

Hi, thanks for the discussion. I'm not going to open a pdf attachment. Can you please either create a codesandbox, stackblitz or a github project that can be safely viewed?

Are you using the GridList prop keyboardNavigationBehavior="tab". This is the intended way for inputs to work inside GridList at this time.

[akeohanePing]

Haha fair enough @snowystinger. ive added a code sandbox.

Tabbing seems to work, but I think we can agree that with large lists, using arrow keys would be a more ideal user experience.

Would you consider the escape focus functionality that I described above to be an anti pattern, or something that potentially would be worth pursuing?

I could get something working, with my implementation using the exposed useGridList hooks, but it basically came down to deleting the onkeydown from the row when focus was on the container, and having a custom onKeyDown function active at that point. Pretty hacky, brittle, and not great.

Curious if some sort of escape focus parent/child element is on your radar at all.

[snowystinger]

Thanks for that. From your use case, I think think the prop I suggested before would be the way to go at the moment. That prop was the first bit of work on what we refer to as "edit mode" and will allow you to use the inputs as you would expect, movement from the table to the contents of the cell changes, but that's expected.

Were you able to give it a try?

Here are some related issues:
Input field inside GridList
Grid navigation edit mode