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
Add postfix convention for store naming rule #37
Add postfix convention for store naming rule #37
Conversation
Thanks for your contribution 🙏 I'm little bit busy now, so I'll review it on Monday. |
Don't worry 👌 Have a great rest of the week. |
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.
Thanks for your contribution, one more time. It's a great help.
I found some issues in this PR. Could you fix it, please?
Also, I found a logic problem of this feature. The rule effector/no-getState
in JS-case (with unavailable type information) rely on naming convention to detect store. I think, we should add a support of postfix-notation in this rule too. Can we get options of this rule from one another? Or, we can use both notations to detect stores (it can lead to false-positive triggers in some cases)?
@@ -38,11 +45,24 @@ module.exports = { | |||
|
|||
const storeName = node.id.name; | |||
|
|||
if (storeName?.startsWith("$")) { | |||
if (mode === "prefix" && storeName?.startsWith("$")) { |
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.
Shall we extract this logic to some place? I see, it is used here and in the JS-case. Also, I suppose it should be used in effector/no-getState
JS-case (it detects stores by naming convention).
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 in this case we have to change the implementation and use shared settings. Otherwise, it wouldn’t be possible to share the mode value across several rules.
What do you think?
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.
It seems like the good idea 👍
rules/enforce-store-naming-convention/enforce-store-naming-convention.js
Outdated
Show resolved
Hide resolved
}); | ||
return; | ||
} | ||
|
||
// Store creation with .map | ||
if (node.callee?.property?.name === "map") { | ||
const objectIsEffectorStore = | ||
node.callee?.object?.name?.startsWith?.("$"); | ||
const objectIsEffectorStore = mode === "prefix" |
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 a mention before, this logic can be extracted to a separate function, so this piece of code could be simplified.
@@ -101,14 +134,24 @@ module.exports = { | |||
} | |||
|
|||
const storeName = node.parent.id.name; | |||
if (storeName.startsWith("$")) { | |||
if (mode === "prefix" && storeName.startsWith("$")) { |
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 same.
@@ -125,14 +168,24 @@ module.exports = { | |||
} | |||
|
|||
const storeName = node.parent.id.name; | |||
if (storeName.startsWith("$")) { | |||
if (mode === "prefix" && storeName.startsWith("$")) { |
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.
And here
rules/enforce-store-naming-convention/enforce-store-naming-convention.js
Show resolved
Hide resolved
rules/enforce-store-naming-convention/enforce-store-naming-convention.md
Outdated
Show resolved
Hide resolved
rules/enforce-store-naming-convention/postfix/examples/correct-store-naming.js
Outdated
Show resolved
Hide resolved
const parserServices = context.parserServices; | ||
const { parserServices, options } = context; | ||
// prefix mode is a default option | ||
const [mode = "prefix"] = options; |
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.
May we validate input here? What if user write incorrect mode? I think, we should raise a readable exception in this case.
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 added this, but not sure if the message is clear 😄 Do you have something on your mind?
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 like the message, but I think, we should add more information — like "the configuration of effector-plugin-eslint ..."
Thank you for the review!👍 I feel sick today but I will try to fix all the comments on the upcoming weekend or the latest at the beginning of the next week. I hope it doesn't affect your plans for 1.0 version of the project 🙏 |
Sure, it's ok. Ne boley 🍀 |
Seems like I fixed all those things you mentioned above, but now I have a couple of questions 😄 :
|
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.
Sorry for the delay 🥲
It's a great job, thanks! I left some minor comments. I think, it's the last iteration 🌚
const { parserServices, settings } = context; | ||
// prefix convention is default | ||
const storeNameConvention = settings.effector?.storeNameConvention || "prefix"; | ||
validateStoreNameConvention(storeNameConvention); |
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, we can pass the whole context
to this function for more flexible validation.
const objectIsEffectorStore = | ||
node.callee?.object?.name?.startsWith?.("$"); | ||
const objectIsEffectorStore = storeNameConvention === "prefix" | ||
? node.callee?.object?.name?.startsWith?.("$") |
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.
In my opinion, we ought to move this check to shared because it's widely used to determine Effector-stores in JS-code without type information.
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.
Yeah, my bad, it's already extracted. Could we use isStoreNameValid
here?
}, | ||
}, | ||
], | ||
}); | ||
} | ||
|
||
function validateStoreNameConvention(storeNameConvention) { |
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.
So, this function looks like shred validation utility, which must be used in any rule with store defining.
```ts | ||
// 👍 nice name | ||
const $name = createStore(null); | ||
|
||
// 👎 bad name | ||
const name = createStrore(null); | ||
``` | ||
## Postfix convention |
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.
Shall we move documentation about shred settings to main README? It seems like general info.
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 yes it's a good idea to copy this info to README, but I'd also still keep the information here since it's related to the particular rule
utils/is-store-name-valid.js
Outdated
@@ -0,0 +1,13 @@ | |||
function isStoreNameValid(storeName, storeNameConvention) { |
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.
Maybe replace storeNameConvention
by context
? In this case, we can move validation here too, and simplify code of rules.
@ilyaryabchinski also, in my opinion, |
@ilyaryabchinski I'm going to release 0.3.0 at the weekend. If you'll finish this PR in a few days, I can wait for you before it. What do you think? |
I am gonna work on your comments this weekend, but not sure if I can finalize all the stuff by the end of the weekend. so I think it would be safer if you release 0.3.0 without these changes. Sorry for the delays I'm having quite busy times at work due to the end of Q3 ⏳ |
It's okay, no worries. |
Your vision is great, Thank you for your comments! I resolved them and added some logic to handle these kinds of edge cases. I also extracted several functions to Let's see if we are finally done with this 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.
Good job! Thanks a lot, it'a great help 🙏
Sorry for such a huge number of comments 😢
It'll be released it 0.3.0 today later.
Don't worry, I understand u have some vision and ideas on the project and also it was my first experience developing custom ESLint rules, so I learned a lot. Thank you for the collaboration 😊👍 |
Adds a possibility to configure convention for store naming. Prefix convention will be a default.
Most new files are created for testing purposes 🙂
closes #31