@lion/ui 0.8.4 → 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.
- package/components/core/src/ScopedElementsMixin.js +2 -2
- package/components/core/test/ScopedElementsMixin.test.js +34 -1
- package/components/core/test/SlotMixin.test.js +13 -28
- package/components/form-core/src/FormControlMixin.js +1 -1
- package/components/form-core/src/validate/ValidateMixin.js +9 -4
- package/components/form-core/src/validate/Validator.js +17 -3
- package/components/form-core/test/validate/Validator.test.js +8 -0
- package/components/form-core/test-suites/ValidateMixin.suite.js +7 -7
- package/components/overlays/src/OverlayController.js +25 -1
- package/components/overlays/src/OverlayMixin.js +17 -4
- package/components/overlays/src/utils/adopt-styles.js +3 -3
- package/components/overlays/test/OverlayController.test.js +33 -2
- package/custom-elements.json +582 -0
- package/dist-types/components/core/test/SlotMixin.test.d.ts.map +1 -1
- package/dist-types/components/form-core/src/validate/ValidateMixin.d.ts.map +1 -1
- package/dist-types/components/form-core/src/validate/Validator.d.ts +16 -6
- package/dist-types/components/form-core/src/validate/Validator.d.ts.map +1 -1
- package/dist-types/components/overlays/src/OverlayController.d.ts +2 -0
- package/dist-types/components/overlays/src/OverlayController.d.ts.map +1 -1
- package/dist-types/components/overlays/src/OverlayMixin.d.ts.map +1 -1
- package/dist-types/tsconfig.tsbuildinfo +1 -1
- package/docs/components/checkbox-group/overview.md +2 -2
- package/docs/components/collapsible/overview.md +1 -1
- package/docs/components/combobox/overview.md +1 -1
- package/docs/components/combobox/use-cases.md +1 -1
- package/docs/components/dialog/overview.md +1 -1
- package/docs/components/fieldset/overview.md +5 -5
- package/docs/components/form/overview.md +3 -3
- package/docs/components/icon/use-cases.md +1 -1
- package/docs/components/input/overview.md +1 -1
- package/docs/components/input-amount/overview.md +3 -3
- package/docs/components/input-date/overview.md +3 -3
- package/docs/components/input-datepicker/overview.md +5 -5
- package/docs/components/input-email/overview.md +2 -2
- package/docs/components/input-file/overview.md +1 -1
- package/docs/components/input-iban/overview.md +2 -2
- package/docs/components/input-range/overview.md +2 -2
- package/docs/components/input-stepper/overview.md +1 -1
- package/docs/components/input-tel/overview.md +1 -1
- package/docs/components/input-tel/use-cases.md +6 -6
- package/docs/components/input-tel-dropdown/overview.md +1 -1
- package/docs/components/listbox/use-cases.md +1 -1
- package/docs/components/radio-group/overview.md +3 -3
- package/docs/components/select/use-cases.md +1 -1
- package/docs/components/select-rich/use-cases.md +1 -1
- package/docs/components/tabs/examples.md +1 -1
- package/docs/fundamentals/index.md +4 -4
- package/docs/fundamentals/node-tools/providence-analytics/overview.md +42 -139
- package/docs/fundamentals/node-tools/publish-docs/overview.md +3 -3
- package/docs/fundamentals/node-tools/rocket-preset-extend-lion-docs/overview.md +2 -2
- package/docs/fundamentals/rationales/accessibility.md +1 -1
- package/docs/fundamentals/systems/core/SlotMixin.md +1 -1
- package/docs/fundamentals/systems/core/overview.md +1 -1
- package/docs/fundamentals/systems/form/formatting-and-parsing.md +4 -4
- package/docs/fundamentals/systems/form/model-value.md +1 -1
- package/docs/fundamentals/systems/form/overview.md +28 -28
- package/docs/fundamentals/systems/form/validate.md +2 -2
- package/docs/fundamentals/systems/localize/overview.md +4 -4
- package/docs/fundamentals/systems/overlays/configuration.md +2 -2
- package/docs/fundamentals/systems/overlays/overview.md +5 -5
- package/docs/fundamentals/systems/overlays/use-cases.md +2 -2
- package/docs/fundamentals/tools/helpers/overview.md +1 -1
- package/docs/fundamentals/tools/singleton-manager/overview.md +4 -4
- package/docs/guides/how-to/create-a-custom-field.md +5 -5
- package/docs/guides/how-to/create-a-form.md +4 -4
- package/docs/guides/how-to/extend-a-native-input.md +2 -2
- package/docs/guides/index.md +8 -8
- package/docs/guides/principles/index.md +5 -5
- package/docs/guides/principles/styling.md +1 -1
- package/package.json +1 -1
- package/docs/fundamentals/node-tools/providence-analytics/LocalConfiguration.md +0 -68
- package/docs/fundamentals/node-tools/providence-analytics/QueryResult.md +0 -111
- package/docs/fundamentals/node-tools/providence-analytics/analyzer.md +0 -69
- package/docs/fundamentals/node-tools/providence-analytics/assets/_mermaid.svg.js +0 -1226
- 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/0bee6e3e0b4257594a9d3d389aaaf4ae0638b528/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/0bee6e3e0b4257594a9d3d389aaaf4ae0638b528/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/0bee6e3e0b4257594a9d3d389aaaf4ae0638b528/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.
|