...

• Scalable and is a generic solution.

Disadvantages:

• We still have 2 items (one for free and other for the paid) as before

• If we have more than one offer active we’ll have multiples items as before

Technical availability/effort: to be analyzed0.5 sprint

...

...

Option 5: have only one item as the original proposal

...

Update related to the initial idea: the “quantity based PLU” will not resolve our problems. When this field is used the user needs to fill all the desired quantities. In our case, the paid/free item can have an “infinite” quantity (based on the combination) and this is broken for our solution and will not work or solve the client's desire for improvement. With that in mind, I (Vinicius) have an idea to variate the constantPLU information on the FE side to see if this can solve the problem without touching the backend and the mentioned “quantity based PLU” and I’m doing a POC to validate this.

Solution proposal

As we don't have an implementation that allows us to deal with a single item that can have free or paid value depending on the quantity the main idea of the solution is to variate/change the PLU that will be used to calculate the value of an item. This will bring us back to the original Figma proposal

How the item was in the “Your cart” section:

...

What the cart item will look like after this solution:

...

Obs: of course we’ll not need the “Ketchup Sachet Free” in the name… this could be just “Ketchup sachet” showing the description about the quantity of free items that we have for this offer. We’ll also hide the edit button as we not need this button for our free item feature.

We’ll also not need anymore the “Add extras” modal to change the items quantity because we can change this directly with this proposal:

...

Approach:

The main idea of this approach is to change the free item behavior with a low impact on the existent feature:

• Create a new hook with a function that will return the correct PLU (free or paid)

• Adjust the use-pricing-function hook

  • Call the new hook

  • Adjust pricingFunctionNoSelections and call the function returned from the new hook inside the condition that checks if the pluType is a constant. The function will return the correct PLU to be passed inside `getPriceForPlus`

    • We’ll also need to adjust the itemQuantity variable or the return. We can have a function that will return the correct quantity to be multiplied based on the offer

      • If the item quantity is less than the actual offer use the quantity from the item. If not we’ll use the item quantity minus the actual maximum offered

  • Perhaps we’ll need to adjust other functions too… need to analyze the full impact of this

• Adjust the cart page (src/pages/cart/index.tsx) cartEntries `updatedCartEntries` return to also have the logic to use the free or the paid PLU

  • This is important because this array will be sent to the priceOrder query and we can’t charge for the free ones for example

  • We’ll need to find inside this array the offered item (we can use the new hook created above for that)

  • If we find the item we’ll need to adjust the vendorConfigsproperty to change the PLU (paid or free based on the max offer counter logic)

• Adjust the addons-item-container

  • Remove the logic that will show the paid item as now we’ll have only one item

  • Use the same method used in the upsell component to add the item to the cart. We’ll not need the hook from the addOns feature anymore

    • Adjust the cart-item buttons + and - to be disabled based in the rules of the free item feature

    • Hide the “edit” button. This button will not be used for our free item feature

  • Analyze and adjust the useAddOnsItemContainer to not look at the paid item anymore. Here we can remove or reuse what’s needed

  • Now when the free item is added to the cart we’ll not need the modal for the edition anymore

• Remove unnecessary logic and code from the addOn feature

• We’ll not touch on Sanity now and this will happen in the next changes/improvements

• Advantages of this approach:

  • Change the use-pricing-function will make all this work correctly even in the cart-preview for example

  • Low-impact development for an initial improvement

  • No need to touch on BE or other integrations

• Disadvantages of this approach:

  • Changing the PLU on a logic hide in the FE code (this will not be a clear config like the vendor config for example) in this first version of the improvement. This will be improved when we change the Sanity part in the future

  • Without the addOn feature and using the cart-item as it is (with the + and - buttons) the page will suffer from re-render when we change the item quantity. Using the addOn feature the state was isolated inside the “Add extras” modal

• Challenge: how do we show the free item quantity on the receipt?

  • Some thoughts of the author (Vinicius):

    • Option 1: have a “hide” item on the cart entries to be the one representing the free item quantity (this can be made on the (src/pages/cart/index.tsx) cartEntries). Perhaps we’ll need to change the component that show the “Your cart” information to hide the item there too

    • Option 2: analyze and discover how we can add items to the receipt without touching the cart entries

POC: https://github.com/rbilabs/intl-whitelabel-app/tree/iberia-dedicated-items-free-improvement-poc

Files changed in the POC above:

• Cart page: frontend/src/pages/cart/index.tsx

• Addons items container: frontend/src/pages/cart/addons-item-container/addons-item-container.tsx

• useAddonsItemContainer: frontend/src/pages/cart/addons-item-container/hook/use-addons-item-container.ts

• usePrincingFunction: frontend/src/state/menu-options/hooks/use-pricing-function.ts

Technical availability/effort: to be analyzed1/1.5 sprint

...

Sanity changes

In the last meetings we discover that Iberia thinks that the UX in Sanity is complicated and we have to change different documents to have the feature working properly. They want to know if we can improve this part of the feature.

...