Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

Approach 1:

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

    • 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

Technical availability/effort: to be analyzed

...