Skip to content
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

Open
wants to merge 13 commits into
base: 1.12
Choose a base branch
from

Conversation

vvasiloi
Copy link
Contributor

@vvasiloi vvasiloi commented May 17, 2020

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:

  • Tests
  • Deprecation of current logic, including constructor arguments
  • UPGRADE-*.md

@vvasiloi vvasiloi requested a review from a team as a code owner May 17, 2020 14:05
Copy link
Member

@lchrusciel lchrusciel left a 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

@vvasiloi
Copy link
Contributor Author

@lchrusciel any updates on this?

@lchrusciel
Copy link
Member

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?

@vvasiloi
Copy link
Contributor Author

vvasiloi commented Jun 17, 2020

@lchrusciel Thank you! There's one thing that I'm not sure how to do and I need help.
How do I deprecate passing of the 1st argument (the repository) and also deprecate not passing the second one (the resolver) without a BC break?
Considering that the 1st parameter's type and name must remain unchanged so it won't break service arguments auto-wiring.

@lchrusciel
Copy link
Member

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.

@stale
Copy link

stale bot commented Sep 20, 2020

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.

@stale stale bot added the Stale Issues and PRs with no recent activity, about to be closed soon. label Sep 20, 2020
@vvasiloi
Copy link
Contributor Author

Don't stale.

@stale stale bot removed the Stale Issues and PRs with no recent activity, about to be closed soon. label Sep 20, 2020
@lchrusciel lchrusciel added the Do not stale Important issues and PRs, that should not be stalled by Stale Bot label Sep 21, 2020
…thod in "sylius.shipping_method_resolver.default"
…od in "sylius.payment_method_resolver.default"
@vvasiloi
Copy link
Contributor Author

@lchrusciel can't believe that it's been more than a year since I opened this.
Time to get back to work.
Could you please take a look at it again?
I added a deprecation notice when passing the repository, a check for neither the repository nor the resolver is passed and the specs.


$paymentMethods = $this->paymentMethodRepository->findEnabledForChannel($channel);
if (empty($paymentMethods)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (empty($paymentMethods)) {
if (!$paymentMethods) {

Copy link
Contributor Author

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)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (empty($shippingMethods)) {
if (!$shippingMethods) {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jakubtobiasz
Copy link
Member

Hi @vvasiloi!
Any plans to continue work on it? PR is old, and we'd like to close it if there are no further plans to finish it :D.

@jakubtobiasz jakubtobiasz self-assigned this Feb 7, 2023
@vvasiloi
Copy link
Contributor Author

vvasiloi commented Feb 7, 2023

The question is what does it take for it to be finished?

@jakubtobiasz
Copy link
Member

jakubtobiasz commented Feb 7, 2023

@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.

@vvasiloi
Copy link
Contributor Author

vvasiloi commented Feb 7, 2023

Well, now I have to resolve the conflict, so yeah, it's WIP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Do not stale Important issues and PRs, that should not be stalled by Stale Bot
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants