-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(core): implement exploreDirectory
method
#1186
feat(core): implement exploreDirectory
method
#1186
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #1186 +/- ##
==========================================
+ Coverage 76.65% 77.60% +0.95%
==========================================
Files 80 83 +3
Lines 16821 17311 +490
Branches 1619 1747 +128
==========================================
+ Hits 12894 13435 +541
+ Misses 3897 3840 -57
- Partials 30 36 +6 ☔ View full report in Codecov by Sentry. |
The current version of the implementation should now already be working – I performed some initial testing with the Zion directory :) Some details need to be fixed/improved, though, I will continue working on this later today. |
2e31dcc
to
783f4a0
Compare
This is required for fully supporting the `exploreDirectory` method. See https://www.w3.org/TR/wot-discovery/#exploration-directory-api-things-listing
783f4a0
to
77b916f
Compare
I think this PR could now be ready for an initial review :) Even though there currently are some typescript quirks regarding the handling of One major piece is currently missing the validation of the retrieved TDs – did we already have a function handy that could be used for that? |
ThingModelHelpers has |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you see a possibility to have tests? Using Zion or so would require the service to be always up which may be an issue, right?
Having a second look, doing tests with Zion means that we need to add them in the CLI because we would need to have also the binding templates up and running. It complicates a little bit the setup but it might be good to create a sort of end-to-end testing in a single place. In other words, we won't need to test the operations per binding but we could have a single code base in one place. Probably it is too much work for a single PR. What do you think? |
I think for now I would try to mock the directory API, but having integration or end-to-end testing with Zion in place in the mid-term sounds like a great idea :) |
packages/core/src/validation.ts
Outdated
export function isThingDescription(input: unknown): input is WoT.ThingDescription { | ||
// TODO: Improve validation function |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense to also have proper validation based on the JSON schema (AJV) validation like we do for TMs.
public static validateThingModel(data: ThingModel): { valid: boolean; errors?: string } { |
Anyhow, definitely not in this PR and I am not even sure whether it makes sense int this case since we should be relaxed when consuming a TD and as strict as possible when creating a TD.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your feedback! I actually had already started to change the validation approach so that it uses the JSON schema definition for validation and also added it to the PR now in the latest commits :) Hope that this is still fine
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this PR is a very good start and for me, it is okay to merge it as is 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks still good 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if it is worth to approve the PR. Some remarks that I have:
- validation: I like the approach but it is a half refactoring, we didn't consistently check where ajv was used and updated the code accordingly. I think the refactoring is needed (and has serious implications with Consume and read loop causes memory leak #1062) but it needs to be done systematically.
@ts-expect-error
: I'm not comfortable about disabling tsc without a proper explanation of what is causing the problem and why is a false positive.
Nonetheless, with this new function we are still in the exploratory space so if @danielpeintner wants to move on I won't block it! Just keep in mind the two issues (that need to be added in the issue tracker).
@JKRhb @relu91 what do you think. Shall we tackle the issues mentioned by @relu91 in this PR or is it better to merge this PR as is and create follow-up PRs.... |
Thank you for your feedback, @relu91 and @danielpeintner! You raised valid concerns, @relu91, and I think we could provide some preliminary fixes in this PR:
Yeah, I also had to think about the
Sure, I will investigate what causes the issue here :) It is a bit strange since it runs without a problem when ignoring the errors TypeScript is reporting here, but these might be related to the ES version we are targeting (note that I tried to use the "regular" streams instead of the Node.js ones). Should I try changing those to their Node.js counterpart? |
b292de9
to
951ca10
Compare
I think @relu91's feedback should now be addressed for the most part – since Node.js streams seem to have a different API, I simplified the Regarding the |
Added a tiny fix and two additional test cases in the latest commits. Edit: With c8fc93f, these new tests are now also working as intended 😅 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @JKRhb much better now!
Btw have you tried the implementation in the browser? is browserify able to translate the streams correctly? |
export function getLastValidationErrors() { | ||
const errors = Helpers.tsSchemaValidator.errors?.map((o: ErrorObject) => o.message).join("\n"); | ||
return new Error(errors); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No strong opinion but the term might convey something which is not always the case. It is correct, it is the "last" validation. Anyhow, if used in some other code parts it might report errors of another validation step (not necessarily the one from last isThingDescription
) that used Helpers.tsSchemaValidator
..
Do you know what I mean.
I think we can merge this PR as is and look at some points raised in the comments later
Did I miss anything? |
This PR starts implementing the
exploreDirectory
method that has recently been added to the Scripting API specification.