-
Notifications
You must be signed in to change notification settings - Fork 10.7k
Add product management SKU #34978
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
Add product management SKU #34978
Conversation
Test Results SummaryCommit SHA: 91ef513
Please address the following issues prior to merging this pull request: |
plugins/woocommerce-admin/client/products/product-validation.ts
Outdated
Show resolved
Hide resolved
plugins/woocommerce-admin/client/products/sections/product-details-section.tsx
Show resolved
Hide resolved
|
Thanks for the review, Maikel! This PR is ready for another look when you have time. |
mattsherman
left a comment
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.
Nice work on this so far, @joshuatf !
My comments mainly revolve around validation.
I totally missed that we were proposing changing the validation rules for SKU in the original issue. I don't think we should do so, since it will introduce compatibility issues with products added via other means (existing UI, API). /cc @pmcpinto @jarekmorawski
plugins/woocommerce-admin/client/products/product-validation.ts
Outdated
Show resolved
Hide resolved
plugins/woocommerce-admin/client/products/product-validation.ts
Outdated
Show resolved
Hide resolved
plugins/woocommerce-admin/client/products/product-validation.ts
Outdated
Show resolved
Hide resolved
plugins/woocommerce-admin/client/products/sections/product-details-section.tsx
Show resolved
Hide resolved
plugins/woocommerce-admin/client/products/sections/product-details-section.tsx
Show resolved
Hide resolved
plugins/woocommerce-admin/client/products/sections/test/utils.ts
Outdated
Show resolved
Hide resolved
plugins/woocommerce-admin/client/products/sections/test/utils.ts
Outdated
Show resolved
Hide resolved
plugins/woocommerce-admin/client/products/product-validation.ts
Outdated
Show resolved
Hide resolved
Good point. I agree with @mattsherman assessment. IMO the benefits of this change don't outweigh the associated risks |
|
@mattsherman @mdperez86 This PR has been updated to remove any validation/sanitization logic around SKUs. I addressed a couple of @mattsherman's feedback requests, though a follow-up to improve form context callbacks may be a nice addition in the future. |
mattsherman
left a comment
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 for trying to improve the onBlur handling, @joshuatf! Unfortunately, I believe that your original implementation, while coupling the different UI sections less-than-ideally, functioned better. I left a comment suggesting we either go back to that implementation or change to an implementation where the SKU is updated on-the-fly as the name field changes.
| }; | ||
|
|
||
| const isNameBlurred = ! prevTouchedName && touched.name; | ||
| useEffect( setSkuIfEmpty, [ isNameBlurred ] ); |
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 does not handle the scenario where the user:
- Focuses on empty name field
- Blurs to another field (without first entering anything in name field)
- Focuses on empty name field
- Enters name
- Blurs to another field
Perhaps it would be better to go back to our original implementation, which tied to the onBlur of the field itself. I don't love that, since it couples the two UI implementations more than ideal, but it does work better.
Perhaps the more ideal solution needs to be addressed in the future. Maybe we need a way to hook into focus change at the Form level, so we (and extensions) could hook into whether the focus changed from one component to another at the Form level.
Or, if you changed the implementation to always update the SKU on the fly as the name value changed, keystroke by keystroke, as long as it was a new product and the user hadn't manually modified the SKU. That would be pretty slick, as long as it wasn't a performance issue.
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 was definitely a hacky solution at best. I agree with moving back to the onBlur. I'll open an issue to introduce a state handler to form context so we can detect various state changes to the form outside of specific components.
I've reverted this in 60da981
| target="_blank" | ||
| type="wp-admin" | ||
| onClick={ () => { | ||
| recordEvent( 'add_product_inventory_help' ); |
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.
I don't love clean up issues, but perhaps it would be best to address Tracks naming across the board in a follow up clean up issue, so we can get this functionality merged to unblock further MVP work.
As you mention, you were just following existing naming conventions on the new product experience. And, those existing conventions are not in line with best practices/guidelines. /cc @AnnaMag @pmcpinto
plugins/woocommerce-admin/client/products/sections/product-details-section.tsx
Show resolved
Hide resolved
|
Thanks for the review @mattsherman! I reverted the to the original |
mattsherman
left a comment
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.
Nice work on this @joshuatf ! LGTM!
I have tested the latest, and it works as expected, with one ambiguous case. The original acceptance criteria didn't detail this, and I can see reasoning behind either behavior, so I'm going to approve this and we can follow up with a future issue if need be...
Scenario:
- User enters in a name (SKU updates automatically)
- User clears the SKU
- User modifies the name (SKU updates automatically)
It is unclear to me what the "best" behavior is in this scenario... should the SKU stay blank because the user manually cleared it, or should it be auto-filled in, since it was blank? It's easy to clear out the SKU again, so I think that how you have it implemented is the preferred way, but it did not meet my expectations when testing, so I'm raising it for discussion.
/cc @jarekmorawski
|
@joshuatf Btw... I see the failing "Run tests against PR / Runs E2E tests", but the failures appear completely unrelated, so I think it is safe to bypass branch protections. |
|
Thanks for the quick review, @mattsherman!
I think so as well. Worst case scenario, are there any detrimental effects to having a SKU filled in? Or reasons a user might want a blank SKU? @jarekmorawski if you have an opinion on this, please let us know and we'll follow up with another issue. |
mattsherman
left a comment
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.
Changes still look good to me.
|
Hi @joshuatf, thanks for merging this pull request. Please take a look at these follow-up tasks you may need to perform:
|
I don't think so. I'd go further and say that it's only beneficial since both WooCommerce and many inventory management systems that the merchants use treat the SKU as a product UID. It's perfectly fine to have it filled in again when the name changes. |
All Submissions:
Changes proposed in this Pull Request:
Adds the SKU field and inventory section to the new product management experience.
Closes #34386 .



How to test the changes in this Pull Request:
Products -> Add new (MVP)Other information:
pnpm --filter=<project> run changelog add?FOR PR REVIEWER ONLY: