Number input widget

[tomdye]

The number input widget will be a base text input with opinionated defaults and type: number. It will expose properties such as min and max and other number related properties.

These number specific properties should work well with native validation and our onValidate callback.

[vansimke]

@tomdye here are some thoughts that I had on how to attack this issue. Please let me know what you think:

Plan

The Number widget will present itself as a normal text input control with additional properties and behaviors that specialize it to work only with numerical data. The following features are planned:

Features

• constrained to accept only numeric inputs (including non-numeric characters associated with numbers such as periods, commas, and dashes)
• constrainable to provided min and max values and increment with optional step value
  • validated onblur
• optional pretty-printing of displayed values on blur to include customizable delimiter and prefix
  • e.g. support currency with thousands delimiter such as $1,000,000.1234
  • default to not displayed
  • delimiters will be removed when control has focus
• optional "spinner" controls to allow incrementing and decrementing by step
  • bind up and down arrow keys to trigger increment/decrement when they are displayed
  • some spinners bind pageUp and pageDown to inc/dec by larger values, should we do this?
• additional features to consider
  • allow list of suggested values
    • e.g. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/number#Offering_suggested_values

Implementation

• Number widget will wrap text-input widget and delegate most rendering responsibilities to it
• Wrapper will constrain and augment underlying text-input, as appropriate, to provide above features
• adopt theme parameters from text-input but extend styling options to allow spinner arrows to be themed as well
  • perhaps the text-input.m.css module should be renamed input.m.css and contain styles for all input-type controls?
• Expected new properties
  • min? / max?
    • place limits on value - exceeding will trigger validation error
  • step?
    • set increment/decrement value
    • set the number of decimal places to validate against
      • if step set to 0.1, then 3.1 would pass validation, but 3.14 would not
  • delimiter?
    • character to use to group non-fractional digits for display
      • e.g. the comma in 1,000,000.1234
  • decimals?
    • max number of decimals to display
  • prefix?
    • string to be pre-pended to value when displaying
  • formatter?
    • function that will be provided the value and will return the text to be displayed when the control doesn't have focus
    • overrides other format modifiers, such as delimiter
      • this could be combined with the previous three properties into something like this

        formatter?: { 
        prefix?: string,
        decimals?: number,
        delimiter?: string
        } | 
        (value: number): string

[tomdye]

@vansimke I think that the scope of this task should be to implement a basic number input which simply restricts the currently large set of TextInputProperties and sets the input type to number. I believe that at this stage we would rely on default browser / mobile os interaction for increment / decrement and native html5 validation via the existing onValidate / valid properties.

Regarding formatting, I think that this could take some default properties for formatting, ie. commaSeparatedThousands: boolean, maxDecimals: number etc and this would be automatically done before calling the standard onValue callback. Any other custom formatting would be done by the parent widget via its onValue callback.

Regarding currency formatting and display, I believe this would be a further Currency input built on top of this one which would offer some currency defaults ie currency: 'us' perhaps which would use a leading renderer for the currency symbol and apply appropriate decimal / thousands separators.

[vansimke]

@tomdye If we use the native number input, I think that will prevent us from doing any of the formatting settings, yes? I'm okay with that, but if we want to go that way, I would probably eliminate the format-related properties (delimiter, decimals, prefix, and formatter). Do you agree?

[vansimke]

As I've thought about the conversation that I had with @agubler and based on the feedback from @tomdye, I think I'm going to start out by refactoring out a common Input widget from the current TextInput. The idea is that this widget will serve as a generic element that can morph into each of the various input types and, as a result, will probably end up with a ton of properties. The TextInput, and eventually the NumberInput widgets will then wrap this widget and narrow the interface to provide the specific functionality for each type (e.g. minLength and maxLength for TextInput and min, max, and step for NumberInput).

I'm going to start by factoring out the Input widget and get a draft PR started to allow feedback on what works and what doesn't.

[tomdye]

@vansimke I don't think that you need to refactor out the existing text input into anything more generic at this time. It should work fine as it is using the current TextInput.

re. formatting, i think it's ok to start with the simple number input for now.