@lion/ui 0.20.0 → 0.21.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (94) hide show
  1. package/components/form-core/src/FormatMixin.js +10 -5
  2. package/components/form-core/test-helpers/mimicUserInput.js +1 -0
  3. package/components/form-core/test-suites/FormatMixin.suite.js +31 -14
  4. package/components/input-amount-dropdown/src/LionInputAmountDropdown.js +51 -8
  5. package/components/input-amount-dropdown/test/lion-input-amount-dropdown-integrations.test.js +5 -0
  6. package/components/input-amount-dropdown/test-suites/LionInputAmountDropdown.suite.js +1 -0
  7. package/components/input-datepicker/src/LionInputDatepicker.js +4 -0
  8. package/components/input-datepicker/test/lion-input-datepicker.test.js +55 -0
  9. package/components/input-range/src/LionInputRange.js +51 -8
  10. package/components/input-range/test/lion-input-range.test.js +114 -0
  11. package/custom-elements.json +415 -96
  12. package/dist-types/components/form-core/src/FormatMixin.d.ts.map +1 -1
  13. package/dist-types/components/form-core/test-helpers/mimicUserInput.d.ts.map +1 -1
  14. package/dist-types/components/form-core/test-suites/FormatMixin.suite.d.ts +8 -0
  15. package/dist-types/components/form-core/test-suites/FormatMixin.suite.d.ts.map +1 -1
  16. package/dist-types/components/input-amount-dropdown/src/LionInputAmountDropdown.d.ts +24 -6
  17. package/dist-types/components/input-amount-dropdown/src/LionInputAmountDropdown.d.ts.map +1 -1
  18. package/dist-types/components/input-amount-dropdown/test-suites/LionInputAmountDropdown.suite.d.ts.map +1 -1
  19. package/dist-types/components/input-datepicker/src/LionInputDatepicker.d.ts +1 -0
  20. package/dist-types/components/input-datepicker/src/LionInputDatepicker.d.ts.map +1 -1
  21. package/dist-types/components/input-datepicker/test/lion-input-datepicker.test.d.ts.map +1 -1
  22. package/dist-types/components/input-range/src/LionInputRange.d.ts +11 -0
  23. package/dist-types/components/input-range/src/LionInputRange.d.ts.map +1 -1
  24. package/dist-types/tsconfig.tsbuildinfo +1 -1
  25. package/docs/components/checkbox-group/api-table.md +4 -2
  26. package/docs/components/checkbox-group/overview.md +2 -2
  27. package/docs/components/collapsible/overview.md +1 -1
  28. package/docs/components/combobox/overview.md +1 -1
  29. package/docs/components/combobox/use-cases.md +1 -1
  30. package/docs/components/dialog/overview.md +1 -1
  31. package/docs/components/fieldset/overview.md +5 -5
  32. package/docs/components/form/overview.md +3 -3
  33. package/docs/components/form/use-cases.md +2 -2
  34. package/docs/components/icon/use-cases.md +1 -1
  35. package/docs/components/input/api-table.md +2 -1
  36. package/docs/components/input/overview.md +1 -1
  37. package/docs/components/input-amount/api-table.md +2 -1
  38. package/docs/components/input-amount/overview.md +3 -3
  39. package/docs/components/input-amount-dropdown/api-table.md +4 -3
  40. package/docs/components/input-date/api-table.md +2 -1
  41. package/docs/components/input-date/overview.md +3 -3
  42. package/docs/components/input-datepicker/api-table.md +2 -1
  43. package/docs/components/input-datepicker/overview.md +5 -5
  44. package/docs/components/input-email/api-table.md +2 -1
  45. package/docs/components/input-email/overview.md +2 -2
  46. package/docs/components/input-file/api-table.md +2 -1
  47. package/docs/components/input-file/overview.md +1 -1
  48. package/docs/components/input-iban/api-table.md +2 -1
  49. package/docs/components/input-iban/overview.md +2 -2
  50. package/docs/components/input-range/api-table.md +7 -1
  51. package/docs/components/input-range/overview.md +2 -2
  52. package/docs/components/input-range/use-cases.md +14 -0
  53. package/docs/components/input-stepper/api-table.md +2 -1
  54. package/docs/components/input-stepper/overview.md +1 -1
  55. package/docs/components/input-tel/api-table.md +2 -1
  56. package/docs/components/input-tel/overview.md +1 -1
  57. package/docs/components/input-tel/use-cases.md +6 -6
  58. package/docs/components/input-tel-dropdown/api-table.md +2 -1
  59. package/docs/components/input-tel-dropdown/overview.md +1 -1
  60. package/docs/components/listbox/api-table.md +2 -1
  61. package/docs/components/listbox/use-cases.md +1 -1
  62. package/docs/components/radio-group/api-table.md +2 -1
  63. package/docs/components/radio-group/overview.md +3 -3
  64. package/docs/components/select/api-table.md +2 -1
  65. package/docs/components/select/use-cases.md +1 -1
  66. package/docs/components/select-rich/use-cases.md +2 -2
  67. package/docs/components/switch/api-table.md +2 -1
  68. package/docs/components/tabs/examples.md +1 -1
  69. package/docs/components/textarea/api-table.md +2 -1
  70. package/docs/fundamentals/index.md +4 -4
  71. package/docs/fundamentals/node-tools/publish-docs/overview.md +3 -3
  72. package/docs/fundamentals/node-tools/rocket-preset-extend-lion-docs/overview.md +2 -2
  73. package/docs/fundamentals/rationales/accessibility.md +1 -1
  74. package/docs/fundamentals/systems/core/SlotMixin.md +1 -1
  75. package/docs/fundamentals/systems/core/overview.md +1 -1
  76. package/docs/fundamentals/systems/form/api-table.md +2 -1
  77. package/docs/fundamentals/systems/form/formatting-and-parsing.md +4 -4
  78. package/docs/fundamentals/systems/form/model-value.md +1 -1
  79. package/docs/fundamentals/systems/form/overview.md +28 -28
  80. package/docs/fundamentals/systems/form/validate.md +2 -2
  81. package/docs/fundamentals/systems/localize/overview.md +4 -4
  82. package/docs/fundamentals/systems/overlays/configuration.md +2 -2
  83. package/docs/fundamentals/systems/overlays/overview.md +5 -5
  84. package/docs/fundamentals/systems/overlays/use-cases.md +2 -2
  85. package/docs/fundamentals/tools/helpers/overview.md +1 -1
  86. package/docs/fundamentals/tools/singleton-manager/overview.md +4 -4
  87. package/docs/guides/how-to/create-a-custom-field.md +5 -5
  88. package/docs/guides/how-to/create-a-form.md +4 -4
  89. package/docs/guides/how-to/extend-a-native-input.md +2 -2
  90. package/docs/guides/how-to/index.md +1 -1
  91. package/docs/guides/index.md +8 -8
  92. package/docs/guides/principles/index.md +5 -5
  93. package/docs/guides/principles/styling.md +1 -1
  94. package/package.json +1 -1
@@ -2212,36 +2212,6 @@
2212
2212
  }
2213
2213
  ]
2214
2214
  },
2215
- {
2216
- "kind": "javascript-module",
2217
- "path": "exports/define-helpers/sb-action-logger.js",
2218
- "declarations": [],
2219
- "exports": [
2220
- {
2221
- "kind": "custom-element-definition",
2222
- "name": "sb-action-logger",
2223
- "declaration": {
2224
- "name": "SbActionLogger",
2225
- "module": "/exports/helpers.js"
2226
- }
2227
- }
2228
- ]
2229
- },
2230
- {
2231
- "kind": "javascript-module",
2232
- "path": "exports/define-helpers/sb-locale-switcher.js",
2233
- "declarations": [],
2234
- "exports": [
2235
- {
2236
- "kind": "custom-element-definition",
2237
- "name": "sb-locale-switcher",
2238
- "declaration": {
2239
- "name": "SbLocaleSwitcher",
2240
- "module": "/exports/helpers.js"
2241
- }
2242
- }
2243
- ]
2244
- },
2245
2215
  {
2246
2216
  "kind": "javascript-module",
2247
2217
  "path": "exports/define/lion-accordion.js",
@@ -2947,6 +2917,36 @@
2947
2917
  }
2948
2918
  ]
2949
2919
  },
2920
+ {
2921
+ "kind": "javascript-module",
2922
+ "path": "exports/define-helpers/sb-action-logger.js",
2923
+ "declarations": [],
2924
+ "exports": [
2925
+ {
2926
+ "kind": "custom-element-definition",
2927
+ "name": "sb-action-logger",
2928
+ "declaration": {
2929
+ "name": "SbActionLogger",
2930
+ "module": "/exports/helpers.js"
2931
+ }
2932
+ }
2933
+ ]
2934
+ },
2935
+ {
2936
+ "kind": "javascript-module",
2937
+ "path": "exports/define-helpers/sb-locale-switcher.js",
2938
+ "declarations": [],
2939
+ "exports": [
2940
+ {
2941
+ "kind": "custom-element-definition",
2942
+ "name": "sb-locale-switcher",
2943
+ "declaration": {
2944
+ "name": "SbLocaleSwitcher",
2945
+ "module": "/exports/helpers.js"
2946
+ }
2947
+ }
2948
+ ]
2949
+ },
2950
2950
  {
2951
2951
  "kind": "javascript-module",
2952
2952
  "path": "components/accordion/src/LionAccordion.js",
@@ -8322,7 +8322,7 @@
8322
8322
  "text": "object"
8323
8323
  },
8324
8324
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
8325
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
8325
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
8326
8326
  "inheritedFrom": {
8327
8327
  "name": "FormatMixin",
8328
8328
  "module": "components/form-core/src/FormatMixin.js"
@@ -9002,7 +9002,7 @@
9002
9002
  }
9003
9003
  }
9004
9004
  ],
9005
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
9005
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
9006
9006
  "return": {
9007
9007
  "type": {
9008
9008
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -9793,6 +9793,16 @@
9793
9793
  "module": "components/form-core/src/FormControlMixin.js"
9794
9794
  }
9795
9795
  },
9796
+ {
9797
+ "kind": "field",
9798
+ "name": "_isEditingTextField",
9799
+ "readonly": true,
9800
+ "inheritedFrom": {
9801
+ "name": "FormatMixin",
9802
+ "module": "components/form-core/src/FormatMixin.js"
9803
+ },
9804
+ "privacy": "protected"
9805
+ },
9796
9806
  {
9797
9807
  "kind": "method",
9798
9808
  "name": "_isEmpty",
@@ -11777,7 +11787,7 @@
11777
11787
  "text": "object"
11778
11788
  },
11779
11789
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
11780
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
11790
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
11781
11791
  "inheritedFrom": {
11782
11792
  "name": "FormatMixin",
11783
11793
  "module": "components/form-core/src/FormatMixin.js"
@@ -12434,7 +12444,7 @@
12434
12444
  }
12435
12445
  }
12436
12446
  ],
12437
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
12447
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
12438
12448
  "return": {
12439
12449
  "type": {
12440
12450
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -13210,6 +13220,16 @@
13210
13220
  "module": "components/form-core/src/FormControlMixin.js"
13211
13221
  }
13212
13222
  },
13223
+ {
13224
+ "kind": "field",
13225
+ "name": "_isEditingTextField",
13226
+ "readonly": true,
13227
+ "inheritedFrom": {
13228
+ "name": "FormatMixin",
13229
+ "module": "components/form-core/src/FormatMixin.js"
13230
+ },
13231
+ "privacy": "protected"
13232
+ },
13213
13233
  {
13214
13234
  "kind": "method",
13215
13235
  "name": "_isEmpty",
@@ -24298,7 +24318,7 @@
24298
24318
  "text": "object"
24299
24319
  },
24300
24320
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
24301
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
24321
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
24302
24322
  "inheritedFrom": {
24303
24323
  "name": "FormatMixin",
24304
24324
  "module": "components/form-core/src/FormatMixin.js"
@@ -24955,7 +24975,7 @@
24955
24975
  }
24956
24976
  }
24957
24977
  ],
24958
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
24978
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
24959
24979
  "return": {
24960
24980
  "type": {
24961
24981
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -25731,6 +25751,16 @@
25731
25751
  "module": "components/form-core/src/FormControlMixin.js"
25732
25752
  }
25733
25753
  },
25754
+ {
25755
+ "kind": "field",
25756
+ "name": "_isEditingTextField",
25757
+ "readonly": true,
25758
+ "inheritedFrom": {
25759
+ "name": "FormatMixin",
25760
+ "module": "components/form-core/src/FormatMixin.js"
25761
+ },
25762
+ "privacy": "protected"
25763
+ },
25734
25764
  {
25735
25765
  "kind": "method",
25736
25766
  "name": "_isEmpty",
@@ -26982,7 +27012,7 @@
26982
27012
  "text": "object"
26983
27013
  },
26984
27014
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
26985
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
27015
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
26986
27016
  "inheritedFrom": {
26987
27017
  "name": "FormatMixin",
26988
27018
  "module": "components/form-core/src/FormatMixin.js"
@@ -27639,7 +27669,7 @@
27639
27669
  }
27640
27670
  }
27641
27671
  ],
27642
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
27672
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
27643
27673
  "return": {
27644
27674
  "type": {
27645
27675
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -28415,6 +28445,16 @@
28415
28445
  "module": "components/form-core/src/FormControlMixin.js"
28416
28446
  }
28417
28447
  },
28448
+ {
28449
+ "kind": "field",
28450
+ "name": "_isEditingTextField",
28451
+ "readonly": true,
28452
+ "inheritedFrom": {
28453
+ "name": "FormatMixin",
28454
+ "module": "components/form-core/src/FormatMixin.js"
28455
+ },
28456
+ "privacy": "protected"
28457
+ },
28418
28458
  {
28419
28459
  "kind": "method",
28420
28460
  "name": "_isEmpty",
@@ -30272,7 +30312,7 @@
30272
30312
  "text": "object"
30273
30313
  },
30274
30314
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
30275
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
30315
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
30276
30316
  "inheritedFrom": {
30277
30317
  "name": "FormatMixin",
30278
30318
  "module": "components/form-core/src/FormatMixin.js"
@@ -30929,7 +30969,7 @@
30929
30969
  }
30930
30970
  }
30931
30971
  ],
30932
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
30972
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
30933
30973
  "return": {
30934
30974
  "type": {
30935
30975
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -31705,6 +31745,16 @@
31705
31745
  "module": "components/form-core/src/FormControlMixin.js"
31706
31746
  }
31707
31747
  },
31748
+ {
31749
+ "kind": "field",
31750
+ "name": "_isEditingTextField",
31751
+ "readonly": true,
31752
+ "inheritedFrom": {
31753
+ "name": "FormatMixin",
31754
+ "module": "components/form-core/src/FormatMixin.js"
31755
+ },
31756
+ "privacy": "protected"
31757
+ },
31708
31758
  {
31709
31759
  "kind": "method",
31710
31760
  "name": "_isEmpty",
@@ -35718,7 +35768,7 @@
35718
35768
  "text": "object"
35719
35769
  },
35720
35770
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
35721
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
35771
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
35722
35772
  "inheritedFrom": {
35723
35773
  "name": "FormatMixin",
35724
35774
  "module": "components/form-core/src/FormatMixin.js"
@@ -36375,7 +36425,7 @@
36375
36425
  }
36376
36426
  }
36377
36427
  ],
36378
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
36428
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
36379
36429
  "return": {
36380
36430
  "type": {
36381
36431
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -37151,6 +37201,16 @@
37151
37201
  "module": "components/form-core/src/FormControlMixin.js"
37152
37202
  }
37153
37203
  },
37204
+ {
37205
+ "kind": "field",
37206
+ "name": "_isEditingTextField",
37207
+ "readonly": true,
37208
+ "inheritedFrom": {
37209
+ "name": "FormatMixin",
37210
+ "module": "components/form-core/src/FormatMixin.js"
37211
+ },
37212
+ "privacy": "protected"
37213
+ },
37154
37214
  {
37155
37215
  "kind": "method",
37156
37216
  "name": "_isEmpty",
@@ -39258,7 +39318,7 @@
39258
39318
  "text": "object"
39259
39319
  },
39260
39320
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
39261
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators."
39321
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators."
39262
39322
  },
39263
39323
  {
39264
39324
  "kind": "field",
@@ -39273,6 +39333,11 @@
39273
39333
  }
39274
39334
  ]
39275
39335
  },
39336
+ {
39337
+ "kind": "field",
39338
+ "name": "_isEditingTextField",
39339
+ "readonly": true
39340
+ },
39276
39341
  {
39277
39342
  "kind": "method",
39278
39343
  "name": "preprocessor",
@@ -39292,7 +39357,7 @@
39292
39357
  }
39293
39358
  }
39294
39359
  ],
39295
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
39360
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
39296
39361
  "return": {
39297
39362
  "type": {
39298
39363
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -44123,7 +44188,7 @@
44123
44188
  "text": "object"
44124
44189
  },
44125
44190
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
44126
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
44191
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
44127
44192
  "inheritedFrom": {
44128
44193
  "name": "FormatMixin",
44129
44194
  "module": "components/form-core/src/FormatMixin.js"
@@ -44717,7 +44782,7 @@
44717
44782
  }
44718
44783
  }
44719
44784
  ],
44720
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
44785
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
44721
44786
  "return": {
44722
44787
  "type": {
44723
44788
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -45429,6 +45494,16 @@
45429
45494
  "module": "components/form-core/src/FormControlMixin.js"
45430
45495
  }
45431
45496
  },
45497
+ {
45498
+ "kind": "field",
45499
+ "name": "_isEditingTextField",
45500
+ "readonly": true,
45501
+ "inheritedFrom": {
45502
+ "name": "FormatMixin",
45503
+ "module": "components/form-core/src/FormatMixin.js"
45504
+ },
45505
+ "privacy": "protected"
45506
+ },
45432
45507
  {
45433
45508
  "kind": "method",
45434
45509
  "name": "_isEmpty",
@@ -47376,7 +47451,16 @@
47376
47451
  "text": "object"
47377
47452
  },
47378
47453
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
47379
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
47454
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
47455
+ "inheritedFrom": {
47456
+ "name": "FormatMixin",
47457
+ "module": "components/form-core/src/FormatMixin.js"
47458
+ }
47459
+ },
47460
+ {
47461
+ "kind": "field",
47462
+ "name": "_isEditingTextField",
47463
+ "readonly": true,
47380
47464
  "inheritedFrom": {
47381
47465
  "name": "FormatMixin",
47382
47466
  "module": "components/form-core/src/FormatMixin.js"
@@ -47401,7 +47485,7 @@
47401
47485
  }
47402
47486
  }
47403
47487
  ],
47404
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
47488
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
47405
47489
  "return": {
47406
47490
  "type": {
47407
47491
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -61432,7 +61516,7 @@
61432
61516
  "text": "object"
61433
61517
  },
61434
61518
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
61435
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
61519
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
61436
61520
  "inheritedFrom": {
61437
61521
  "name": "FormatMixin",
61438
61522
  "module": "components/form-core/src/FormatMixin.js"
@@ -61455,6 +61539,15 @@
61455
61539
  "module": "components/form-core/src/FormatMixin.js"
61456
61540
  }
61457
61541
  },
61542
+ {
61543
+ "kind": "field",
61544
+ "name": "_isEditingTextField",
61545
+ "readonly": true,
61546
+ "inheritedFrom": {
61547
+ "name": "FormatMixin",
61548
+ "module": "components/form-core/src/FormatMixin.js"
61549
+ }
61550
+ },
61458
61551
  {
61459
61552
  "kind": "method",
61460
61553
  "name": "preprocessor",
@@ -61474,7 +61567,7 @@
61474
61567
  }
61475
61568
  }
61476
61569
  ],
61477
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
61570
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
61478
61571
  "return": {
61479
61572
  "type": {
61480
61573
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -69860,7 +69953,7 @@
69860
69953
  "text": "object"
69861
69954
  },
69862
69955
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
69863
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
69956
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
69864
69957
  "inheritedFrom": {
69865
69958
  "name": "LionField",
69866
69959
  "module": "components/form-core/src/LionField.js"
@@ -70487,7 +70580,8 @@
70487
70580
  "attribute": "modelValue",
70488
70581
  "type": {
70489
70582
  "text": "object"
70490
- }
70583
+ },
70584
+ "description": "For a FormControl to function properly, its modelValue, serializedValue and viewValue/formattedValue\nshould always translate in two directions. This is expected by `_callParser` method. It guards for empty\nviewValues. As the viewValue (`.value`) only concerns the amount part and not the currency part in\nInputAmountDropdown, this contract is broken.\nBelow, we compensate for this."
70491
70585
  },
70492
70586
  {
70493
70587
  "kind": "field",
@@ -70617,7 +70711,7 @@
70617
70711
  }
70618
70712
  }
70619
70713
  ],
70620
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
70714
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
70621
70715
  "return": {
70622
70716
  "type": {
70623
70717
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -71501,6 +71595,16 @@
71501
71595
  "text": "HTMLInputElement | HTMLTextAreaElement"
71502
71596
  }
71503
71597
  },
71598
+ {
71599
+ "kind": "field",
71600
+ "name": "_isEditingTextField",
71601
+ "readonly": true,
71602
+ "inheritedFrom": {
71603
+ "name": "LionField",
71604
+ "module": "components/form-core/src/LionField.js"
71605
+ },
71606
+ "privacy": "protected"
71607
+ },
71504
71608
  {
71505
71609
  "kind": "method",
71506
71610
  "name": "_isEmpty",
@@ -72397,6 +72501,16 @@
72397
72501
  "module": "components/form-core/src/LionField.js"
72398
72502
  }
72399
72503
  },
72504
+ {
72505
+ "kind": "field",
72506
+ "name": "__modelValue",
72507
+ "description": "The internal modelValue is a combination of the amount and the currency code. The amount is a number, the currency code is a string.",
72508
+ "privacy": "private",
72509
+ "type": {
72510
+ "text": "AmountDropdownModelValue"
72511
+ },
72512
+ "default": "{ currency: this.currency, amount: '' }"
72513
+ },
72400
72514
  {
72401
72515
  "kind": "method",
72402
72516
  "name": "__onBlur",
@@ -72819,17 +72933,6 @@
72819
72933
  }
72820
72934
  ],
72821
72935
  "attributes": [
72822
- {
72823
- "name": "modelValue",
72824
- "fieldName": "modelValue",
72825
- "type": {
72826
- "text": "object"
72827
- },
72828
- "inheritedFrom": {
72829
- "name": "LionInputAmount",
72830
- "module": "components/input-amount/src/LionInputAmount.js"
72831
- }
72832
- },
72833
72936
  {
72834
72937
  "name": "preferredCurrencies",
72835
72938
  "type": {
@@ -72869,6 +72972,14 @@
72869
72972
  "module": "components/input-amount/src/LionInputAmount.js"
72870
72973
  }
72871
72974
  },
72975
+ {
72976
+ "name": "modelValue",
72977
+ "fieldName": "modelValue",
72978
+ "inheritedFrom": {
72979
+ "name": "LionInputAmount",
72980
+ "module": "components/input-amount/src/LionInputAmount.js"
72981
+ }
72982
+ },
72872
72983
  {
72873
72984
  "name": "autocomplete",
72874
72985
  "type": {
@@ -73351,7 +73462,7 @@
73351
73462
  "text": "object"
73352
73463
  },
73353
73464
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
73354
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
73465
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
73355
73466
  "inheritedFrom": {
73356
73467
  "name": "LionField",
73357
73468
  "module": "components/form-core/src/LionField.js"
@@ -74073,7 +74184,7 @@
74073
74184
  }
74074
74185
  }
74075
74186
  ],
74076
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
74187
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
74077
74188
  "return": {
74078
74189
  "type": {
74079
74190
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -74892,6 +75003,16 @@
74892
75003
  "text": "HTMLInputElement | HTMLTextAreaElement"
74893
75004
  }
74894
75005
  },
75006
+ {
75007
+ "kind": "field",
75008
+ "name": "_isEditingTextField",
75009
+ "readonly": true,
75010
+ "inheritedFrom": {
75011
+ "name": "LionField",
75012
+ "module": "components/form-core/src/LionField.js"
75013
+ },
75014
+ "privacy": "protected"
75015
+ },
74895
75016
  {
74896
75017
  "kind": "method",
74897
75018
  "name": "_isEmpty",
@@ -76734,7 +76855,7 @@
76734
76855
  "text": "object"
76735
76856
  },
76736
76857
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
76737
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
76858
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
76738
76859
  "inheritedFrom": {
76739
76860
  "name": "LionField",
76740
76861
  "module": "components/form-core/src/LionField.js"
@@ -77428,7 +77549,7 @@
77428
77549
  }
77429
77550
  }
77430
77551
  ],
77431
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
77552
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
77432
77553
  "return": {
77433
77554
  "type": {
77434
77555
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -78235,6 +78356,16 @@
78235
78356
  "text": "HTMLInputElement | HTMLTextAreaElement"
78236
78357
  }
78237
78358
  },
78359
+ {
78360
+ "kind": "field",
78361
+ "name": "_isEditingTextField",
78362
+ "readonly": true,
78363
+ "inheritedFrom": {
78364
+ "name": "LionField",
78365
+ "module": "components/form-core/src/LionField.js"
78366
+ },
78367
+ "privacy": "protected"
78368
+ },
78238
78369
  {
78239
78370
  "kind": "method",
78240
78371
  "name": "_isEmpty",
@@ -80021,7 +80152,7 @@
80021
80152
  "text": "object"
80022
80153
  },
80023
80154
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
80024
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
80155
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
80025
80156
  "inheritedFrom": {
80026
80157
  "name": "LionField",
80027
80158
  "module": "components/form-core/src/LionField.js"
@@ -80740,7 +80871,7 @@
80740
80871
  }
80741
80872
  }
80742
80873
  ],
80743
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
80874
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
80744
80875
  "return": {
80745
80876
  "type": {
80746
80877
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -81673,6 +81804,16 @@
81673
81804
  "description": "Subclassers can replace this with their custom extension invoker,\nlike `<my-button><calendar-icon></calendar-icon></my-button>`",
81674
81805
  "privacy": "protected"
81675
81806
  },
81807
+ {
81808
+ "kind": "field",
81809
+ "name": "_isEditingTextField",
81810
+ "readonly": true,
81811
+ "inheritedFrom": {
81812
+ "name": "LionField",
81813
+ "module": "components/form-core/src/LionField.js"
81814
+ },
81815
+ "privacy": "protected"
81816
+ },
81676
81817
  {
81677
81818
  "kind": "method",
81678
81819
  "name": "_isEmpty",
@@ -83530,7 +83671,7 @@
83530
83671
  "text": "object"
83531
83672
  },
83532
83673
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
83533
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
83674
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
83534
83675
  "inheritedFrom": {
83535
83676
  "name": "LionField",
83536
83677
  "module": "components/form-core/src/LionField.js"
@@ -84230,7 +84371,7 @@
84230
84371
  }
84231
84372
  }
84232
84373
  ],
84233
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
84374
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
84234
84375
  "return": {
84235
84376
  "type": {
84236
84377
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -85038,6 +85179,16 @@
85038
85179
  "text": "HTMLInputElement | HTMLTextAreaElement"
85039
85180
  }
85040
85181
  },
85182
+ {
85183
+ "kind": "field",
85184
+ "name": "_isEditingTextField",
85185
+ "readonly": true,
85186
+ "inheritedFrom": {
85187
+ "name": "LionField",
85188
+ "module": "components/form-core/src/LionField.js"
85189
+ },
85190
+ "privacy": "protected"
85191
+ },
85041
85192
  {
85042
85193
  "kind": "method",
85043
85194
  "name": "_isEmpty",
@@ -86695,7 +86846,7 @@
86695
86846
  "text": "object"
86696
86847
  },
86697
86848
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
86698
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
86849
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
86699
86850
  "inheritedFrom": {
86700
86851
  "name": "LionField",
86701
86852
  "module": "components/form-core/src/LionField.js"
@@ -87432,7 +87583,7 @@
87432
87583
  }
87433
87584
  }
87434
87585
  ],
87435
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
87586
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
87436
87587
  "return": {
87437
87588
  "type": {
87438
87589
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -88306,6 +88457,16 @@
88306
88457
  "privacy": "protected",
88307
88458
  "readonly": true
88308
88459
  },
88460
+ {
88461
+ "kind": "field",
88462
+ "name": "_isEditingTextField",
88463
+ "readonly": true,
88464
+ "inheritedFrom": {
88465
+ "name": "LionField",
88466
+ "module": "components/form-core/src/LionField.js"
88467
+ },
88468
+ "privacy": "protected"
88469
+ },
88309
88470
  {
88310
88471
  "kind": "method",
88311
88472
  "name": "_isEmpty",
@@ -91413,7 +91574,7 @@
91413
91574
  "text": "object"
91414
91575
  },
91415
91576
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
91416
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
91577
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
91417
91578
  "inheritedFrom": {
91418
91579
  "name": "LionField",
91419
91580
  "module": "components/form-core/src/LionField.js"
@@ -92115,7 +92276,7 @@
92115
92276
  }
92116
92277
  }
92117
92278
  ],
92118
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
92279
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
92119
92280
  "return": {
92120
92281
  "type": {
92121
92282
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -92923,6 +93084,16 @@
92923
93084
  "text": "HTMLInputElement | HTMLTextAreaElement"
92924
93085
  }
92925
93086
  },
93087
+ {
93088
+ "kind": "field",
93089
+ "name": "_isEditingTextField",
93090
+ "readonly": true,
93091
+ "inheritedFrom": {
93092
+ "name": "LionField",
93093
+ "module": "components/form-core/src/LionField.js"
93094
+ },
93095
+ "privacy": "protected"
93096
+ },
92926
93097
  {
92927
93098
  "kind": "method",
92928
93099
  "name": "_isEmpty",
@@ -95590,7 +95761,7 @@
95590
95761
  "text": "object"
95591
95762
  },
95592
95763
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
95593
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
95764
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
95594
95765
  "inheritedFrom": {
95595
95766
  "name": "LionField",
95596
95767
  "module": "components/form-core/src/LionField.js"
@@ -96176,6 +96347,16 @@
96176
96347
  "attribute": "max",
96177
96348
  "reflects": true
96178
96349
  },
96350
+ {
96351
+ "kind": "field",
96352
+ "name": "maxLabel",
96353
+ "privacy": "public",
96354
+ "type": {
96355
+ "text": "string"
96356
+ },
96357
+ "default": "''",
96358
+ "attribute": "max-label"
96359
+ },
96179
96360
  {
96180
96361
  "kind": "field",
96181
96362
  "name": "min",
@@ -96187,6 +96368,16 @@
96187
96368
  "attribute": "min",
96188
96369
  "reflects": true
96189
96370
  },
96371
+ {
96372
+ "kind": "field",
96373
+ "name": "minLabel",
96374
+ "privacy": "public",
96375
+ "type": {
96376
+ "text": "string"
96377
+ },
96378
+ "default": "''",
96379
+ "attribute": "min-label"
96380
+ },
96190
96381
  {
96191
96382
  "kind": "field",
96192
96383
  "name": "modelValue",
@@ -96315,7 +96506,7 @@
96315
96506
  }
96316
96507
  }
96317
96508
  ],
96318
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
96509
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
96319
96510
  "return": {
96320
96511
  "type": {
96321
96512
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -97168,6 +97359,16 @@
97168
97359
  "text": "HTMLInputElement | HTMLTextAreaElement"
97169
97360
  }
97170
97361
  },
97362
+ {
97363
+ "kind": "field",
97364
+ "name": "_isEditingTextField",
97365
+ "readonly": true,
97366
+ "inheritedFrom": {
97367
+ "name": "LionField",
97368
+ "module": "components/form-core/src/LionField.js"
97369
+ },
97370
+ "privacy": "protected"
97371
+ },
97171
97372
  {
97172
97373
  "kind": "method",
97173
97374
  "name": "_isEmpty",
@@ -97649,6 +97850,18 @@
97649
97850
  "module": "components/form-core/src/LionField.js"
97650
97851
  }
97651
97852
  },
97853
+ {
97854
+ "kind": "field",
97855
+ "name": "_valueDisplay",
97856
+ "description": "Get the display info for the current value",
97857
+ "privacy": "protected",
97858
+ "return": {
97859
+ "type": {
97860
+ "text": "{ text: string, showUnit: boolean }"
97861
+ }
97862
+ },
97863
+ "readonly": true
97864
+ },
97652
97865
  {
97653
97866
  "kind": "field",
97654
97867
  "name": "_visibleMessagesAmount",
@@ -98367,6 +98580,22 @@
98367
98580
  "default": "false",
98368
98581
  "fieldName": "noMinMaxLabels"
98369
98582
  },
98583
+ {
98584
+ "name": "min-label",
98585
+ "type": {
98586
+ "text": "string"
98587
+ },
98588
+ "default": "''",
98589
+ "fieldName": "minLabel"
98590
+ },
98591
+ {
98592
+ "name": "max-label",
98593
+ "type": {
98594
+ "text": "string"
98595
+ },
98596
+ "default": "''",
98597
+ "fieldName": "maxLabel"
98598
+ },
98370
98599
  {
98371
98600
  "name": "autocomplete",
98372
98601
  "type": {
@@ -98907,7 +99136,7 @@
98907
99136
  "text": "object"
98908
99137
  },
98909
99138
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
98910
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
99139
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
98911
99140
  "inheritedFrom": {
98912
99141
  "name": "LionField",
98913
99142
  "module": "components/form-core/src/LionField.js"
@@ -99635,7 +99864,7 @@
99635
99864
  }
99636
99865
  }
99637
99866
  ],
99638
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
99867
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
99639
99868
  "return": {
99640
99869
  "type": {
99641
99870
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -100555,6 +100784,16 @@
100555
100784
  "text": "HTMLInputElement | HTMLTextAreaElement"
100556
100785
  }
100557
100786
  },
100787
+ {
100788
+ "kind": "field",
100789
+ "name": "_isEditingTextField",
100790
+ "readonly": true,
100791
+ "inheritedFrom": {
100792
+ "name": "LionField",
100793
+ "module": "components/form-core/src/LionField.js"
100794
+ },
100795
+ "privacy": "protected"
100796
+ },
100558
100797
  {
100559
100798
  "kind": "method",
100560
100799
  "name": "_isEmpty",
@@ -102403,7 +102642,7 @@
102403
102642
  "text": "object"
102404
102643
  },
102405
102644
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
102406
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
102645
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
102407
102646
  "inheritedFrom": {
102408
102647
  "name": "LionField",
102409
102648
  "module": "components/form-core/src/LionField.js"
@@ -103178,7 +103417,7 @@
103178
103417
  }
103179
103418
  }
103180
103419
  ],
103181
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
103420
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
103182
103421
  "return": {
103183
103422
  "type": {
103184
103423
  "text": "{ viewValue: string; caretIndex: number; } | undefined"
@@ -104034,6 +104273,16 @@
104034
104273
  "text": "HTMLInputElement | HTMLTextAreaElement"
104035
104274
  }
104036
104275
  },
104276
+ {
104277
+ "kind": "field",
104278
+ "name": "_isEditingTextField",
104279
+ "readonly": true,
104280
+ "inheritedFrom": {
104281
+ "name": "LionField",
104282
+ "module": "components/form-core/src/LionField.js"
104283
+ },
104284
+ "privacy": "protected"
104285
+ },
104037
104286
  {
104038
104287
  "kind": "method",
104039
104288
  "name": "_isEmpty",
@@ -106028,7 +106277,7 @@
106028
106277
  "text": "object"
106029
106278
  },
106030
106279
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
106031
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
106280
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
106032
106281
  "inheritedFrom": {
106033
106282
  "name": "LionField",
106034
106283
  "module": "components/form-core/src/LionField.js"
@@ -106779,7 +107028,7 @@
106779
107028
  }
106780
107029
  }
106781
107030
  ],
106782
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
107031
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
106783
107032
  "return": {
106784
107033
  "type": {
106785
107034
  "text": "{ viewValue: string; caretIndex: number; } | undefined"
@@ -107597,6 +107846,16 @@
107597
107846
  "text": "HTMLInputElement | HTMLTextAreaElement"
107598
107847
  }
107599
107848
  },
107849
+ {
107850
+ "kind": "field",
107851
+ "name": "_isEditingTextField",
107852
+ "readonly": true,
107853
+ "inheritedFrom": {
107854
+ "name": "LionField",
107855
+ "module": "components/form-core/src/LionField.js"
107856
+ },
107857
+ "privacy": "protected"
107858
+ },
107600
107859
  {
107601
107860
  "kind": "method",
107602
107861
  "name": "_isEmpty",
@@ -109780,7 +110039,7 @@
109780
110039
  "text": "object"
109781
110040
  },
109782
110041
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
109783
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
110042
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
109784
110043
  "inheritedFrom": {
109785
110044
  "name": "LionField",
109786
110045
  "module": "components/form-core/src/LionField.js"
@@ -110476,7 +110735,7 @@
110476
110735
  }
110477
110736
  }
110478
110737
  ],
110479
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
110738
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
110480
110739
  "return": {
110481
110740
  "type": {
110482
110741
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -111280,6 +111539,16 @@
111280
111539
  "text": "HTMLInputElement | HTMLTextAreaElement"
111281
111540
  }
111282
111541
  },
111542
+ {
111543
+ "kind": "field",
111544
+ "name": "_isEditingTextField",
111545
+ "readonly": true,
111546
+ "inheritedFrom": {
111547
+ "name": "LionField",
111548
+ "module": "components/form-core/src/LionField.js"
111549
+ },
111550
+ "privacy": "protected"
111551
+ },
111283
111552
  {
111284
111553
  "kind": "method",
111285
111554
  "name": "_isEmpty",
@@ -119385,7 +119654,7 @@
119385
119654
  "text": "object"
119386
119655
  },
119387
119656
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
119388
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
119657
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
119389
119658
  "inheritedFrom": {
119390
119659
  "name": "FormatMixin",
119391
119660
  "module": "components/form-core/src/FormatMixin.js"
@@ -119663,7 +119932,7 @@
119663
119932
  }
119664
119933
  }
119665
119934
  ],
119666
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
119935
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
119667
119936
  "return": {
119668
119937
  "type": {
119669
119938
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -119862,6 +120131,16 @@
119862
120131
  "module": "components/form-core/src/FormatMixin.js"
119863
120132
  }
119864
120133
  },
120134
+ {
120135
+ "kind": "field",
120136
+ "name": "_isEditingTextField",
120137
+ "readonly": true,
120138
+ "inheritedFrom": {
120139
+ "name": "FormatMixin",
120140
+ "module": "components/form-core/src/FormatMixin.js"
120141
+ },
120142
+ "privacy": "protected"
120143
+ },
119865
120144
  {
119866
120145
  "kind": "method",
119867
120146
  "name": "_isEmpty",
@@ -127837,7 +128116,7 @@
127837
128116
  "text": "object"
127838
128117
  },
127839
128118
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
127840
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
128119
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
127841
128120
  "inheritedFrom": {
127842
128121
  "name": "LionField",
127843
128122
  "module": "components/form-core/src/LionField.js"
@@ -128565,7 +128844,7 @@
128565
128844
  }
128566
128845
  }
128567
128846
  ],
128568
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
128847
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
128569
128848
  "return": {
128570
128849
  "type": {
128571
128850
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -129390,6 +129669,16 @@
129390
129669
  "text": "HTMLInputElement | HTMLTextAreaElement"
129391
129670
  }
129392
129671
  },
129672
+ {
129673
+ "kind": "field",
129674
+ "name": "_isEditingTextField",
129675
+ "readonly": true,
129676
+ "inheritedFrom": {
129677
+ "name": "LionField",
129678
+ "module": "components/form-core/src/LionField.js"
129679
+ },
129680
+ "privacy": "protected"
129681
+ },
129393
129682
  {
129394
129683
  "kind": "method",
129395
129684
  "name": "_isEmpty",
@@ -135111,7 +135400,7 @@
135111
135400
  "text": "object"
135112
135401
  },
135113
135402
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
135114
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
135403
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
135115
135404
  "inheritedFrom": {
135116
135405
  "name": "LionField",
135117
135406
  "module": "components/form-core/src/LionField.js"
@@ -135789,7 +136078,7 @@
135789
136078
  }
135790
136079
  }
135791
136080
  ],
135792
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
136081
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
135793
136082
  "return": {
135794
136083
  "type": {
135795
136084
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -136559,6 +136848,16 @@
136559
136848
  }
136560
136849
  }
136561
136850
  },
136851
+ {
136852
+ "kind": "field",
136853
+ "name": "_isEditingTextField",
136854
+ "readonly": true,
136855
+ "inheritedFrom": {
136856
+ "name": "LionField",
136857
+ "module": "components/form-core/src/LionField.js"
136858
+ },
136859
+ "privacy": "protected"
136860
+ },
136562
136861
  {
136563
136862
  "kind": "method",
136564
136863
  "name": "_isEmpty",
@@ -138526,7 +138825,7 @@
138526
138825
  "text": "object"
138527
138826
  },
138528
138827
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
138529
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
138828
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
138530
138829
  "inheritedFrom": {
138531
138830
  "name": "LionField",
138532
138831
  "module": "components/form-core/src/LionField.js"
@@ -139224,7 +139523,7 @@
139224
139523
  }
139225
139524
  }
139226
139525
  ],
139227
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
139526
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
139228
139527
  "return": {
139229
139528
  "type": {
139230
139529
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -140010,6 +140309,16 @@
140010
140309
  "text": "LionSwitchButton"
140011
140310
  }
140012
140311
  },
140312
+ {
140313
+ "kind": "field",
140314
+ "name": "_isEditingTextField",
140315
+ "readonly": true,
140316
+ "inheritedFrom": {
140317
+ "name": "LionField",
140318
+ "module": "components/form-core/src/LionField.js"
140319
+ },
140320
+ "privacy": "protected"
140321
+ },
140013
140322
  {
140014
140323
  "kind": "method",
140015
140324
  "name": "_isEmpty",
@@ -142354,7 +142663,7 @@
142354
142663
  "text": "object"
142355
142664
  },
142356
142665
  "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
142357
- "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
142666
+ "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
142358
142667
  "inheritedFrom": {
142359
142668
  "name": "LionField",
142360
142669
  "module": "components/form-core/src/LionField.js"
@@ -143060,7 +143369,7 @@
143060
143369
  }
143061
143370
  }
143062
143371
  ],
143063
- "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
143372
+ "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
143064
143373
  "return": {
143065
143374
  "type": {
143066
143375
  "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -143891,6 +144200,16 @@
143891
144200
  "text": "HTMLInputElement | HTMLTextAreaElement"
143892
144201
  }
143893
144202
  },
144203
+ {
144204
+ "kind": "field",
144205
+ "name": "_isEditingTextField",
144206
+ "readonly": true,
144207
+ "inheritedFrom": {
144208
+ "name": "LionField",
144209
+ "module": "components/form-core/src/LionField.js"
144210
+ },
144211
+ "privacy": "protected"
144212
+ },
143894
144213
  {
143895
144214
  "kind": "method",
143896
144215
  "name": "_isEmpty",