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
[WIP] Default shipping and payment method resolver #11482
base: 1.12
Are you sure you want to change the base?
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.
Hey Victor!
thanks for your contribution.
I would say, we are fine with specs only. Another possibility is to write more complicated functional tests, but it may be tricky, as we will need to wire it up manually. /cc @Sylius/core-team
src/Sylius/Component/Core/Resolver/EligibleDefaultShippingMethodResolver.php
Outdated
Show resolved
Hide resolved
src/Sylius/Component/Core/Resolver/EligibleDefaultShippingMethodResolver.php
Outdated
Show resolved
Hide resolved
@lchrusciel any updates on this? |
Let's go with this PR as it is, without splitting. Looking right now at the code, specs are a must. Here we need to cover at least changes to the logic. Also, we could easily test that some argument is not needed. From a high-level perspective, we could add one scenario for each case, where the resolver will return different objects than the current solution. If you have an idea for PHPUnit(which I mentioned previously) go for it, but it would just skip this part. This is a nice addition, and I would like to merge it. Is there anything else I can help you with to push it forward? |
@lchrusciel Thank you! There's one thing that I'm not sure how to do and I need help. |
I missed this case, and to be sure I wasn't aware about issue you've raised. However, I cannot see too many possibilities other than just message, that only the second argument can be passed and it will become the first one. I'm considering also, that maybe some bind option could provide backward compatibility in case you raised. Then, we can remove typehint from the constructor, inject new service, bind this argument for autowiring and then in code just handle different behavior depending on injected service. |
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions. |
Don't stale. |
…thod in "sylius.shipping_method_resolver.default"
…od in "sylius.payment_method_resolver.default"
5fcaff3
to
b5e1a7d
Compare
add spec for the check
@lchrusciel can't believe that it's been more than a year since I opened this. |
src/Sylius/Component/Core/Resolver/DefaultPaymentMethodResolver.php
Outdated
Show resolved
Hide resolved
|
||
$paymentMethods = $this->paymentMethodRepository->findEnabledForChannel($channel); | ||
if (empty($paymentMethods)) { |
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.
if (empty($paymentMethods)) { | |
if (!$paymentMethods) { |
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.
Maybe count($paymentMethods) === 0
?
Or use reset($paymentMethods)
and check if it's false
instead of relying on the numeric index ($paymentMethods[0]
).
{ | ||
$shippingMethods = $this->shippingMethodsResolver->getSupportedMethods($shipment); | ||
|
||
if (empty($shippingMethods)) { |
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.
if (empty($shippingMethods)) { | |
if (!$shippingMethods) { |
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.
add spec for the check
Hi @vvasiloi! |
The question is what does it take for it to be finished? |
@vvasiloi I dunno, you're the author 😂. I see there's a WIP in the title that's why I'm asking :D. Also there're conflicts. |
Well, now I have to resolve the conflict, so yeah, it's WIP. |
Default shipping method resolver and default payment method resolver should use the corresponding collection resolver to get available methods to choose from.
Right now the logic is duplicated and in case a custom collection resolver uses a different logic it might happen that the default resolver will return a method which is not available.
Need suggestions for tests and on how to deprecate the current logic, especially the constructor arguments. Also, should I split it 2 PRs?
TODO: