-
Notifications
You must be signed in to change notification settings - Fork 16
refactor: use getNgRx*
to grab all Store
instances
#221
refactor: use getNgRx*
to grab all Store
instances
#221
Conversation
src/utils/helper-functions/utils.ts
Outdated
}, []) | ||
} | ||
|
||
export function getNgRxStoreIdentifiers( |
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.
or maybe
export function getNgRxStoreIdentifiers( | |
export function getNgRxStores( |
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.
`getNgRxStoreIdentifiers is fine for me
return stores.reduce( | ||
(visitors, store) => ({ | ||
...visitors, | ||
[`${pipeableSelect(store.name)}, ${storeSelect(store.name)}`]( | ||
node: TSESTree.CallExpression, | ||
) { |
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.
This would grab any existing Store
.
typeAnnotation: TSESTree.TSTypeAnnotation | ||
}) { | ||
Program() { | ||
const [store] = getNgRxStoreIdentifiers(context) ?? [] |
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.
Only the first Store
would be reported.
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 changed this behavior and we're now reporting all stores
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 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
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.
Feel free to merge this @rafaelss95 if it's ok for you.
@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 😞 |
Hi @rafaelss95 don't worry about it. |
0508e76
to
ed635e1
Compare
ed635e1
to
93e8432
Compare
@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 |
Hi @rafaelss95 after a first glance it looks super! |
Not really. Besides that, there are some new tests to ensure we cover multiple |
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.
Looking good! I have nothing else to say 🚀
🎉 This PR is included in version 1.46.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
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 theStore
, we get theIdentifier
, or rather, not just the first one, but all of them (Identifier[]
), basicallyfindNgRx*
(simplestring
) would becomegetNgrx*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
anduse-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 tono-typed-global-store
anduse-consistent-global-store-name
too? Or should we change the behavior ofno-typed-global-store
anduse-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 usingreduce
) and you can also seeno-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.