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

chore: add guard-for-in eslint rule #1210

Merged
merged 1 commit into from
Jul 11, 2024

Conversation

JKRhb
Copy link
Member

@JKRhb JKRhb commented Jan 6, 2024

(Not only) in the context of #1177, I noticed that some of the for loops use the for ... in syntax instead of the for ... 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.

Copy link

codecov bot commented Jan 6, 2024

Codecov Report

Attention: Patch coverage is 67.80822% with 47 lines in your changes missing coverage. Please review.

Project coverage is 76.75%. Comparing base (5e2b362) to head (ee9ebbe).

Files Patch % Lines
...kages/binding-http/src/routes/thing-description.ts 0.00% 14 Missing ⚠️
packages/binding-websockets/src/ws-server.ts 0.00% 6 Missing ⚠️
packages/core/src/servient.ts 58.33% 5 Missing ⚠️
packages/td-tools/src/td-parser.ts 90.00% 2 Missing and 3 partials ⚠️
packages/td-tools/src/thing-model-helpers.ts 78.94% 2 Missing and 2 partials ⚠️
...ckages/binding-netconf/src/codecs/netconf-codec.ts 0.00% 3 Missing ⚠️
packages/core/src/codecs/netconf-codec.ts 0.00% 3 Missing ⚠️
packages/core/src/exposed-thing.ts 25.00% 3 Missing ⚠️
packages/binding-coap/src/mdns-introducer.ts 0.00% 0 Missing and 2 partials ⚠️
packages/core/src/helpers.ts 80.00% 0 Missing and 2 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1210      +/-   ##
==========================================
+ Coverage   76.72%   76.75%   +0.02%     
==========================================
  Files          83       83              
  Lines       16085    16058      -27     
  Branches     1632     1621      -11     
==========================================
- Hits        12341    12325      -16     
+ Misses       3695     3678      -17     
- Partials       49       55       +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@JKRhb JKRhb force-pushed the for-in-loop branch 2 times, most recently from 9f8e8e7 to 2192cc9 Compare January 6, 2024 20:24
@danielpeintner
Copy link
Member

Out of curiosity: Did you run into an actual problem or are you proposing the change because of the possible unexpected errors?

@JKRhb JKRhb marked this pull request as ready for review January 8, 2024 13:16
@JKRhb
Copy link
Member Author

JKRhb commented Jan 8, 2024

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 for of is a better approach than for in in general. So in that regard it is more like an optimization.

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 guard-for-in rule.

Copy link
Member

@relu91 relu91 left a 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.

packages/binding-coap/src/mdns-introducer.ts Outdated Show resolved Hide resolved
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]) {
Copy link
Member

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?

Copy link
Member Author

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]) {
Copy link
Member

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]) {
Copy link
Member

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];

Copy link
Member Author

@JKRhb JKRhb Jan 9, 2024

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; };

Comment on lines 102 to 104
property.readOnly ??= false;
property.writeOnly ??= false;
property.observable ??= false;
Copy link
Member

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?

Copy link
Member

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

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 code should now behave the same as before and should actually only be a refactoring :)

packages/td-tools/src/util/asset-interface-description.ts Outdated Show resolved Hide resolved
packages/td-tools/src/util/asset-interface-description.ts Outdated Show resolved Hide resolved
packages/td-tools/src/util/asset-interface-description.ts Outdated Show resolved Hide resolved
Copy link
Member

@egekorkan egekorkan left a 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

@JKRhb JKRhb marked this pull request as draft February 1, 2024 09:39
@JKRhb
Copy link
Member Author

JKRhb commented Jul 9, 2024

Rebased this PR against the latest state of the master branch and applied some adjustments :) I think this should be ready for another review.

@JKRhb JKRhb marked this pull request as ready for review July 9, 2024 20:18
@@ -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> {
Copy link
Member

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...

Copy link
Member

Choose a reason for hiding this comment

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

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.

I looked over the changes and the they seem fine now. Thanks!

Copy link
Member Author

@JKRhb JKRhb Jul 11, 2024

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)?

Copy link
Member

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

and they are similar but not the same at all 🙈

It seems the one in binding-netconf seems more sophisticated. @lukesmolo?

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 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 😅

Copy link
Member

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.

Copy link
Member

Choose a reason for hiding this comment

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

I created #1304.
@JKRhb shall we fix it independently and you merge in master in this PR? Would that be okay for you?

Copy link
Member Author

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 :)

Copy link
Member

@danielpeintner danielpeintner Jul 12, 2024

Choose a reason for hiding this comment

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

#1305 has been merged. @JKRhb maybe you can merge in master and we can continue with merging this PR ...

Copy link
Member

@danielpeintner danielpeintner Jul 12, 2024

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 🙈

@JKRhb
Copy link
Member Author

JKRhb commented Jul 11, 2024

I looked over the changes and the they seem fine now. Thanks!

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.

@danielpeintner
Copy link
Member

@relu91 are you okay with these changes?

@relu91 relu91 merged commit 4500eef into eclipse-thingweb:master Jul 11, 2024
13 checks passed
@JKRhb JKRhb deleted the for-in-loop branch July 11, 2024 14:24
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.

4 participants