@lion/ui 0.8.5 → 0.8.6

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 (68) hide show
  1. package/components/core/src/ScopedElementsMixin.js +2 -2
  2. package/components/core/test/ScopedElementsMixin.test.js +34 -1
  3. package/components/core/test/SlotMixin.test.js +13 -28
  4. package/components/form-core/test-suites/ValidateMixin.suite.js +7 -7
  5. package/components/overlays/src/OverlayController.js +25 -1
  6. package/components/overlays/src/OverlayMixin.js +17 -4
  7. package/components/overlays/src/utils/adopt-styles.js +3 -3
  8. package/components/overlays/test/OverlayController.test.js +33 -2
  9. package/custom-elements.json +106 -0
  10. package/dist-types/components/core/test/SlotMixin.test.d.ts.map +1 -1
  11. package/dist-types/components/overlays/src/OverlayController.d.ts +2 -0
  12. package/dist-types/components/overlays/src/OverlayController.d.ts.map +1 -1
  13. package/dist-types/components/overlays/src/OverlayMixin.d.ts.map +1 -1
  14. package/dist-types/tsconfig.tsbuildinfo +1 -1
  15. package/docs/components/checkbox-group/overview.md +2 -2
  16. package/docs/components/collapsible/overview.md +1 -1
  17. package/docs/components/combobox/overview.md +1 -1
  18. package/docs/components/combobox/use-cases.md +1 -1
  19. package/docs/components/dialog/overview.md +1 -1
  20. package/docs/components/fieldset/overview.md +5 -5
  21. package/docs/components/form/overview.md +3 -3
  22. package/docs/components/icon/use-cases.md +1 -1
  23. package/docs/components/input/overview.md +1 -1
  24. package/docs/components/input-amount/overview.md +3 -3
  25. package/docs/components/input-date/overview.md +3 -3
  26. package/docs/components/input-datepicker/overview.md +5 -5
  27. package/docs/components/input-email/overview.md +2 -2
  28. package/docs/components/input-file/overview.md +1 -1
  29. package/docs/components/input-iban/overview.md +2 -2
  30. package/docs/components/input-range/overview.md +2 -2
  31. package/docs/components/input-stepper/overview.md +1 -1
  32. package/docs/components/input-tel/overview.md +1 -1
  33. package/docs/components/input-tel/use-cases.md +6 -6
  34. package/docs/components/input-tel-dropdown/overview.md +1 -1
  35. package/docs/components/listbox/use-cases.md +1 -1
  36. package/docs/components/radio-group/overview.md +3 -3
  37. package/docs/components/select/use-cases.md +1 -1
  38. package/docs/components/select-rich/use-cases.md +1 -1
  39. package/docs/components/tabs/examples.md +1 -1
  40. package/docs/fundamentals/index.md +4 -4
  41. package/docs/fundamentals/node-tools/providence-analytics/overview.md +42 -139
  42. package/docs/fundamentals/node-tools/publish-docs/overview.md +3 -3
  43. package/docs/fundamentals/node-tools/rocket-preset-extend-lion-docs/overview.md +2 -2
  44. package/docs/fundamentals/rationales/accessibility.md +1 -1
  45. package/docs/fundamentals/systems/core/SlotMixin.md +1 -1
  46. package/docs/fundamentals/systems/core/overview.md +1 -1
  47. package/docs/fundamentals/systems/form/formatting-and-parsing.md +4 -4
  48. package/docs/fundamentals/systems/form/model-value.md +1 -1
  49. package/docs/fundamentals/systems/form/overview.md +28 -28
  50. package/docs/fundamentals/systems/form/validate.md +2 -2
  51. package/docs/fundamentals/systems/localize/overview.md +4 -4
  52. package/docs/fundamentals/systems/overlays/configuration.md +2 -2
  53. package/docs/fundamentals/systems/overlays/overview.md +5 -5
  54. package/docs/fundamentals/systems/overlays/use-cases.md +2 -2
  55. package/docs/fundamentals/tools/helpers/overview.md +1 -1
  56. package/docs/fundamentals/tools/singleton-manager/overview.md +4 -4
  57. package/docs/guides/how-to/create-a-custom-field.md +5 -5
  58. package/docs/guides/how-to/create-a-form.md +4 -4
  59. package/docs/guides/how-to/extend-a-native-input.md +2 -2
  60. package/docs/guides/index.md +8 -8
  61. package/docs/guides/principles/index.md +5 -5
  62. package/docs/guides/principles/styling.md +1 -1
  63. package/package.json +1 -1
  64. package/docs/fundamentals/node-tools/providence-analytics/LocalConfiguration.md +0 -68
  65. package/docs/fundamentals/node-tools/providence-analytics/QueryResult.md +0 -111
  66. package/docs/fundamentals/node-tools/providence-analytics/analyzer.md +0 -69
  67. package/docs/fundamentals/node-tools/providence-analytics/assets/_mermaid.svg.js +0 -1226
  68. package/docs/fundamentals/node-tools/providence-analytics/dashboard.md +0 -22
@@ -1,68 +0,0 @@
1
- # Node Tools >> Providence Analytics >> Local configuration ||40
2
-
3
- The Providence configuration file is read by providence cli (optional) and by the dashboard (required).
4
- It has a few requirements:
5
-
6
- - it must be called `providence.conf.js` or `providence.conf.mjs`
7
- - it must be in ESM format
8
- - it must be located in the root of a repository (under `process.cwd()`)
9
-
10
- ## Meta data
11
-
12
- ### Category info
13
-
14
- Based on the filePath of a result, a category can be added.
15
- For example:
16
-
17
- ```js
18
- export default {
19
- metaConfig: {
20
- categoryConfig: [
21
- {
22
- // This is the name found in package.json
23
- project: '@lion/ui/root.js',
24
- // These conditions will be run on overy filePath
25
- categories: {
26
- core: p => p.startsWith('./packages/core'),
27
- utils: p => p.startsWith('./packages/ajax') || p.startsWith('./packages/localize'),
28
- overlays: p =>
29
- p.startsWith('./packages/overlays') ||
30
- p.startsWith('./packages/dialog') ||
31
- p.startsWith('./packages/tooltip'),
32
- ...
33
- },
34
- },
35
- ],
36
- },
37
- }
38
- ```
39
-
40
- > N.B. category info is regarded as subjective, therefore it's advised to move this away from
41
- > Analyzers (and thus file-system cache). Categories can be added realtime in the dashboard.
42
-
43
- ## Project paths
44
-
45
- ### referenceCollections
46
-
47
- A list of file system paths. They can be defined relative from the current project root or they can be full paths.
48
- When a [MatchAnalyzer](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/fundamentals/node-tools/providence-analytics/analyzer.md) like `match-imports` or `match-subclasses` is used, the default reference(s) can be configured here. For instance: ['/path/to/@lion/ui/form.js']
49
-
50
- An example:
51
-
52
- ```js
53
- referenceCollections: {
54
- // Our products
55
- 'lion-based-ui': [
56
- './providence-input-data/references/lion-based-ui',
57
- './providence-input-data/references/lion-based-ui-labs',
58
- ],
59
- ...
60
- }
61
- ```
62
-
63
- ### searchTargetCollections
64
-
65
- A list of file system paths. They can be defined relative from the current project root
66
- or they can be full paths.
67
- When not defined, the current project will be the search target (this is most common when
68
- providence is used as a dev dependency).
@@ -1,111 +0,0 @@
1
- # Node Tools >> Providence Analytics >> QueryResult ||50
2
-
3
- When an Analyzer has run, it returns a QueryResult. This is a json object that contains all
4
- meta info (mainly configuration parameters) and the query output.
5
- A QueryResult always contains the analysis of one project (a target project). Optionally,
6
- it can contain a reference project as well.
7
-
8
- ## Anatomy
9
-
10
- A QueryResult starts with a meta section, followed by the actual results
11
-
12
- ### Meta
13
-
14
- The meta section lists all configuration options the analyzer was run with. Here, you see an
15
- example of a `find-imports` QueryResult:
16
-
17
- ```js
18
- "meta": {
19
- "searchType": "ast-analyzer",
20
- "analyzerMeta": {
21
- "name": "find-imports",
22
- "requiredAst": "babel",
23
- "identifier": "importing-target-project_0.0.2-target-mock__1970011674",
24
- "targetProject": {
25
- "name": "importing-target-project",
26
- "commitHash": "3e5014d6ecdff1fc71138cdb29aaf7bf367588f5",
27
- "version": "0.0.2-target-mock"
28
- },
29
- "configuration": {
30
- "keepInternalSources": false
31
- }
32
- }
33
- },
34
- ```
35
-
36
- ### Output
37
-
38
- The output is usually more specifically tied to the Analyzer. What most regular Analyzers
39
- (not being MatchAnalyzers that require a referenceProjectPath) have in common, is that their
40
- results are being shown per "entry" (an entry corresponds with an AST generated by Babel, which in
41
- turn corresponds to a file found in a target or reference project).
42
-
43
- Below an example is shown of `find-imports` QueryOutput:
44
-
45
- ```js
46
- "queryOutput": [
47
- {
48
- "project": {
49
- "name": "importing-target-project",
50
- "mainEntry": "./target-src/match-imports/root-level-imports.js",
51
- "version": "0.0.2-target-mock",
52
- "commitHash": "3e5014d6ecdff1fc71138cdb29aaf7bf367588f5"
53
- },
54
- "entries": [
55
- {
56
- "file": "./target-src/find-imports/all-notations.js",
57
- "result": [
58
- {
59
- "importSpecifiers": [
60
- "[file]"
61
- ],
62
- "source": "imported/source",
63
- "normalizedSource": "imported/source",
64
- "fullSource": "imported/source"
65
- },
66
- {
67
- "importSpecifiers": [
68
- "[default]"
69
- ],
70
- "source": "imported/source-a",
71
- "normalizedSource": "imported/source-a",
72
- "fullSource": "imported/source-a"
73
- },
74
- ...
75
- ```
76
-
77
- MatchAnalyzers usually do post processing on the entries. The output below (for the `match-imports`
78
- Analyzer) shows an ordering by matched specifier.
79
-
80
- ```js
81
- "queryOutput": [
82
- {
83
- "exportSpecifier": {
84
- "name": "[default]",
85
- "project": "exporting-ref-project",
86
- "filePath": "./index.js",
87
- "id": "[default]::./index.js::exporting-ref-project"
88
- },
89
- "matchesPerProject": [
90
- {
91
- "project": "importing-target-project",
92
- "files": [
93
- "./target-src/match-imports/root-level-imports.js",
94
- "./target-src/match-subclasses/internalProxy.js"
95
- ]
96
- }
97
- ]
98
- },
99
- ...
100
- ```
101
-
102
- Due to some legacy decisions, the QueryOutput allows for multiple target- and reference projects.
103
- Aggregation of data now takes place in the dashboard.
104
- QueryOutputs always contain one or a combination of two projects. This means that the
105
- QueryOutput structure could be simplified in the future.
106
-
107
- ## Environment agnosticism
108
-
109
- The output files stored in the file system always need to be machine independent:
110
- this means that all machine specific information, like a complete filepath, needs to be removed from a QueryOutput (paths relative from project root are still allowed).
111
- In that way, the caching mechanism (based on hash comparisons) as described in [Analyzer](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/fundamentals/node-tools/providence-analytics/analyzer.md) is guaranteed to work across different machines.
@@ -1,69 +0,0 @@
1
- # Node Tools >> Providence Analytics >> Analyzer ||20
2
-
3
- Analyzers form the core of Providence. They contain predefined queries based on AST traversal/analysis.
4
- A few examples are:
5
-
6
- - find-imports
7
- - find-exports
8
- - match-imports
9
-
10
- An analyzer will give back a [QueryResult](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/fundamentals/node-tools/providence-analytics/QueryResult.md) that will be written to the file system by Providence.
11
- All analyzers need to extend from the `Analyzer` base class, found in `src/program/analyzers/helpers`.
12
-
13
- ## Public api
14
-
15
- Providence has the following configuration api:
16
-
17
- - name (string)
18
- - requiresReference (boolean)
19
- An analyzer will always need a targetProjectPath and can optionally have a referenceProjectPath.
20
- In the latter case, it needs to have `requiresReference: true` configured.
21
-
22
- During AST traversal, the following api can be consulted
23
-
24
- - `.targetData`
25
- - `.referenceData`
26
- - `.identifier`
27
-
28
- ## Phases
29
-
30
- ### Prepare phase
31
-
32
- In this phase, all preparations will be done to run the analysis. Providence is designed to be performant and therefore will first look if it finds an already existing, cached result for the current setup.
33
-
34
- ### Traverse phase
35
-
36
- The ASTs are created for all projects involved and the data are extracted into a QueryOutput. This output can optionally be post processed.
37
-
38
- ### Finalize phase
39
-
40
- The data are normalized and written to the filesystem in JSON format.
41
-
42
- ## Targets and references
43
-
44
- Every Analyzer needs a targetProjectPath. A targetProjectPath is a file path String that.
45
-
46
- ## Types
47
-
48
- We can roughly distinguish two types of analyzers: those that require a reference and those that don't require a reference.
49
-
50
- ## Database
51
-
52
- In order to share data across multiple machines, results are written to the filesystem in a
53
- "machine agnostic" way. They can be shared through git and serve as a local database.
54
-
55
- ### Caching
56
-
57
- In order to make caching possible, Providence creates an "identifier": a hash from the combination of project versions + Analyzer configuration. When an identifier already exists in the filesystem, the result can be read from cache. This increases performance and helps mitigate memory problems that can occur when handling large amounts of data in a batch.
58
-
59
- ## Analyzer helpers
60
-
61
- Inside the folder './src/program/analyzers', a folder 'helpers' is found.
62
- Helpers are created specifically for use within analyzers and have knowledge about
63
- the context of the analyzer (knowledge about an AST and/or QueryResult structure).
64
-
65
- Generic functionality (that can be applied in any context) can be found in './src/program/utils'.
66
-
67
- ## Post processors
68
-
69
- Post processors are imported by analyzers and act on their outputs. They can be enabled via the configuration of an analyzer. They can be found in './src/program/analyzers/post-processors'. For instance: transform the output of analyzer 'find-imports' by sorting on specifier instead of the default (entry). Other than most configurations of analyzers, post processors act on the total result of all analyzed files instead of just one file/ ast entry.