#3286 + #3332 catalog-next module improvements

[cewald]

Related issues

closes #3286 and #3332

Short description and why it's useful

I added a new state item, containing the current category id, to be able to traverse the current category even if the current route path is not the same as in url_path nor slug (e.g. if you use rewrites). I decided to use just the id in currentId state property to prevent duplicate content in the state, because the category is already in categoriesMap.

Also I changed how the filter for the category is added to the action in the category page. This way you don't need to ask for config.products.useMagentoUrlKeys and use just the given parameters of the current route. This is more specific and also more flexible than just get it by the path.

And I fixed the bug mentioned in #3286 where it sometimes returns the wrong category because of the flacky include()-search in the getCategoryFrom() getter.

Which environment this relates to

Check your case. In case of any doubts please read about Release Cycle

• Test version (https://test.storefrontcloud.io) - this is a new feature or improvement for Vue Storefront. I've created branch from develop branch and want to merge it back to develop
• RC version (https://next.storefrontcloud.io) - this is a stabilisation fix for Release Candidate of Vue Storefront. I've created branch from release branch and want to merge it back to release
• Stable version (https://demo.storefrontcloud.io) - this is an important fix for current stable version. I've created branch from hotfix or master branch and want to merge it back to hotfix

Upgrade Notes and Changelog

• No upgrade steps required (100% backward compatibility and no breaking changes)
• I've updated the Upgrade notes and Changelog on how to port existing VS sites with this new feature

IMPORTANT NOTICE - Remember to update CHANGELOG.md with description of your change

Contribution and currently important rules acceptance

• I read and followed contribution rules
• I read the TypeScript Action Plan and adjusted my PR according to it
• I read about Vue Storefront Modules and I am aware that every new feature should be a module

[lukeromanowicz]

Looks good, awesome job 👍

[patzick]

Thanks @cewald, i think it's better to improve category match pattern instead of extending state to store categoryId. Removing it was a purpose to have single source of truth in url without need to set it maunually.
Let's hold this one to rethink it :)

[cewald]

@patzick I totally like this approach of having a "true" single source of truth, thats why I just added the ID instead of a own category object, but yes indeed it would be better to get that without a extra state entry. But how is it then possible to see if this url-key is probably connected to a custom route if I don't use the url-key in category-state?

For example I added a route like via a custom url mappingFallback() rule like:

{
  "name": "category",
  "params": {
    "slug": "new"
  }
}

A use-case for that is to have custom url's for a specific standard route. For example: our marketing want's an url that isn't conform with our default url-category pattern but then again sounds better in communication.

[cewald]

@patzick I updated my pull request as you said. I found a way to traverse the current url in a better way without the need of an extra current category state. I was able to get the current category in a more specific way than using url-key, by using the route.params (like in URL mapping). This way it's possible to have any url-key you want and still find the current category by it's original url-key from route.params.

I put it into a new method so we still have both ways – there are use-cases when it's enough to look just after the url-key.

[pkarw]

@cewald is this one ready to be merged in?

[pkarw]

awesome job by the way @cewald :-)

[pkarw]

Just a very very small change suggested; overall: great job

[pkarw]

Thasnk

[patzick]

i'll only change that back for one reason - with every category vue will mutate state and will invoke recalculate all computed properties and getters which are based on this. Fix for reactivity here is actually change
state.categoriesMap = Object.assign(state.categoriesMap, newCategoriesEntry)
to
state.categoriesMap = Object.assign({}, state.categoriesMap, newCategoriesEntry)

[cewald]

Ah nice, didn't figured that out :)

[patzick]

Great work @cewald , i'll only change back CATEGORY_ADD_CATEGORIES to invoke state mutation once, but overall really great job! :)