Skip to content
This repository has been archived by the owner on Jul 11, 2024. It is now read-only.

refactor: use getNgRx* to grab all Store instances #221

Conversation

rafaelss95
Copy link
Collaborator

@rafaelss95 rafaelss95 commented Sep 20, 2021

So, I've opened this PR to discuss in practice what something we discussed some time ago #189 (comment)...

The proposal here is to normalize the store retrieval. Instead of getting just the string that represents the Store, we get the Identifier, or rather, not just the first one, but all of them (Identifier[]), basically findNgRx* (simple string) would become getNgrx*Identifiers (Identifier[]).

With this we'll be able to use this method for the remaining rules that still don't use this method to grab the store(s): no-multiple-global-stores, no-typed-global-store and use-consistent-global-store-name.


Question/Statements:

Currently, the vast majority of the rules, except the three mentioned above only cares about the first injected Store. Should we apply this to no-typed-global-store and use-consistent-global-store-name too? Or should we change the behavior of no-typed-global-store and use-consistent-global-store-name to report only the first match?

You can see use-selector-for-select's changes how it would look like if we apply the option 1 => it basically loop through the stores and build the visitors using reduce) and you can also see no-typed-global-store's changes how it would look like if we apply the option 2 => it basically gets the first injected instance as we do in the other rules).

If you ask me, I don't have a strong opinion about this, but for me, if you have more than one injected Store ​​you either injected by a mistake or I don't know what the reason could be 😅

Maybe there's a case I didn't think you need to inject more than one? 🤔

In any case, let me know your thoughts.


Please, note that this is just a draft and not necessarily must be merged.

}, [])
}

export function getNgRxStoreIdentifiers(
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

or maybe

Suggested change
export function getNgRxStoreIdentifiers(
export function getNgRxStores(

Copy link
Owner

Choose a reason for hiding this comment

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

`getNgRxStoreIdentifiers is fine for me

Comment on lines 39 to 44
return stores.reduce(
(visitors, store) => ({
...visitors,
[`${pipeableSelect(store.name)}, ${storeSelect(store.name)}`](
node: TSESTree.CallExpression,
) {
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This would grab any existing Store.

typeAnnotation: TSESTree.TSTypeAnnotation
}) {
Program() {
const [store] = getNgRxStoreIdentifiers(context) ?? []
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Only the first Store would be reported.

Copy link
Owner

Choose a reason for hiding this comment

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

I changed this behavior and we're now reporting all stores

Copy link
Owner

@timdeschryver timdeschryver left a comment

Choose a reason for hiding this comment

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

I like the idea.
Having multiple stores is a bad practice (that's why it's also a rule).
For our rules, I think it makes sense to report all the stores (because the multiple stores rule could be turned off).

Did you check the performance gains? or is this just a gut feeling?

If you can resolve the conflicts, I think that we can merge it

@github-actions github-actions bot removed the conflicts There is a merge conflict label Oct 5, 2021
@timdeschryver timdeschryver marked this pull request as ready for review October 5, 2021 17:00
Copy link
Owner

@timdeschryver timdeschryver left a comment

Choose a reason for hiding this comment

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

Feel free to merge this @rafaelss95 if it's ok for you.

@rafaelss95
Copy link
Collaborator Author

@timdeschryver I prefer to change a bit before merging. I opened it with little change as possible, so you could give me ur opinion. Now that I have your opinion validated, maybe I could change some other rules already in this PR. WDYT? If so, I can do it tomorrow when I get some more time. I've been busy these days 😞

@timdeschryver
Copy link
Owner

Hi @rafaelss95 don't worry about it.
You can refactor existing rules in this PR if you want, just make sure that you commit per rule as that would be easier to review for me (but I see you're already doing that 👍).
Ping me when the PR is ready to be reviewed.

@rafaelss95 rafaelss95 force-pushed the feat/proposal-use-method-to-grab-stores branch from ed635e1 to 93e8432 Compare October 11, 2021 01:30
@rafaelss95
Copy link
Collaborator Author

@timdeschryver Done! I think I finished everything I had planned here.

The PR got huge mostly due to the testing changes, but I tried to separate as much as I could. In any case, let me clear up any doubts... and I'm totally open to breaking it if you feel more comfortable.

Also, please take as much time as you think necessary to review it.


Btw, I didn't touch the avoid-cyclic-effects tests to avoid conflicts with #254 (but I still plan to add tests to cover multiple Actions) in another PR.

@timdeschryver
Copy link
Owner

Hi @rafaelss95 after a first glance it looks super!
I'll go through it in more details later this week.
Just one question, I'm assuming you didn't make changes to the contents of a tests, just the formatting. Is that assumption valid?

@rafaelss95
Copy link
Collaborator Author

I'm assuming you didn't make changes to the contents of a tests, just the formatting. Is that assumption valid?

Not really. Besides that, there are some new tests to ensure we cover multiple Store-like and also some naming changes for consistency (like class somethingElse to class Ok<index> / NotOk<index> (to help in debugging - and also to maintain a standard).

Copy link
Owner

@timdeschryver timdeschryver left a comment

Choose a reason for hiding this comment

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

Looking good! I have nothing else to say 🚀

@timdeschryver timdeschryver merged commit c392618 into timdeschryver:main Oct 12, 2021
@github-actions
Copy link

🎉 This PR is included in version 1.46.2 🎉

The release is available on:

Your semantic-release bot 📦🚀

@rafaelss95 rafaelss95 deleted the feat/proposal-use-method-to-grab-stores branch October 13, 2021 00:56
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants