Hey there! What’s the Compose way of sharing focus between two UI elements? I’m trying to replicate this view which shares focus between an input and a list so that the user can both type a search query and use the arrow keys and return to select results without switching back and forth via ⇥

I don't unfortunately have a solution but I am interested if there's a native way to do this

Not sure if there's a different idiomatic way in compose, but generally (in other UI frameworks) the idea is to capture up and down arrow key press events in the input and update the selected index of the list accordingly. It's not "shared focus", as only the input is focused, but there's nothing stopping input on one element to impact the state elsewhere in the app (that's kind of the whole point of event handling).

Thanks @Ruckus! I was hoping for there to be a composable way where I don’t have to know about the keys that I need to send elsewhere, and where I don’t have to fake focus styling in one part. The problem is that there might be special key handlers and different child components in the list items of the result list, which should be encapsulated there with their own key handlers and based on their own focus state. But neither will work if I have to intercept key events at the top level and if the list doesn’t actually receive focus

The problem is that there might be special key handlers...

What do you mean by this? If you're talking about a list view that you create, you could just extract the handlers into functions and call them from both the list or the input depending on who has focus. If you're talking about arbitrary composables, that's a whole different can of worms. A workaround I've used in other UI toolkits is to grab a reference to the target node (e.g. the list) and call it's event handler directly passing in either the event captured from the input, or a new event I constructed for more fine grained control. However, considering UI nodes are functions instead of objects in Compose, I'm not sure what the correct way to go about doing that is.

I have answers to all these questions already, and yes, it’s about arbitrary composition exactly

There is one big difference in that nested handlers are structured. They have to go up and down the tree, so handling order can be deterministic and easy to reason about, whereas arbitrary elements are not.

Arbitrary elements can be enumerated in DFS order

Sure, but what about two siblings. It isn't clear who gets priority.

Why? DFS order makes this very clear

Siblings have an order

That's my point, the order often isn't as clear as it may seem. The obvious example is whatever order they are defined in the code, but that might not line up with many users expectations, such as what is visible on the screen, or where elements appear on the screen. But all of this is arguably beside the point, as the fundamental idea of having multiple elements focused is problematic, as that kind of defeats the whole point of focus in the first place, and can be fairly easily worked around using the methods I mentioned earlier, without having to answer any of these questions.

Aren’t you expecting to be able to both type and move the selection in macOS Spotlight, or the completion in any IDE, or even in your browser address bar?

Sure, but that's not multiple focus. In all of those cases, the focus in on the input, and the appropriate functions are called from the input's event handler. There is still only one thing focused at any given time.

That’s one way of implementing it, but that doesn’t compose. That’s my whole point. I want to be able to plug any component into a list entry and the component should be able to query the focus API just like any other

The same argument applies to input validation, or clicking a button to show or hide parts of the input, or anything on the UI whose interaction modifies anything else on the UI. It's not multiple focus, it's just event handling.

I don’t understand how these examples relate to the point. None of them actually need to be active at the same time

None of them actually need to be active at the same time

Yes, that's exactly my point.

How does bringing up unrelated examples prove your point?

My point is that all of these are essentially the same thing, and your use case doesn't require multiple focus. It's just another example of one elements interaction changing the state of the app that gets represented elsewhere.

No use case requires a built-in focus system or even key handlers in any nested position. I can also hard-code all key handlers at the window root and build my own focus system to keep track of what is going on in the window. I think we can agree that this would not be a reasonable way to go about it but it would be possible, right?

That feels like a strawman argument.

I’m exaggerating your argument to make it clear that the coupling of the two sides of my UI comes at a cost

Ah, I think I see the issue. I apologize. Let me try to explain.

Yes

Is it fair to say that is an entirely separate and unrelated use case from the kinds of things I've been suggesting, or am I still missing something?

I believe we can also just stop here and I’ll be happy with knowing that there aren’t any built-in tools for realizing this in Compose

Fair enough, but if I may, that suggestion actually sounds exactly like what you were suggesting as an exaggeration of my argument: "I can also hard-code all key handlers at the window root and build my own focus system to keep track of what is going on in the window." As ridiculous as that sounds, you may be on to something. You could create a

MultiFocus

composable that can handle any such use cases inside it and dispatch accordingly. You would need to come up with a good way of representing to the user what elements are and are not in focus, as well as how to add or remove elements (or just assume everything in it is always focused I guess), but it could be cool. Instead of the completion in an IDE (which I think still fits into the tightly coupled world), this would be more akin to multiple cursors in an IDE.

No problem 🙂