Locale aware double input

[t-unit]

Environment

Package version: 17.0.1

Describe your question

Depending on the local/language setting of an app, users expect to input floating point number with varying decimal separators. (E.g. see https://en.wikipedia.org/wiki/Decimal_separator#Conventions_worldwide).

I found that this library does not have any support for locale aware parsing, as DoubleValueAccessor is using double.tryParse that does not take any locale into account.

1. What is the intended way to deal with different locales and floating point formats an this library?
2. Shouldn't this library already take care of this an provide proper parsing for any locals? (It already has a dependency towards intl)

We came up with a custom value accessor:

class NumberFormatDoubleValueAccessor extends ControlValueAccessor<double, String> {
  NumberFormatDoubleValueAccessor(this.format);

  final NumberFormat format;

  @override
  String modelToViewValue(double? modelValue) => format.format(modelValue);

  @override
  double? viewToModelValue(String? viewValue) =>
      (viewValue == '' || viewValue == null)
          ? null
          : format.tryParse(viewValue)?.toDouble();
}

that allows specifying a format like NumberFormatDoubleValueAccessor(NumberFormat.decimalPattern('de')).

[vasilich6107]

What is the intended way to deal with different locales and floating point formats an this library

It depends on the individual project preferences

Shouldn't this library already take care of this an provide proper parsing for any locals?

Library provides a form engine that encapsulates the logic of manipulating with the form state + mechanisms of validators/asyncValidators
All basic valueAccessors are bonus points and serve nicely for kickstarting + as example of implementation.
Proper parsing of any locales is just one from tons of possible edge cases. The library should definitely avoid supporting all of them.
This library depends on intl package mostly due to the date time value accessor.
As time goes I'm pretty sure that this was not the best decision to include intl in scope of this package cause it just makes maintenance and update of the project more complex
Here is an example of PR that aimed to overcome consequences of having intl on board.
827c895

It would be better to move DateTimeValueAccessor reference implementation to README.md and make the life a bit easier.