onFocus callback

[souporserious]

How do you feel about an onFocus callback? So if you have an element that can't receive focus you can add a class yourself or handle the state in something like React and apply a style. I'm trying to build a combobox right now and need to have a fake focus group so the input can remain focused, but still allow choosing a result. Thoughts? I can put together a PR if you like the idea. Maybe something like this?

onFocus: options.onFocus || function (member) {
  focusNode(member.node)
}

Then it would be the user's responsibility to handle focusing the element however they wanted.

edit

Realized this can't be solved with just a callback. I'm guessing another option like groupNode would be required to determine what the focus group is. Any ideas on that?

[davidtheclark]

🤔 I can see the use-case ...

Does this significantly reduce the accessibility of the component? In the past I've handled this in comboboxes by returning focus to the input when the user starts typing letters again.

Realized this can't be solved with just a callback.

Why not? I don't immediately see what's missing that groupNode would provide.

[souporserious]

I tried messing around with it and wasn't able to keep state just in one node, when I used the keyboard it was changing all of them. Maybe I was missing something. I'll take another stab at it tomorrow.

I'll try doing what you suggest by returning focus to input if they continue typing again. I was going off of the majority combobox implementations out there and how they keep the main input focused the whole time.

[davidtheclark]

I guess an onFocus-type callback would be ok. I wonder if there's a better name than onFocus, though, because it be actually focusing, in browser terms.

I'm afraid this might involve some significant rewriting and introduce a lot of potential bugs. You'd have to start tracking which item is "faux-focused" for the up and down arrows to work. I'm open to a PR!

[souporserious]

Ok so I thought I almost had it, but then I hit a snag with stringSearch. I'm wondering if this library can be broken down further?

So you just have something that handles focusing faux or real groups, pretty much an index manager that listens for keyup on an element of your choosing.

Then I'm thinking we can piece out the string search stuff from that since it's not needed for the combobox.

The end user could just pass false for stringSearch when they are making a combobox, which would get rid of all of the above. Maybe I'm overthinking it now. Thoughts?

[davidtheclark]

@souporserious I'm not sure I understand how stringSearch was a snag. You can currently turn it off by settingstringSearch: false. That's what you want, right? Or am I misunderstanding?

[souporserious]

Yes, you are correct. I was under stress trying to get it done and kept getting caught up in the stringSearch stuff. I rolled our own for now since I needed to get it out and had to test it https://github.com/souporserious/react-aria/blob/master/src/utils/FocusGroup.js but I'll PR into here once I get a chance.

[souporserious]

@davidtheclark going to submit a PR for this. Was wondering if you would be interested in using ES2016 for this project? I think we can clean some things up and make it a little more concise. If not, no worries.

[davidtheclark]

Was wondering if you would be interested in using ES2016 for this project?

No, I'd rather keep this simple and run the code as authored, browser-compatible.

[souporserious]

Finally got some time and started a PR. I just threw everything that I needed to get it working on there. Open to any critiques and suggestions you have.