Apply lazy-hydrate on category page

[andrzejewsky]

Related issues

closes #3327

Short description and why it's useful

This is a PoC of introducing lazy-hydrate for category pages. I had to face many issues with that. First of all the goal was to remove category-next.products from __INITIAL_STATE__ but it causes lack of reactivity in the vuex so the products field will not be refreshed. Second one - SSR rendering - the asyncData is calling before components were rendered and it stores the products in the vuex state that you have deleted beforehand.... and even more...

let me explain what I did and why:

1. In order to keep reactivity we can't just remove fields from the state - I've introduced filterInitialState which uses new option in the config initialStateFilterDefaults that includes fields that will be set to their default values I used new option because we might need a possibility to remove totally some field, so initialStateFilter still works as before.
2. Because we have deleted (set to default) products by the filter (initialStateFilterDefaults), so there is no data in the state but we actually have fetched products so... I stored them in the just ordinary variable ssrProducts and if it's a SSR, it uses this variable, otherwise - read the data from getter (computed property categoryProducts)

The rest of code should be understandable. I know it's a bit hacky not it does work. I've not noticed a big difference in the lighthouse, but I tested this only on the dev environment. I have to admit that it reduces page size by ~40-44% though.

Let me know guys what you think.

Which environment this relates to

• 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

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

[pkarw]

@patzick and @filrak take a look at this one. It’s probably our way to beat Lighthouse 👍

[pkarw]

We need to deal with ssrProducts local variable - remove it from Category.vue leve; otherwise it's cool

[filrak]

If I understand correctly

• initialStateFilter removes certain STORES from Vuex completely
• initialStateFilterDefaults sets certain FIELDS to their initial values, right?

I'm wondering if we could somehow merge this functionalities and always set defaults for fields in initialStateFilter. Amount of additional code will be barely noticeable and won't affect performance at all. in return we will cut off the complexity

[andrzejewsky]

@filrak

If I understand correctly

• initialStateFilter removes certain STORES from Vuex completely
• initialStateFilterDefaults sets certain FIELDS to their initial values, right?

Yeah this is how it works.

You are right, we can set always initial values instead of removing them. I did this in that way just because I wanted to avoid potential errors / BC-breaks, but I'll check that later.

[andrzejewsky]

Ok, I've spent some time on it and I even removed this local-variable-way hack @pkarw . Actually everything works via vuex (getters). It was possible because I've changed the way of the filtering __INITIAL_STATE__. Now, the state filter is calling just before the output render (sending to the client), so the SSR application is able to use fully vuex - beforehand it was a problem because sometimes we were removing the state fields when the application wanted to read something from the state (this is what I've noticed). Now, the initialStateFilter sets indicated fields to their default values (as you mentioned @filrak )

[pkarw]

OK, for me it's fine! we need some @alinadivante on QA + @patzick final approval

[pkarw]

@andrzejewsky just one more thing :-) can we enable this lazy loading feature only if config variable like: config.products..useLazyLoading?

[alinadivante]

I started testing it today, but I will continue on Friday. Just write here if any others changes will be applied and what I should take into account during testing :)

[andrzejewsky]

@pkarw I added option config.products.lazyLoadingCategoryProducts. It enables lazy-hydrate component and puts category-next.products to the filter list (because this option doesn't make sense without that filter)

[pkarw]

Cool, thanks! Waiting for @alinadivante feedback before we merge it in

[alinadivante]

for me it works good :)
I didn't notice anything wrong

[pkarw]

Ok! I’m merging it in

[pkarw]

So @andrzejewsky the next challenge will be to optimize the product page ;) but first @patzick must finish his refactoring effort on it

[pkarw]

Great job! Thanks!