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

Implement getCategories store getter #284

Merged
merged 4 commits into from
Dec 21, 2022

Conversation

surchs
Copy link
Contributor

@surchs surchs commented Dec 16, 2022

Closes #254

@surchs surchs changed the title Surchs-255 Implement getCategories store getter Dec 16, 2022
Copy link
Contributor

@jarmoza jarmoza left a comment

Choose a reason for hiding this comment

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

Just two small issues regarding naming/styling and good to go

@@ -39,14 +40,14 @@

...mapGetters([

"categories",
"getCategories",
Copy link
Contributor

Choose a reason for hiding this comment

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

Just for the sake of simplicity - why include get in the name? Is this something we just went with from the Miro? The code using the returned value from the getter should not care that it's interacting with a getter.

Since categories is now a more complex field in the refactor, and we really want the names of the categories here how about naming this getter something like categoryNames?

Copy link
Contributor

@rmanaem rmanaem Dec 19, 2022

Choose a reason for hiding this comment

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

I think we can take a page out of the old Java OOP best practices and use get(for getters) and set(for mutators) prefixes. It has a nice ring to it but I agree on the 2nd point maybe rename it to getCategoryNames?

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 I like the combo here. @jarmoza: I like that the methodname tells you in easy language what it does. I haven't found any official recommendations so far, but I like the thinking in this issue: vuestorefront/vue-storefront#2069

Copy link
Contributor

Choose a reason for hiding this comment

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

@surchs Seems like a good basis for a standard.

Copy link
Contributor Author

@surchs surchs Dec 21, 2022

Choose a reason for hiding this comment

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

Good point. I'm tracking this here now: #287. For the refactor I would say we make the vuex method names consistent as we implement them. So I will leave categoryClasses alone for now, even though it should also start with get to be consistent.

@@ -2,11 +2,16 @@
import Vue from "vue";

export const state = () => ({
columnToCategoryMapping: {}
columnToCategoryMapping: {},
Copy link
Contributor

Choose a reason for hiding this comment

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

We should alphabetize object keys if we don't have a functional grouping for them.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch @jarmoza. Didn't we have something setup to complain / fix this issue as part of the linting? Should we?

Copy link
Contributor

@rmanaem rmanaem left a comment

Choose a reason for hiding this comment

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

Looks good to me! 🎉

vuex getters should start with `get`.
@surchs surchs requested a review from jarmoza December 21, 2022 16:06
@surchs surchs closed this Dec 21, 2022
@surchs surchs deleted the surchs-255 branch December 21, 2022 16:43
@surchs surchs restored the surchs-255 branch December 21, 2022 16:43
@surchs surchs reopened this Dec 21, 2022
@surchs
Copy link
Contributor Author

surchs commented Dec 21, 2022

nice...

@surchs surchs requested a review from rmanaem December 21, 2022 16:44
Copy link
Contributor

@jarmoza jarmoza left a comment

Choose a reason for hiding this comment

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

Looks good @surchs!

@surchs surchs merged commit 86bf385 into dev_components_talk_to_store_directly Dec 21, 2022
@surchs surchs deleted the surchs-255 branch December 21, 2022 17:01
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.

3 participants