@genesislcap/foundation-filters 14.63.1-alpha-e78a361.0 → 14.64.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.
- package/README.md +13 -23
- package/package.json +6 -6
package/README.md
CHANGED
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
[](https://lerna.js.org/)
|
|
4
4
|
[](https://www.typescriptlang.org/)
|
|
5
5
|
|
|
6
|
-
`foundation-filters` provides a collection of client
|
|
6
|
+
`foundation-filters` provides a collection of client-side filters, including:
|
|
7
7
|
|
|
8
8
|
* [nodeEnv](./docs/api/foundation-filters.nodeenvfilter.md)
|
|
9
9
|
* [percentage](./docs/api/foundation-filters.percentagefilter.md)
|
|
@@ -16,17 +16,12 @@ These can be run in isolation or as part of a chain using the [runner](./docs/ap
|
|
|
16
16
|
|
|
17
17
|
### [API Docs](./docs/api/index.md)
|
|
18
18
|
|
|
19
|
-
Client
|
|
20
|
-
values. They may also access runtime data or state to provide an outcome. They can be used for simple tasks like array
|
|
21
|
-
or input filtering, to for more advanced use-cases such as driving feature flags, behaviors, directives etc.
|
|
19
|
+
Client-side filters generally take primitive input parameters, and return `true` or `false` based on these values. They may also access runtime data or state to provide an outcome. They can be used for simple tasks like array or input filtering, or for more advanced use cases - such as driving feature flags, behaviors, directives, etc.
|
|
22
20
|
|
|
23
|
-
Filters can be chained using the utilities provided in this package to handle more complex scenarios. When a filter is
|
|
24
|
-
used without all the input parameters needed, we log a warning and return `true` by convention so the chain can continue.
|
|
25
|
-
This is currently controlled at an individual filter level, and may change in time.
|
|
21
|
+
Filters can be chained using the utilities provided in this package to handle more complex scenarios. When a filter is used without all the input parameters needed, Genesis logs a warning and returns `true` by convention so that the chain can continue. This is currently controlled at an individual filter level, and may change in time.
|
|
26
22
|
|
|
27
23
|
:::important
|
|
28
|
-
It's important to highlight that filters are purposefully decoupled from any `effect`, like pairing with a `when()`
|
|
29
|
-
directive or custom effect logic. This flexibility allows these filters to be reused for numerous purposes.
|
|
24
|
+
It's important to highlight that filters are purposefully decoupled from any `effect`, like pairing with a `when()` directive or custom-effect logic. This flexibility allows these filters to be reused for numerous purposes.
|
|
30
25
|
:::
|
|
31
26
|
|
|
32
27
|
## Usage
|
|
@@ -54,10 +49,9 @@ const outcome = this.timeWindow.filter({
|
|
|
54
49
|
});
|
|
55
50
|
```
|
|
56
51
|
|
|
57
|
-
The function version is pretty self-explanatory, and you may be
|
|
58
|
-
reason is at the point of calling a filter, either directly or indirectly as say part of a chain, you may not know what
|
|
59
|
-
data or state from the application it needs to provide its outcome. The DI versions encapsulate this complexity, which
|
|
60
|
-
aids later refactoring, and leaves callers free to pass only primitive input parameters where possible.
|
|
52
|
+
The function version is pretty self-explanatory, and you may be wondering why you would use the DI injected version. The
|
|
53
|
+
reason is at the point of calling a filter, either directly or indirectly as (say) part of a chain, you may not know what
|
|
54
|
+
data or state from the application it needs to provide its outcome. The DI versions encapsulate this complexity, which aids later refactoring, and leaves callers free to pass only primitive input parameters where possible.
|
|
61
55
|
|
|
62
56
|
### DI use cases
|
|
63
57
|
|
|
@@ -71,13 +65,9 @@ const outcome = this.userTargeting.filter({
|
|
|
71
65
|
});
|
|
72
66
|
```
|
|
73
67
|
|
|
74
|
-
Here we've
|
|
75
|
-
the underlying function directly. If where we source the current user from changes over time, the author of the filter
|
|
76
|
-
can refactor centrally.
|
|
68
|
+
Here we've used the `UserTargeting` filter without the need to provide the current user or other data points to the underlying function directly. If we source the current user from changes over time, the author of the filter can refactor centrally.
|
|
77
69
|
|
|
78
|
-
All DI
|
|
79
|
-
may provide other APIs for convenience to abstract underlying implementation details. For example, `UserTargeting`
|
|
80
|
-
provides a `hasAdminProfile` API, so the previous example can be re-written as:
|
|
70
|
+
All DI-based filters implement the [ClientFilter](./docs/api/foundation-filters.clientfilter.md) interface; however, they may provide other APIs for convenience to abstract underlying implementation details. For example, `UserTargeting` provides a `hasAdminProfile` API, so the previous example can be re-written as:
|
|
81
71
|
|
|
82
72
|
```ts
|
|
83
73
|
import { UserTargeting } from '@genesislcap/foundation-filters';
|
|
@@ -87,8 +77,8 @@ import { UserTargeting } from '@genesislcap/foundation-filters';
|
|
|
87
77
|
const outcome = this.userTargeting.hasAdminProfile();
|
|
88
78
|
```
|
|
89
79
|
|
|
90
|
-
This is quite a simplistic example, but
|
|
91
|
-
filters themselves where needed. It is also worth mentioning that DI
|
|
80
|
+
This is quite a simplistic example, but we hope it helps to highlight that common parameters can be predefined in the
|
|
81
|
+
filters themselves where needed. It is also worth mentioning that DI-based filters are registered as transient, meaning
|
|
92
82
|
you will get a new instance for every dependency request or container.get(). The ClientFilterRunner used to run chained
|
|
93
83
|
filters is also transient.
|
|
94
84
|
|
|
@@ -170,7 +160,7 @@ class RunnerExample extends FASTElement {
|
|
|
170
160
|
|
|
171
161
|
## License
|
|
172
162
|
|
|
173
|
-
Note: this project provides front
|
|
163
|
+
Note: this project provides front-end dependencies and uses licensed components listed in the next section; thus, licenses for those components are required during development. Contact [Genesis Global](https://genesis.global/contact-us/) for more details.
|
|
174
164
|
|
|
175
165
|
### Licensed components
|
|
176
|
-
Genesis low-code platform
|
|
166
|
+
Genesis low-code platform
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@genesislcap/foundation-filters",
|
|
3
3
|
"description": "Genesis Foundation Filters",
|
|
4
|
-
"version": "14.
|
|
4
|
+
"version": "14.64.0",
|
|
5
5
|
"sideEffects": false,
|
|
6
6
|
"license": "SEE LICENSE IN license.txt",
|
|
7
7
|
"main": "dist/esm/index.js",
|
|
@@ -40,14 +40,14 @@
|
|
|
40
40
|
"test:debug": "genx test --debug"
|
|
41
41
|
},
|
|
42
42
|
"devDependencies": {
|
|
43
|
-
"@genesislcap/foundation-testing": "14.
|
|
44
|
-
"@genesislcap/genx": "14.
|
|
43
|
+
"@genesislcap/foundation-testing": "14.64.0",
|
|
44
|
+
"@genesislcap/genx": "14.64.0",
|
|
45
45
|
"@types/ua-parser-js": "^0.7.36",
|
|
46
46
|
"rimraf": "^3.0.2"
|
|
47
47
|
},
|
|
48
48
|
"dependencies": {
|
|
49
|
-
"@genesislcap/foundation-comms": "14.
|
|
50
|
-
"@genesislcap/foundation-utils": "14.
|
|
49
|
+
"@genesislcap/foundation-comms": "14.64.0",
|
|
50
|
+
"@genesislcap/foundation-utils": "14.64.0",
|
|
51
51
|
"@microsoft/fast-element": "^1.7.0",
|
|
52
52
|
"@microsoft/fast-foundation": "^2.33.2",
|
|
53
53
|
"tslib": "^2.3.1",
|
|
@@ -61,5 +61,5 @@
|
|
|
61
61
|
"publishConfig": {
|
|
62
62
|
"access": "public"
|
|
63
63
|
},
|
|
64
|
-
"gitHead": "
|
|
64
|
+
"gitHead": "b9342cf385809ba4b2ad9bc592ae9dffe9360ce4"
|
|
65
65
|
}
|