-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
[WIP] Refactor catalog module #2890
Conversation
I think it's good step, right direction. The considerations:
|
I'll need add docs and info what's changed, but this can be reviewed. |
@patzick there is a check missing if the category is available in the offline mode - I can enter it and there is no even basic data like category title: https://www.dropbox.com/s/te3xe9fzl2bv2i9/Screenshot%202019-06-26%2022.07.23.png?dl=0 on demo - when you enter category that hasn't been visited before you get notification that this product is not availble in the offline mode + you can't just enter it. We should have some better sollution than this "broken" category page like it's right now |
Moreover, I see that currently we're not setting the category data into local cache ( UPDATE: What's pretty interesting even with the |
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.
It's really cool one! I had some questions regarding categoriesMap
(to make sure we won't duplicate data), categoryHierarchy
(if it's really needed) and mostly about the offline mode (caching/exception handling).
BUT I must admit it works perfectly well for most scenarios I've tested :D That's great, the code is very coherent - I like it.
getCategories: (state) => state.categories, | ||
getCategoryProducts: (state) => state.products, | ||
getAvailableFilters: state => state.availableFilters, | ||
calculateCurrentCategory: (state, getters, rootState) => (route) => { |
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'd say get
is easier to get :D
await dispatch('loadCategoryFilters', searchCategory) | ||
const searchQuery = getters.getCurrentFiltersFrom(route[products.routerFiltersSource]) | ||
let filterQr = buildFilterProductsQuery(searchCategory, searchQuery.filters) | ||
const searchResult = await quickSearchByQuery({ query: filterQr, sort: searchQuery.sort }) |
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'm not sure if'we re using the config.entites.products.includeFields
... as it was done with the progressive caching approach
: https://github.com/DivanteLtd/vue-storefront/blob/70543b3cfa379971220f6514348fe0386a108878/core/modules/catalog/store/category/actions.ts#L240
It seems like not. Moreover, we're not running these 2 calls with the doublecheck (if it gains the performance) as it was originally done. It should work exact the same way
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.
Moreover, the stock prefetching mechanism is also not ported to this refactored version: https://github.com/DivanteLtd/vue-storefront/blob/70543b3cfa379971220f6514348fe0386a108878/core/modules/catalog/store/category/actions.ts#L267
Without prefetching the stocks - when the config.products. filterUnavailableVariants
is set to true - it will take forever to fetch the stocks on demand on the product page
return 0 | ||
} | ||
|
||
export const _prepareCategoryHierarchyMap = (category: Category|ChildrenData) => { |
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'd suggest you to reconsider if this is really needed. Potentially it will be huuuge object (take wonect.com for an example) - building it, passing thru INITIAL_STATE - not sure if it makes sense. shouldn't we create this kind of mapping just for the current category (we do have category.path
which consist the ids of category accestors as far as I remember) (?)
@@ -0,0 +1,3 @@ | |||
export async function afterRegistration ({ Vue, config, store, isServer }) { | |||
if (isServer) await store.dispatch('category-next/_prepareCategoriesHierarchyMap') |
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 don't liek to have such a pre-caching mechanism for the whole category tree in the module init :(
} | ||
return filters | ||
}, | ||
getAvailableFilters: state => state.availableFilters, |
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 this interface :)
OK one more thing - we're not caching the products when browsing in the CSR ( |
@@ -0,0 +1,5 @@ | |||
import { CategoryService } from './CategoryService'; |
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.
set sideEffects: false for this in package.json
return 0 | ||
} | ||
|
||
export const _prepareCategoryPathIds = (category: Category): string[] => { |
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.
_ indicates private fn yet you export it, why?
import chunk from 'lodash-es/chunk' | ||
|
||
const actions: ActionTree<CategoryState, RootState> = { | ||
async loadCategoryProducts ({ commit, getters, dispatch, rootState }, { route, category } = {}) { |
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.
imho products should be cached by default. No additional work should be required to do this
Short description and why it's useful
This is WIP and should be for now treated as POC. PR created at early stage to show concept.
things to complete this PR
Additional TODO to complete this PR
Which environment this relates to
Check your case. In case of any doubts please read about Release Cycle
develop
branch and want to merge it back todevelop
release
branch and want to merge it back torelease
hotfix
ormaster
branch and want to merge it back tohotfix
Upgrade Notes and Changelog
IMPORTANT NOTICE - Remember to update
CHANGELOG.md
with description of your change