Merge pull request #443 from ing-bank/chore/update-formatter-documentation
chore(field): update formatter documentation
This commit is contained in:
commit
f9002d93bb
2 changed files with 3 additions and 118 deletions
|
|
@ -1,117 +0,0 @@
|
||||||
# FormatMixin
|
|
||||||
|
|
||||||
The FormatMixin keeps track of the `modelValue`, `formattedValue` and `serializedValue`.
|
|
||||||
It is designed to work in conjunction with `LionField`.
|
|
||||||
|
|
||||||
## Concepts of different values
|
|
||||||
|
|
||||||
### model value
|
|
||||||
|
|
||||||
The model value is the result of the parser function. It will be stored as `.modelValue`
|
|
||||||
and should be considered the internal value used for validation and reasoning/logic.
|
|
||||||
The model value is 'ready for consumption' by the outside world (think of a Date object
|
|
||||||
or a float). It can(and is recommended to) be used as both input value and
|
|
||||||
output value of the `LionField`.
|
|
||||||
|
|
||||||
Examples:
|
|
||||||
|
|
||||||
- For a date input: a String '20/01/1999' will be converted to `new Date('1999/01/20')`
|
|
||||||
- For a number input: a formatted String '1.234,56' will be converted to a Number: `1234.56`
|
|
||||||
|
|
||||||
### view value
|
|
||||||
|
|
||||||
The view value is the result of the formatter function.
|
|
||||||
It will be stored as `.formattedValue` and synchronized to `.value` (a viewValue setter that
|
|
||||||
allows to synchronize to `._inputNode`).
|
|
||||||
Synchronization happens conditionally and is (by default) the result of a blur. Other conditions
|
|
||||||
(like error state/validity and whether the a model value was set programatically) also play a role.
|
|
||||||
|
|
||||||
Examples:
|
|
||||||
|
|
||||||
- For a date input, this would be '20/01/1999' (dependent on locale).
|
|
||||||
- For a number input, this could be '1,234.56' (a String representation of modelValue
|
|
||||||
1234.56)
|
|
||||||
|
|
||||||
### serialized value
|
|
||||||
|
|
||||||
This is the serialized version of the model value.
|
|
||||||
It exists for maximal compatibility with the platform API.
|
|
||||||
The serialized value can be an interface in context where data binding is not supported
|
|
||||||
and a serialized string needs to be set.
|
|
||||||
|
|
||||||
Examples:
|
|
||||||
|
|
||||||
- For a date input, this would be the iso format of a date, e.g. '1999-01-20'.
|
|
||||||
- For a number input this would be the String representation of a float ('1234.56' instead
|
|
||||||
of 1234.56)
|
|
||||||
|
|
||||||
When no parser is available, the value is usually the same as the formattedValue (being \_inputNode.value)
|
|
||||||
|
|
||||||
## Formatters, parsers and (de)serializers
|
|
||||||
|
|
||||||
In order to create advanced user experiences (automatically formatting a user input or an input
|
|
||||||
set imperatively by an Application Developer).
|
|
||||||
|
|
||||||
Below some concrete examples can be found of implementations of formatters and parsers,
|
|
||||||
extrapolating the example of a date input.
|
|
||||||
|
|
||||||
### Formatters
|
|
||||||
|
|
||||||
A formatter should return a `formattedValue`:
|
|
||||||
|
|
||||||
```js
|
|
||||||
function formatDate(modelValue, options) {
|
|
||||||
if (!(modelValue instanceof Date)) {
|
|
||||||
return options.formattedValue;
|
|
||||||
}
|
|
||||||
return formatDateLocalized(modelValue, options);
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
Notice the options object, which holds a fallback value that shows what should be presented on
|
|
||||||
screen when the user input resulted in an invalid modelValue
|
|
||||||
|
|
||||||
### Parsers
|
|
||||||
|
|
||||||
A parser should return a `modelValue`:
|
|
||||||
|
|
||||||
```js
|
|
||||||
function parseDate(formattedValue, options) {
|
|
||||||
return formattedValue === '' ? undefined : parseDateLocalized(formattedValue);
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
Notice that when it's not possible to create a valid modelValue based on the formattedValue,
|
|
||||||
one should return `undefined`.
|
|
||||||
|
|
||||||
### Serializers and deserializers
|
|
||||||
|
|
||||||
A serializer should return a `serializedValue`:
|
|
||||||
|
|
||||||
```js
|
|
||||||
function serializeDate(modelValue, options) {
|
|
||||||
return modelValue.toISOString();
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
A deserializer should return a `modelValue`:
|
|
||||||
|
|
||||||
```js
|
|
||||||
function deserializeDate(serializeValue, options) {
|
|
||||||
return new Date(serializeValue);
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
### FieldCustomMixin
|
|
||||||
|
|
||||||
When creating your own custom input, please use `FieldCustomMixin` as a basis for this.
|
|
||||||
Concrete examples can be found at [`<lion-input-date>`](../../input-date) and
|
|
||||||
[`<lion-input-amount>`](../../input-amount).
|
|
||||||
|
|
||||||
## Flow diagram
|
|
||||||
|
|
||||||
The following flow diagram is based on both end user input and interaction programmed by the
|
|
||||||
developer. It shows how the 'computation loop' for modelValue, formattedValue and serializedValue
|
|
||||||
is triggered.
|
|
||||||
|
|
||||||
[Flow diagram](./formatterParserFlow.svg)
|
|
||||||
|
|
@ -27,7 +27,9 @@ Examples:
|
||||||
|
|
||||||
- For a date input, this would be '20/01/1999' (dependent on locale).
|
- For a date input, this would be '20/01/1999' (dependent on locale).
|
||||||
- For a number input, this could be '1,234.56' (a String representation of modelValue
|
- For a number input, this could be '1,234.56' (a String representation of modelValue
|
||||||
1234.56)
|
1234.56).
|
||||||
|
|
||||||
|
A value will not get formatted if it is invalid, so the user won't get rewarded for a falsy input.
|
||||||
|
|
||||||
### serializedValue
|
### serializedValue
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue