Skip to content

Conversation

@mdperez86
Copy link
Contributor

@mdperez86 mdperez86 commented Oct 17, 2022

All Submissions:

Changes proposed in this Pull Request:

Closes #35036.

How to test the changes in this Pull Request:

  1. Go to the Add new product page
  2. Click on Shipping class dropdown field
  3. Select Add new shipping class option from the list
  4. From New shipping class modal form, add a new shipping class name then click Add button.
  5. When the modal closed the new shipping class added should be shown as the selected value of the Shipping class dropdown.

Screen.Recording.2022-10-17.at.2.20.11.PM.mov

Other information:

  • Have you added an explanation of what your changes do and why you'd like us to include them?
  • Have you written new tests for your changes, as applicable?
  • Have you successfully run tests with your changes locally?
  • Have you created a changelog file for each project being changed, ie pnpm --filter=<project> run changelog add?

FOR PR REVIEWER ONLY:

  • I have reviewed that everything is sanitized/escaped appropriately for any SQL or XSS injection possibilities. I made sure Linting is not ignored or disabled.

@mdperez86 mdperez86 requested a review from a team October 17, 2022 14:33
@github-actions github-actions bot added focus: react admin plugin: woocommerce Issues related to the WooCommerce Core plugin. labels Oct 17, 2022
@github-actions
Copy link
Contributor

github-actions bot commented Oct 17, 2022

Test Results Summary

Commit SHA: c32f0e5

Test 🧪Passed ✅Failed 🚨Broken 🚧Skipped ⏭️Unknown ❔Total 📊Duration ⏱️
API Tests18800201900m 43s
E2E Tests186003018915m 46s

To view the full API test report, click here.
To view the full E2E test report, click here.
To view all test reports, visit the WooCommerce Test Reports Dashboard.

@mdperez86 mdperez86 marked this pull request as ready for review October 17, 2022 17:29
@mdperez86 mdperez86 self-assigned this Oct 17, 2022
Copy link
Contributor

@joshuatf joshuatf left a comment

Choose a reason for hiding this comment

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

Hey @mdperez86, this looks great and is testing well!

Just left a quick suggestion on how we set the new shipping value.

// This should never be a real slug value of any existing shipping class
export const ADD_NEW_SHIPPING_CLASS_OPTION_VALUE =
'__ADD_NEW_SHIPPING_CLASS_OPTION__';
export const UNCATEGORIZED_CATEGORY_SLUG = 'uncategorized';
Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for moving these constants into here!

I know you're just moving this slug in here so I won't let it hold up this PR, but I'm wondering if this will function as expected since users can change the uncategorized slug and definitely may depending on locale.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, that's interesting! I'm wondering what is the logic WP is using to assign this category by default to any product if the user never select any category at all. If this is a variable thing then how do they deal with this? If you can enlighten me with that answer will be great for me, otherwise I think I should find the answer by myself.
Anyway this is a super great catch!

Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like the default category is stored in an option - get_option( 'default_product_cat', 0 ).

We should probably rely on that instead of the slug/name since those could be changed.

This is obviously unrelated to this PR though, so I don't want to block your work here. Would you mind creating a follow-up issue for this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Promise< ProductShippingClass >
>( values ).then( ( value ) => {
invalidateResolution( 'getProductShippingClasses' );
selectShippingClassProps?.onChange( value.slug );
Copy link
Contributor

Choose a reason for hiding this comment

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

Calling the onChange handler from the Form feels a tiny bit hacky to me and something I'd like to avoid if we can.

Would a call to setValue from the useFormContext work well here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's a matter of how it reads. But using setValue forces me to know the field name and duplicate it around the code. But I don't have a special oppinion for any of the two solutions.
I can change it by your suggestion.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done!

Copy link
Contributor

Choose a reason for hiding this comment

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

But using setValue forces me to know the field name and duplicate it around the code

Ya, that's a great point. I guess my main concern is that the intent of the onChange api is to handle changes coming from an input and not necessarily manual changes.

Luckily this handles both events and direct value changes so it works in the current scenario, but I do worry about breaking changes in the future.

Maybe we can introduce something like setValue from getInputProps that acts as a shortcut if we don't want to hold the name of input in a constant.

useDispatch: jest.fn(),
} ) );

describe( 'ProductShippingSection', () => {
Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for adding these tests ❤️

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Definitively!!!

@mdperez86 mdperez86 force-pushed the add/35036-select-created-class branch from bcc9424 to f6b18fc Compare October 18, 2022 13:20
@mdperez86 mdperez86 requested a review from joshuatf October 18, 2022 13:29
Copy link
Contributor

@joshuatf joshuatf left a comment

Choose a reason for hiding this comment

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

Code looks great and is testing well! Thanks, Maikel!

// This should never be a real slug value of any existing shipping class
export const ADD_NEW_SHIPPING_CLASS_OPTION_VALUE =
'__ADD_NEW_SHIPPING_CLASS_OPTION__';
export const UNCATEGORIZED_CATEGORY_SLUG = 'uncategorized';
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like the default category is stored in an option - get_option( 'default_product_cat', 0 ).

We should probably rely on that instead of the slug/name since those could be changed.

This is obviously unrelated to this PR though, so I don't want to block your work here. Would you mind creating a follow-up issue for this?

@mdperez86 mdperez86 merged commit a0b27a4 into trunk Oct 18, 2022
@mdperez86 mdperez86 deleted the add/35036-select-created-class branch October 18, 2022 18:40
@github-actions github-actions bot added this to the 7.2.0 milestone Oct 18, 2022
@github-actions
Copy link
Contributor

Hi @mdperez86, thanks for merging this pull request. Please take a look at these follow-up tasks you may need to perform:

  • Add the release: add testing instructions label

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

plugin: woocommerce Issues related to the WooCommerce Core plugin.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Shipping] Shipping class dropdown enhancement

3 participants