A modern programming language that makes developers happier.

kotlinlang

image.png

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

Thanks <@U10EJRH2L>!

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

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

The difficulties you’re describing regarding more complex event handling aren’t much different from nested key handlers

Arbitrary elements can be enumerated in DFS order

Siblings have an order, and the children of the first sibling come before the second sibling on the way down, and vice versa on the way up

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?

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

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

How does bringing up unrelated examples prove your point?

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?

It wouldn’t be very easy to maintain this kind of code, most importantly. Everything would be coupled. And in the same way, I’m trying to avoid coupling the two parts of my UI together. I want to be able to plug in a generic list and a generic input without them having to know about each other, and  while using the built-in focus system and key handlers

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

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