@genesislcap/foundation-filters 14.63.1 → 14.64.1

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 (2) hide show
  1. package/README.md +13 -23
  2. package/package.json +6 -6
package/README.md CHANGED
@@ -3,7 +3,7 @@
3
3
  [![lerna](https://img.shields.io/badge/maintained%20with-lerna-cc00ff.svg)](https://lerna.js.org/)
4
4
  [![TypeScript](https://img.shields.io/badge/%3C%2F%3E-TypeScript-%230074c1.svg)](https://www.typescriptlang.org/)
5
5
 
6
- `foundation-filters` provides a collection of client side filters, including:
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 side filters generally take primitive input parameters, and will return `true` or `false` based these
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 thinking why would you use the DI injected version. The
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 leveraged the `UserTargeting` filter without the need to provide the current user or other data points to
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 based filters implement the [ClientFilter](./docs/api/foundation-filters.clientfilter.md) interface, however they
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 hopefully helps to highlight that common parameters can be predefined in the
91
- filters themselves where needed. It is also worth mentioning that DI based filters are registered as transient, meaning
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 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.
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.63.1",
4
+ "version": "14.64.1",
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.63.1",
44
- "@genesislcap/genx": "14.63.1",
43
+ "@genesislcap/foundation-testing": "14.64.1",
44
+ "@genesislcap/genx": "14.64.1",
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.63.1",
50
- "@genesislcap/foundation-utils": "14.63.1",
49
+ "@genesislcap/foundation-comms": "14.64.1",
50
+ "@genesislcap/foundation-utils": "14.64.1",
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": "5d9a089691a3919092d15c10c7894dae5f67ebcc"
64
+ "gitHead": "388d98a93111aa940bb8d3d0272f7de616d519cd"
65
65
  }