Skip to content
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

First steps in fixing #758 #767

Merged
merged 6 commits into from
Jun 10, 2022
Merged

First steps in fixing #758 #767

merged 6 commits into from
Jun 10, 2022

Conversation

relu91
Copy link
Member

@relu91 relu91 commented May 20, 2022

I've started the long journey in the pursuit of a type-safe code base. This PR is still a work in progress since I have still to solve the issues caused by my changes in the other packages. My plan in this PR is to have td-tools and core strictly checked. The good news is that they already are, BUT on the way, I had to make some choices that influenced the other packages. To fully close this PR I will fix the errors in the other packages to have the CI/CD work again. Meanwhile, I'd ask you to review core and td-tools because I'll try to not touch those anymore.

Let me know if you see something off! 👍🏻

relu91 added 2 commits May 20, 2022 17:41
Signed-off-by: reluc <relu.cri@gmail.com>
Signed-off-by: reluc <relu.cri@gmail.com>
Copy link
Member

@JKRhb JKRhb left a 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 hard work! See a couple of comments/suggestions below :)

packages/core/src/consumed-thing.ts Outdated Show resolved Hide resolved
Comment on lines +516 to +517
// eslint-disable-next-line @typescript-eslint/no-non-null-assertion -- if cacheIdx is valid, then clients *contains* schemes[cacheIdx]
client = this.getClients().get(schemes[cacheIdx])!;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to throw an error here instead?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The thing is that at the point we are sure that this.getClients().get(schemes[cacheIdx])! will not be undefined. Check line 508 cacheIdx will be not be -1 if this.getClients() contains that scheme.

packages/core/src/consumed-thing.ts Show resolved Hide resolved
packages/core/src/consumed-thing.ts Show resolved Hide resolved
bytes = codec.valueToBytes(value, schema, par);
} else {
console.warn(
"[core/content-serdes]",
`ContentSerdes passthrough due to unsupported serialization format '${contentType}'`
);
bytes = Buffer.from(value.toString());
bytes = Buffer.from(value === null ? "" : value.toString());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it intended to only check for null and not also for undefined (using value == null) here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So if we just trust the tsc compiler we know that value is not undefined, therefore it does not make sense. Some people say that in general is not guaranteed that people will use your library from TS and therefore you should take into account corner cases that are covered by the compiler. My problem here is that we don't have a policy. So if we check for undefined here, then we have to do it everywhere basically.... not sure if is something that we want.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, there is a check above, though, which logs a warning if the value is undefined. To be consistent, that check would need to be removed as well?

My suggestion here would be to simply use the following:

Suggested change
bytes = Buffer.from(value === null ? "" : value.toString());
bytes = Buffer.from(value?.toString() ?? "");

This way, the code is a bit more concise and undefined is also covered (which would otherwise cause an error, as toString() seems to not exist on undefined, in contrast to other data types).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might have agreed with @JKRhb's suggestion but then I thought more about the logic. IMHO is wrong... The else branch is activated if no codec is found and it defaults to simple sending value.toString or "". But value.toString() is not always correct. For example for objects it returns: [object Object] . Why should we send this to the wire? 🤔 So the resolve this conversation I would like to open an issue instead of fixing this detail. thumbs up if you agree

packages/core/src/servient.ts Show resolved Hide resolved
packages/core/src/servient.ts Outdated Show resolved Hide resolved
packages/core/src/wot-impl.ts Outdated Show resolved Hide resolved
packages/core/src/wot-impl.ts Outdated Show resolved Hide resolved
@@ -239,7 +239,7 @@ export class ThingModelHelpers {
console.debug("[td-tools]", "http fetched:", parsedData);
resolve(parsedData);
} catch (e) {
console.error(e.message);
console.error("[td-tools]", (e as Error).message);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could also call e.toString() here.

@relu91
Copy link
Member Author

relu91 commented May 27, 2022

@JKRhb and @danielpeintner I'm starting working on this again. I'm not sure about what I need to address first. What do you prefer between:

  1. Resolve @JKRhb review comments/suggestions
  2. Fix other packages

@danielpeintner
Copy link
Member

I think we should focus on core and td-tools for now.
Other packages may also follow in future PRs.

@relu91
Copy link
Member Author

relu91 commented May 27, 2022

so you are ok even if the other packages have building errors? (my personal take is to go with this strategy)

Signed-off-by: reluc <relu.cri@gmail.com>
@danielpeintner
Copy link
Member

so you are ok even if the other packages have building errors? (my personal take is to go with this strategy)

One the short run either way is fine for me.
Before merging this PR we should have a clean build. I guess, there is no question with that regard.

What I think is a good way forward is to properly fix core and td-tools with strict rules in this PR.
The other packages can be fixed so that it compiles. In follow-up PRs we can fix any other binding/package with strict rules in place...

I don't know whether that makes sense for everybody?

@relu91
Copy link
Member Author

relu91 commented Jun 7, 2022

Before merging this PR we should have a clean build. I guess, there is no question with that regard.

Ok then for a clear build I have to change also non-core packages... let's hope it is not a massive change! But to simplify the review process I would first fix @JKRhb's comments.

relu91 added 2 commits June 8, 2022 15:09
Signed-off-by: reluc <relu.cri@gmail.com>
@relu91 relu91 requested a review from danielpeintner June 8, 2022 19:24
Copy link
Member

@danielpeintner danielpeintner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good work @relu91 👍

Looks good!

Since I don't have much time before the vacation and I think it would be good to merge it soon I tried to look as good as possible.

Note: The PR introduces some more // @ts-ignore we might want to look later.

BTW, see question below w.r.t. to killme.js

killme.js Outdated Show resolved Hide resolved
Signed-off-by: reluc <relu.cri@gmail.com>
@relu91
Copy link
Member Author

relu91 commented Jun 10, 2022

File removed, merging.

@relu91 relu91 merged commit 1d2ea3b into eclipse-thingweb:master Jun 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants