Bugfix/2918

[pkarw]

Related issues

closes #2918, #3050, #3099

Short description and why it's useful

I've fixed the naming convention of the prices field, got final_price to be used in price calculations + removed all the Vue.prototype.* references introducing the new object StorageManager

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

[pkarw]

I've fixed the unit tests + merged the develop in

[pkarw]

• TODO: Check the MP02 - Caesar pants - why the MP02-32-Gray is not setting the special_price in the main product
• TODO: Add finalPriceIncludeTax parameter to the updateProductPrice function call - as it might be separate setting than sourcePriceIncludeTax

[pkarw]

• TODO: To take care of the actions.spec.ts for the unit/cart/store as some of the tests generate warnings after new getters got introduced + basically needs to be refactored to keep up with the curent state of the cart module

[pkarw]

QA: In order to test this feature please do update vue-storefront-api on your local machine to the PR: vuestorefront/vue-storefront-api#289

In this PR I've changed the price fields naming + changed the way localStorage got operated. I've also added the support for the final_price field which was missing before. Features that needed to be tested out:

• catalog promotion rules should got applied after product indexation (before hand they were' not - only product special_prices which is a different use case)
• need to check the total prices in the cart,
• order placing mechanism uses queues in the localStorage - we need to check it out if it still works just fine,
• offline mode also uses localStorage for caching so let's try it out as well
• all the other features which base on product or cart prices needed to be double-checked (for example bundle products)
• the dynamic pricing alwaysSyncPlatformPricesOver feature that syncs the prices with Magento backedn

[patzick]

Looks good to me. Is it still WIP?

I have points only for storage-manager.ts i'd like you to address to:

1. I'd change register method to set or add
2. To what is currentStoreCode used for inside?
3. We should have some kind of storage map inside which holds the keys, otherwise someone could register get collection and override out get
4. What about second registration? I'm afraid of potential memory leaks - maybe for safety check if is already registered and delete it before or not register new one?
5. Why is get registering new storage if not exists? Shouldn't just return null? Why we need exists function then if get always returns collection? I believe there are reasons for that so this is a question to clarify :)

[pkarw]

1. I'd change register method to set or add

Done!

2. To what is currentStoreCode used for inside?

It's for discovering the changes (https://github.com/DivanteLtd/vue-storefront/blob/3d1d81c0e1aebfcdeda97ea7fec58b6d3ab8ef29/core/lib/multistore.ts#L103) as UniversalStorage's are related to the currentStoreView by the prefix

3. We should have some kind of storage map inside which holds the keys, otherwise someone could register get collection and override out get

Well, the object itself is kind of hash - this[collectionName] so i thoutght it's safe

4. What about second registration? I'm afraid of potential memory leaks - maybe for safety check if is already registered and delete it before or not register new one?

I think it's safe - as the set (formerly register) just sets the property so when it's changed the reference counter got decreased and then removed so I'm not sure if the memory leak is a true danger in here?

5. Why is get registering new storage if not exists? Shouldn't just return null? Why we need exists function then if get always returns collection? I believe there are reasons for that so this is a question to clarify :)

It's for those who miss the point storage needs to be registered :) There was no risk of having sucha a safe fallbsack