How would you implement a toolbar?

[jossmac]

I'd like to build something like the Radix toolbar. I was hoping it could be achieved with some combination of useListState and useActionGroup + useActionGroupItem but the navigation and selection are bound together so you end up with tabbable "islands", rather than a single toolbar that's navigable with arrow keys regardless of group selection behaviour.

[devongovett]

You could use FocusScope + useFocusManager for this: https://react-spectrum.adobe.com/react-aria/FocusScope.html#usefocusmanager-example

[getDanArias]

Howdy! I bumped into this discussing while researching how to implement the ActionGroup component present in React Spectrum but using only React Aria. The example that you link works but it still has the tab navigation in the toolbar. The behavior in React Spectrum's ActionGroup is that once one tabs into the toolbar and one can only navigate with the arrow keys as the tabbing again takes us to the next component group: https://react-spectrum.adobe.com/react-spectrum/ActionGroup.html#example

May you have some insight please if this is achievable with React Aria? 🙏

[devongovett]

We do have a Toolbar in React Aria Components now. Does that do what you're looking for? https://react-spectrum.adobe.com/react-aria/Toolbar.html

[getDanArias]

Yes, this is perfect. Thanks for your reply. I missed it when going over each RAC :)

[ritz078]

I implemented it recently and the most complicated was the addition of menu but I was able to implement those too with some custom code. Focus Manager was biggest help here. See #4458 for more details

[jossmac]

Thanks for that @ritz078, I haven't yet implemented a menu but it will likely come up. Should be able to use the same roving tabIndex technique.

Here's where I got to:

toolbar-navigation.mov

[GermanJablo]

If I use the component inside the toolbar on mobile, when I press the buttons the virtual keyboard closes. What would be the way to prevent this?

From what I see, it seems to me that this behavior is due to usePress().

Should I make a custom button for the toolbar and add all the hooks to it except usePress()?

I feel like I'm complicating something that should be simpler. Isn't there some prop or something designed for this use case?

[snowystinger]

Yeah, I don't see that staying open behavior on my iOS device without preventing focus on pointerdown, which is probably what I was referring to earlier (sorry, been a little while since I looked at this).

Possibly you could use our very hidden/secret prop https://github.com/adobe/react-spectrum/blob/main/packages/%40react-aria/interactions/src/usePress.ts#L30
But we don't like to advertise it because it should only be used in very rare circumstances. I think in this case it is ok. It's a similar usecase to the 'clear button' in a combobox or searchfield where you want to keep editing. Just be mindful of user flows for more than touch. Try it with a screen reader, try it with a mouse, and try all the same editing with an attached keyboard.

[GermanJablo]

Yeah, I don't see that staying open behavior on my iOS device without preventing focus on pointerdown, which is probably what I was referring to earlier (sorry, been a little while since I looked at this).

That's weird. I just tried a simple on IOS and it doesn't close the keyboard. I'm not adding anything...

Possibly you could use our very hidden/secret prop https://github.com/adobe/react-spectrum/blob/main/packages/%40react-aria/interactions/src/usePress.ts#L30

The problem with that is that it doesn't activate the hover and press states

[snowystinger]

Could you share the example you tried? Possibly a screen recording as well. Maybe I've misinterpreted something here.

[GermanJablo]

Oh, it seems that I was calling some function inside onClick that caused that behavior, and the states thing was a problem with the css selector. preventFocusOnPress solves my problem perfectly. My only suggestion would be to expose it in the ts interface.

Sorry for the inconvenience and thank you very much for the help!

[snowystinger]

We are very hesitant to expose that one. It's not really the full story and it's usually paired with another possibly dangerous/exclusionary prop which makes it easy to exclude certain user groups from being able to complete a task.

We may eventually find a better way to signal that, but for now, making it a very conscious choice through (lack of) types is the best option we've come up with.