@tft/crispr-forms 13.0.0 → 13.0.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.
package/README.md CHANGED
@@ -7,81 +7,22 @@
7
7
 
8
8
  [Interactive docs](https://stackblitz.com/github/nayfin/tft-documentation)
9
9
 
10
- ## VOTE ON POSSIBLE BREAKING CHANGE
11
10
 
12
- I'd like to implement modeled form configurations, which would allow users to get compilation errors when a form configuration will create a form value that is outside of the desired model.
11
+ ### Breaking changes v11 => v13
13
12
 
14
- For instance, let's say we want to create a form configuration that would generate a form who's value matches a simple model:
13
+ We have a few breaking changes in this release, and probably a few more on the way. We'll make it worth it in upcoming releases though.
15
14
 
16
- ```ts
17
- interface SimpleModel {
18
- a: string;
19
- b: string;
20
- }
21
- ```
22
-
23
- The form config would look something like this:
24
-
25
- ```ts
26
- const formConfig: FormConfig = {
27
- ...
28
- fields: [
29
- {
30
- controlName: 'a',
31
- controlType: ControlType.INPUT,
32
- },
33
- {
34
- controlName: 'b',
35
- controlType: ControlType.INPUT
36
- },
37
- ]
38
- }
39
- ```
40
-
41
- Ideally, I would like to enable passing the model to the config as a generic to enforce `controlName`s alignment with property key names.
42
-
43
- ```ts
44
-
45
- const formConfig: FormConfig<SimpleModel> = {
46
- ...
47
- fields: [
48
- {
49
- controlName: 'a',
50
- controlType: ControlType.INPUT,
51
- },
52
- {
53
- controlName: 'b',
54
- controlType: ControlType.INPUT,
55
- },
56
- {
57
- controlName: 'invalidControlName', // <-- this would throw a compilation error
58
- controlType: ControlType.INPUT,
59
- },
60
- ]
61
- }
62
- ```
63
-
64
- This change would be very easy if I had initially made the `fields` property a mapped object of fields instead of an array, but it may be impossible to accomplish in the current architecture. So if you have ideas on how this can be accomplished without the massive breaking change of converting the `fields` property to a mapped object, take a look at the open [stackoverflow question](https://stackoverflow.com/questions/66359127/strongly-type-form-generator-config-array).
15
+ - `FileUploadComponent` is now `FileUploadFieldComponent` to align with naming convention of the rest of the form field. If you're using this class directly you'll have to update usage.
16
+ - Most control configurations now require a `label` property. This is to align with the changes to the Angular Material template API for form fields.
17
+ - New dependency on 'browser-image-compression'. It's a little heavy, we're working on making it only required if you use the `ImageUploadFieldComponent` and we may switch to a smaller library if we find a better one and more time.
65
18
 
66
- If we can't get the desired behavior without changing the `fields` property, we will have to change the `fields` property from an array to an object, with the `controlName` as the key to each field config. The previous example would look like this:
19
+ #### Upcoming / In Progress
67
20
 
68
- ```ts
69
- const newFormConfig: FormConfig<SimpleModel> = {
70
- ...
71
- fields: {
72
- a: {
73
- controlType: ControlType.INPUT,
74
- },
75
- b: {
76
- controlType: ControlType.INPUT,
77
- }
78
- }
79
- }
80
- ```
21
+ - Creating modules for each component so that you can avoid importing unused components
22
+ - Switch from MomentDateAdaptor to FnsDateAdapter
81
23
 
82
- Let me know what you think in this [survey](https://docs.google.com/forms/d/e/1FAIpQLSehFV17thIy79mV63sHOJIcwG-iALr9AyltrCOAbCcaFm1syg/viewform?usp=sf_link). Is the breaking change worth it to get modeled configurations or would you prefer to not have to align your configurations with the new system?
83
24
 
84
- # NEW FEATURES:
25
+ # NEW FEATURES v11:
85
26
 
86
27
  ## Buttons can reset form or take custom events
87
28
 
@@ -110,7 +51,6 @@ export class CustomComponentComponent {
110
51
  ```
111
52
  Examples of how to extend current field behavior available [here](https://stackblitz.com/github/nayfin/tft-documentation?file=src%2Fapp%2Fcrispr-forms-demo%2Ffeatures%2Finfo%2Finfo.component.ts0)
112
53
 
113
-
114
54
  ### Breaking changes v10 => v11
115
55
 
116
56
  All fields deprecated in v10 have been removed
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@tft/crispr-forms",
3
- "version": "13.0.0",
3
+ "version": "13.0.1",
4
4
  "peerDependencies": {
5
5
  "@angular/common": "^13.0.0",
6
6
  "@angular/forms": "^13.0.0",
@@ -9,12 +9,11 @@
9
9
  "@angular/cdk": "^13.0.0",
10
10
  "@tft/form-validation-handler": "^13.0.0",
11
11
  "@angular/material-moment-adapter": "^13.0.0",
12
- "ngx-image-compress": "^13.0.0",
12
+ "browser-image-compression": "^1.0.0",
13
13
  "moment": "^2.24.0",
14
14
  "rxjs": "^7.0.0",
15
15
  "@angular/platform-browser-dynamic": "13.2.1",
16
- "@angular/platform-browser": "13.2.1",
17
- "browser-image-compression": "~1.0.0"
16
+ "@angular/platform-browser": "13.2.1"
18
17
  },
19
18
  "dependencies": {
20
19
  "tslib": "^2.0.0"
Binary file
Binary file