search

adobe / react-spectrum

A collection of libraries and tools that help you build adaptive, accessible, and robust user experiences.
https://react-spectrum.adobe.com
Apache License 2.0
12.2k stars 1.06k forks source link

Support live formatting in NumberField #6156

Open oscarcarlstrom opened 3 months ago

oscarcarlstrom commented 3 months ago

Provide a general summary of the feature here

I would be very nice to enable live formatting in the RAC NumberField component.

🤔 Expected Behavior?

When a user types the value is formatted while typing.

😯 Current Behavior

The value is currently only formatted when a user blurs (click outside/tab out) the input.

💁 Possible Solution

I would expected this to be the default behavior. But I imagine some developers would like to turn it off. So either a prop liveFormatting?: boolean or a prop noLiveFormatting?: boolean.

🔦 Context

When inputing large numbers (such as when a customer is applying for a loan at a bank), it is much easier for a user to read: 11 500 000, than 11500000 while typing.

💻 Examples

No response

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

LFDanLu commented 3 months ago

@snowystinger if I remember correctly didn't we want to avoid/minimize live formatting in the NumberField since it felt odd to change the value from under the user as they were typing in the field? There may have been some other challenges getting the live formatting itself working but that was the main thing I remember from all that time ago.

snowystinger commented 3 months ago

Thanks for the issue. Please see https://react-spectrum.adobe.com/react-aria/NumberField.html#controlled for part of why we do not do live formatting currently. Also, related discussion https://github.com/adobe/react-spectrum/discussions/6061

In addition, as @LFDanLu pointed out, live formatting would be more difficult over live onChanges because various characters and symbols would be added or removed while typing. This could easily lead to losing the cursor position and would make announcements through assistive technologies not as clear. These problems are also exacerbated by putting the field into a controlled state.

We'd love to be able to support this someday, but there are some major hurdles to figure out before then.

oscarcarlstrom commented 3 months ago

@LFDanLu / @snowystinger Thank you for the swift reply! I think I know where you are coming from. In my experience it depends a little bit on how the live formatting is applied. But I would also like to point out that from an accessibility perspective, live formatting could also ease on cognitive load as big numbers become more readable instantly. I would argue that this not only makes it easier for people with cognitive disabilities or dyslexia, but for everyone. As it takes away load from the brains working memory.

As for characters being removed/added. In our (Scandinavian) use case, this isn’t actually an issue. Since numbers are separated with white spaces, which isn’t announced by screen readers individually as the user types.

From what you are saying maybe default isn’t the way to go, but how about making it optional? And I definitely get that it adds some inconvenience by making the component controlled internally. Hope to see this in the future, would be much appreciated 🙏

Would you consider allowing strings as value for the NumberField as an intermediate solution though? That would make it possible for us to add live formatting ourselves, in a parent component.

Also want to say that I think you guys are doing an amazing job with RAC, it is a pleasure to use and a real productivity booster. It is also the only accessible library that I have encountered that actually works. It is also amazing how comprehensive you managed to make it. So thank you!

snowystinger commented 3 months ago

Thanks for the message!

I don't think we should open value up to being a string, that could have a whole host of problems. However, in the past when thinking about this, I had an idea that we could expose 'inputValue' and 'onInputChange' props, much like Combobox does.

I've not had the time to test it out though, and I'm not sure what kinds of misuse it could open the component to. Parsing those partial numbers is hard, and I'm worried people would use inputValue to make decisions which are locale specific.

For a point of comparison, NumberField has ~400 unit tests, compared to ListView, which has drag and drop and all kinds of other complex interactions, which only have ~160. Even ComboBox only has ~250. And those are both some of our most complex components.

Again, I don't disagree with wanting to support live formatting. I am just not convinced we've found the way to do it yet.