-
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
chore: add guard-for-in
eslint rule
#1210
Conversation
9f8e8e7
to
2192cc9
Compare
Out of curiosity: Did you run into an actual problem or are you proposing the change because of the possible unexpected errors? |
I think there haven't been real problems so far, however, I think I've already read some time ago that using However, I've also noticed that there are several places where a pattern like for (const key in object) {
const value = object[key];
useKeyAndValue(key, value);
} is being used. In terms of readability and especially type safety, I think it is better to rather use something like for (const [key, value] of Object.entries(object)) {
useKeyAndValue(key, value);
} instead, which is encouraged by activating the |
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.
Some questions/required changes below.
const el = properties[key]; | ||
// TODO: Use correct type for el | ||
// eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
for (const [key, el] of Object.entries(properties) as [string, any]) { |
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.
PropertyElement
doesn't work here?
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.
Unfortunately, DataSchema
is currently defined as an object whose values are typed as any
:/ So in this case, we would need to cast. Note also that these are the properties
of the DataSchema
and not Property Affordances. In any case, the typing here needs to be revisited.
const el = properties[key]; | ||
// TODO: Use correct type for el | ||
// eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
for (const [key, el] of Object.entries(properties) as [string, any]) { |
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.
Same as above?
@@ -535,11 +535,11 @@ export default class OctetstreamCodec implements ContentCodec { | |||
} | |||
|
|||
result = result ?? Buffer.alloc(parseInt(parameters.length)); | |||
for (const propertyName in schema.properties) { | |||
// eslint-disable-next-line @typescript-eslint/no-explicit-any | |||
for (const [propertyName, propertySchema] of Object.entries(schema.properties) as [string, any]) { |
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.
Missing TODO. can't we try to use the inferred type from the removed line below?
const propertySchema = schema.properties[propertyName];
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.
Missing TODO.
Thank you, should be fixed now :)
can't we try to use the inferred type from the removed line below?
const propertySchema = schema.properties[propertyName];
Unfortunately, the type of propertySchema
was any
here :/ DataSchema
seems to be defined like this at the moment in the wot-typescript-definitions
:
type DataSchema = { [key: string]: any; };
packages/td-tools/src/td-parser.ts
Outdated
property.readOnly ??= false; | ||
property.writeOnly ??= false; | ||
property.observable ??= false; |
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.
The new code is not exactly the same as the old one. The old one also corrected the type of the property. @danielpeintner should we keep it or the new version is better?
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.
Good question. In theory for well-defined TDs it should not make any difference on the other hand the more complex "old" code fixes wrong types also. If it were me to decide I would stick with the old code.. but I do not have a very strong preference.
the same goes for actions and events
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.
The code should now behave the same as before and should actually only be a refactoring :)
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.
Fine regarding the changes to mqtt package
Rebased this PR against the latest state of the |
@@ -453,15 +447,15 @@ export class ThingModelHelpers { | |||
return tmpThingModels; | |||
} | |||
|
|||
private static getThingModelRef(data: Record<string, unknown>): Record<string, unknown> { | |||
const refs = {} as Record<string, unknown>; | |||
private static getThingModelRef(data: Record<string, unknown>): Record<string, string> { |
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.
A general comment. Changes to ThingModel code should also go to https://github.com/eclipse-thingweb/td-tools/tree/main/node/thing-model later...
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 created eclipse-thingweb/td-tools#33
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 looked over the changes and the they seem fine now. Thanks!
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.
By the way: I just fully realized only now that there are two netconf-codec.ts
files, one in the core
package and one in the binding-netconf
package. I wonder if we should remove one of them (probably the one in the core
package)?
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.
uiii, strange and bad. I checked them
- https://github.com/eclipse-thingweb/node-wot/blob/master/packages/binding-netconf/src/codecs/netconf-codec.ts
vs. - https://github.com/eclipse-thingweb/node-wot/blob/master/packages/core/src/codecs/netconf-codec.ts
and they are similar but not the same at all 🙈
It seems the one in binding-netconf seems more sophisticated. @lukesmolo?
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 checked them
* https://github.com/eclipse-thingweb/node-wot/blob/master/packages/binding-netconf/src/codecs/netconf-codec.ts vs. * https://github.com/eclipse-thingweb/node-wot/blob/master/packages/core/src/codecs/netconf-codec.ts
and they are similar but not the same at all 🙈
Hmm, yeah, if I see it correctly, commit 56797cd intended to move the codec to the binding directory but also left it in the core package 😅
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 should be moved to its own issue.
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.
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.
As this one is already merged, I think we can continue in #1305 independently :)
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.
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.
Ahh, I missed that the PR is already merged 🙈
Thank you! :) The PR would now be ready to be merged – however, I guess we should wait for #1302 et al. to resolve the issue with the eslint step. |
@relu91 are you okay with these changes? |
(Not only) in the context of #1177, I noticed that some of the for loops use the
for ... in
syntax instead of thefor ... of
syntax. Apparently, the former style is discouraged and not recommended by eslint, for example (see https://eslint.org/docs/latest/rules/guard-for-in).This PR replaces the code lines in question and enforces the new style by activating the
guard-for-in
eslint rule.