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

Add postfix convention for store naming rule #37

Merged
merged 12 commits into from Sep 26, 2021
Merged

Add postfix convention for store naming rule #37

merged 12 commits into from Sep 26, 2021

Conversation

ilyaryabchinski
Copy link
Contributor

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

@igorkamyshev
Copy link
Member

Thanks for your contribution 🙏

I'm little bit busy now, so I'll review it on Monday.

@ilyaryabchinski
Copy link
Contributor Author

Don't worry 👌 Have a great rest of the week.

Copy link
Member

@igorkamyshev igorkamyshev left a 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("$")) {
Copy link
Member

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

Copy link
Contributor Author

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?

Copy link
Member

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 👍

});
return;
}

// Store creation with .map
if (node.callee?.property?.name === "map") {
const objectIsEffectorStore =
node.callee?.object?.name?.startsWith?.("$");
const objectIsEffectorStore = mode === "prefix"
Copy link
Member

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("$")) {
Copy link
Member

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("$")) {
Copy link
Member

Choose a reason for hiding this comment

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

And here

const parserServices = context.parserServices;
const { parserServices, options } = context;
// prefix mode is a default option
const [mode = "prefix"] = options;
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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

@ilyaryabchinski
Copy link
Contributor Author

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 🙏

@igorkamyshev
Copy link
Member

Sure, it's ok.

Ne boley 🍀

@ilyaryabchinski
Copy link
Contributor Author

ilyaryabchinski commented Sep 17, 2021

Seems like I fixed all those things you mentioned above, but now I have a couple of questions 😄 :

  1. Do you think that we also need to throw an error in the rule effector/no-getState if the convention is configured in the wrong way? Or it's enough to throw only in the rule effector/enforce-store-naming-convention?
  2. I noticed that now store names like $myStore$ are valid. Do you think we should cover these cases as well ?

Copy link
Member

@igorkamyshev igorkamyshev left a 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);
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, 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?.("$")
Copy link
Member

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.

Copy link
Member

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

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
Copy link
Member

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.

Copy link
Contributor Author

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

@@ -0,0 +1,13 @@
function isStoreNameValid(storeName, storeNameConvention) {
Copy link
Member

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.

@igorkamyshev
Copy link
Member

@ilyaryabchinski also, in my opinion, $myStore$ is a bad way to name stores.

@igorkamyshev
Copy link
Member

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

@ilyaryabchinski
Copy link
Contributor Author

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 ⏳

@igorkamyshev
Copy link
Member

It's okay, no worries.

@ilyaryabchinski
Copy link
Contributor Author

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 utils so now it looks a little cleaner(well, at least to me 😄 ).

Let's see if we are finally done with this issue 😸

5o97qv

Copy link
Member

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

@igorkamyshev igorkamyshev merged commit 01e7175 into effector:master Sep 26, 2021
@ilyaryabchinski
Copy link
Contributor Author

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 😊👍

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.

Convention of a store naming
2 participants