Use strictTemplates Compiler Option #100
Conversation
|
@mdelez I am going to group tests on this PR, so tests are run individually (like in https://github.com/dasch-swiss/knora-api/blob/f984c2e0589aec81e28c45adde4ff76d9820b640/.github/workflows/main.yml#L62-L142). And not all of them would be required for merging, so we could detect problems without blocking development. |
|
|
||
| strategy: | ||
| matrix: | ||
| node-version: [12.x] |
There was a problem hiding this comment.
@subotic Do you happen to know if there could be one central version matrix? This would be easier to update.
There was a problem hiding this comment.
You could try and see if defaults could allow you to define a value which you then could use in all the different matrix statements.
There was a problem hiding this comment.
will do, thx
There was a problem hiding this comment.
There was a problem hiding this comment.
Or did I do it wrong?
There was a problem hiding this comment.
ok, I am giving up on that ...
|
@mdelez I made different groups of tests, and not all of them are required. |
Perfect! |
| <dsp-time-value class="parent-value-component" #displayVal *ngSwitchCase="constants.TimeValue" [mode]="mode" [displayValue]="displayValue"></dsp-time-value> | ||
| <dsp-geoname-value class="parent-value-component" #displayVal *ngSwitchCase="constants.GeonameValue" [mode]="mode" [displayValue]="displayValue"></dsp-geoname-value> | ||
| <dsp-link-value class="parent-value-component" #displayVal *ngSwitchCase="constants.LinkValue" [mode]="mode" [displayValue]="displayValue" | ||
| <dsp-text-value-as-string class="parent-value-component" #displayVal *ngSwitchCase="'ReadTextValueAsString'" [mode]="mode" [displayValue]="$any(displayValue)"></dsp-text-value-as-string> |
There was a problem hiding this comment.
should I work on making a service that returns the correct value type? It shouldn't take too long and then you can use the service in this branch so we don't have to use temporary code that may get left in the master branch for a while
There was a problem hiding this comment.
I think the other two issues are more important. Could we do them first?
There was a problem hiding this comment.
In case of the DisplayEditComponent, we know that this will be correct at runtime. We just have to tell the compiler somehow.
There was a problem hiding this comment.
@mdelez Now that solved all the other problems, you can work on this :-)
|
not to myself: make e2e tests required when this PR has been merged. |
projects/dsp-ui/src/lib/action/components/sort-button/sort-button.component.html
Outdated
Show resolved
Hide resolved
|
@kilchenmann @mdelez @flavens Could you have a look at this PR? I'd like to merge it before working on migrating the advanced search, so that the new code is compiled in strict template mode. |
|
@mdelez I think it is ok to use |
resolves https://dasch.myjetbrains.com/youtrack/issue/DSP-319
requires #101This PR makes the lib compile with Ivy using
"strictTemplates": true. Compilation problems are ignored using$any()(https://angular.io/guide/template-syntax#the-any-type-cast-function).However, the following issues still have to be fixed:
https://dasch.myjetbrains.com/youtrack/issue/DSP-393 (should be addressed soon)https://dasch.myjetbrains.com/youtrack/issue/DSP-391 (trivial)This PR splits tests into groups:
I did not make dev build of lib required since we do not use it in production (Ivy is not used to build the lib for production). However, this test should pass. More checks by the compiler should lead to fewer problems at runtime, that's my rationale.