-
Notifications
You must be signed in to change notification settings - Fork 3
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
Deprecate existing coupon codes methods #19
Conversation
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.
Great job, left some comment about some possibile improvements.
Before this to be completed I think we should get rid of all the expect(Spree::Deprecation).to receive(:warn)
from feature specs. I'm thinking at the cart ones, there's no real replacement of this right now so maybe we need to implement a way to apply coupon code via API first, as it's done in the checkout.
What do you think?
@@ -20,6 +20,7 @@ module Spree::Api | |||
|
|||
it "can apply a coupon code to the order" do |
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.
this tests look like duplicated of what we have here, right? If yes, maybe we can do another PR to remove duplication?
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.
Noted 👌
4609d98
to
d27596f
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.
Left a comment, I think we are very close. Thanks!
Also, we can maybe squash some commits together? |
d68f38c
to
70b3f36
Compare
66eac4c
to
4559a00
Compare
Closing now that solidusio#2958 is merged into master |
Following @kennyadsl's idea on solidusio#2327, this PR aims to deprecate current endpoints used to apply coupon codes (on orders and checkout) and replace them with a new API controller/endpoint properly named
Spree::Api::CouponCodesController
.I think this approach allows a better separation of concerns and it's easier to reason about. Plus, it'd be easier to implement a built-in solution for solidusio#1641.
That said, we're still missing a
Spree::CouponCodesController
controller/endpoint under/frontend
but since we're already using API calls under said folder, I still debating whether to implement that or not.I'm open to suggestions!