You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This has some advantages, like give for granted the price and avoid making lot of resources traversing for complex cases but it also has cons, like forcing us to stub the line item price, when we need it to be something different from the default, as happening here.
We should understand if it's possible to make this price dynamic, based on the price of the variant associated with that line item. We should also deprecate the current line item factory, in order to allow backward compatibility for users that are relying on our core factories.
This discussion was converted from issue #3417 on September 07, 2022 09:00.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
At the moment, our line item factory has a static value as the default for its price, which is
BigDecimal('10.00')
.This has some advantages, like give for granted the price and avoid making lot of resources traversing for complex cases but it also has cons, like forcing us to stub the line item price, when we need it to be something different from the default, as happening here.
We should understand if it's possible to make this price dynamic, based on the price of the variant associated with that line item. We should also deprecate the current line item factory, in order to allow backward compatibility for users that are relying on our core factories.
Beta Was this translation helpful? Give feedback.
All reactions