feat(dts-generator): add TypedJSONModel #516
Conversation
|
|
| /** | ||
| * TypedJSONModel is a subclass of JSONModel that provides type-safe access to the model data. It is only available when using UI5 with TypeScript. | ||
| * | ||
| * @since 1.138.0 |
There was a problem hiding this comment.
this is going to be a higher version. Need to find out which one it's gonna be..
The interesting thing is that the availability depends on the code in OpenUI5, but the presence of this d.ts snippet depends on the version of the dts-generator.
- On the one hand this means that in order to provide support in version X of UI5, not only this version X needs the respective code, but it also needs to be produced with the updated dts-generator.
- On the other hand, we need to enhance the dts-generator logic to only add this d.ts snippet when the UI5 version being built does contain the code, i.e. must be >= version X.
| /** | ||
| * TypedJSONModel is a subclass of JSONModel that provides type-safe access to the model data. It is only available when using UI5 with TypeScript. | ||
| * | ||
| * @since 1.138.0 |
| @@ -0,0 +1,78 @@ | |||
| # Type Safe JSONModel | |||
|
|
|||
| This package explores type-safe data binding in UI5 applications, | |||
There was a problem hiding this comment.
explores or provides in the meantime?
| as well as the binding paths in all methods mentioned above. | ||
| The limits are presumably a rather theoretical problem, but are to be kept in mind. | ||
|
|
||
| I followed a test-driven approach to implement the required types: |
There was a problem hiding this comment.
"I followed"... this is not exactly the wording expected in such a project. Maybe make it passive (a ... approach was followed).
| I followed a test-driven approach to implement the required types: | ||
| Expectations have been articulated in the folder [`webapp/model/test/cases`](webapp/model/test/cases). | ||
|
|
||
| I could not find a common approach to test typings, so |
| console.assert(typedContext.getProperty("approved") == true); | ||
| console.assert(typedContext.getProperty("items/0/description") == "Notebook"); | ||
|
|
||
| console.assert(model.getProperty("/order/approved") == true); |
There was a problem hiding this comment.
is there a specific reason why you sometimes use "==" instead of "==="?
| /** | ||
| * TypedJSONContext is a subclass of Context that provides type-safe access to the model data. It is only available when using UI5 with TypeScript. | ||
| * | ||
| * @since 1.138.0 |
There was a problem hiding this comment.
here and all other places as well
|
rebase now against the primary error in node 18 and update the expected test result in openui5-snapshot-test with "npm run re-generate" |
| @@ -16,6 +16,7 @@ | |||
| "build": "lerna run build", | |||
| "preci": "lerna run build", | |||
| "ci": "npm-run-all format:validate ci:subpackages legal:*", | |||
| "test:typed-json-model": "cd test-packages/typed-json-model && npm run test", | |||
There was a problem hiding this comment.
As the other scripts do not point to subpackage scripts, better remove this one
| @@ -16,6 +16,7 @@ | |||
| "build": "lerna run build", | |||
| "preci": "lerna run build", | |||
| "ci": "npm-run-all format:validate ci:subpackages legal:*", | |||
There was a problem hiding this comment.
this is how the entire repo should be CI-tested, so I would suggest something like "ci": "npm run lint && npm run ts-typecheck && npm run test", (or just the test?) inside the package.json of your new package.
There was a problem hiding this comment.
ummm... the ts-typecheck actually gives me quite some errors, but it looks like those are the expected ones. So exclude the testcases from being handled by typescript, if that works - or just remove this "ts-typecheck" script: there is not much actual TS code to check except for the model itself and that one is thoroughly tested by your tests.
|
Ah, that was just putting your code to the right places - thanks a lot for the implementation, it's great to get this in! In addition to the comments above, as I told you, please document what to do when a fix is needed, esp. how to update the code in the dts-generator. My prior mail had the description how I split type definitions and implementation. For a small fix or extension you'd probably just apply the changes to what we already have in the dts-generator and in the OpenUI5 repo, not do the full splitting exercise again. Also, we need some documentation for users of the TJM. We only have the JSDoc in the types themselves (good but hard to discover when you don't know the feature) and the sample app deep inside this repo. If you write up some markdown, we can find a good place. E.g. in the gh-pages branch of this repo, where we can get it in immediately (and where you can develop the docu as PR). That place would also be a good one to mention the limitations. Including the relatively esoteric technical ones within the model you already described, but more importantly the real-life ones outside the TJM itself which are more likely to be seen by users, like that in XMLView bindings there is of course no type safety provided by using a typed model (so you can still bind to non-existing properties) etc. |
Add the type definitions for the
TypedJSONModeland adapt the generator to insert them to the core d.ts file.Related to #509 – thanks for your submission, @akudev !
I added tests for
TypedJSONModel, which can be executed separately vianpm run test:typed-json-model, so they can be added to CI when appropriate.