-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor Line Item Total Calculations #6080
Refactor Line Item Total Calculations #6080
Conversation
c3214bb
to
9a82ff7
Compare
Hey @jarednorman Do you think also #1837 could be tackled in #5872 . Think what you are doing here will also reduce testing time significantly which is also great. If not we would like to align with you and dedicate some resources to fix #1837 already on your new model. |
Ok, when you finished #5872 if you like @shahmayur001 can take a look at #1837 |
9a82ff7
to
15dac06
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #6080 +/- ##
==========================================
- Coverage 92.42% 88.70% -3.73%
==========================================
Files 389 830 +441
Lines 8005 17998 +9993
==========================================
+ Hits 7399 15965 +8566
- Misses 606 2033 +1427 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I really like that we make solidus more composable. Can we make this a configuration then to fulfil the goal completely?
While working on the in-memory updater in solidusio#5872, we found the need to change how item totals were being calculated, so that we could mark adjustments for destruction without actually destroying them, while still keeping tax adjustments intact. This change is completely backwards-compatible with the current OrderUpdater, so to reduce the scope of our PR, we wanted to make this change separately. Since the OrderUpdater is already very large, this helps reduce its responsibilities and makes it easier to test this behaviour. We don't see it as necessary to make this a configurable class, but this change leaves that option open in the future. Co-authored-by: Adam Mueller <[email protected]> Co-authored-by: Alistair Norman <[email protected]> Co-authored-by: Chris Todorov <[email protected]> Co-authored-by: Harmony Bouvier <[email protected]> Co-authored-by: Sofia Besenski <[email protected]> Co-authored-by: benjamin wil <[email protected]>
I don't know if there's all that much customizing people will perform on this class, but it's easy enough to make it configurable just in case.
15dac06
to
7a3bfc2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super good
@kennyadsl can we merge this, it seems to be universally approved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, just left a question, but I'm good with the PR as is. 🙏
Summary
This is related to #5872, but it is not a functional change. It refactors the existing order updater to use a class that we created for the in-memory order updater. The goal here is just to reduce the scope of that PR, though it's also a small design improvement.
Checklist
Check out our PR guidelines for more details.
The following are mandatory for all PRs:
The following are not always needed: