-
Notifications
You must be signed in to change notification settings - Fork 10.8k
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 create attribute term modal #35131
Conversation
Test Results SummaryCommit SHA: 38dcbb3
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. |
8d5ce35
to
7420a10
Compare
80e7590
to
32001b9
Compare
getFilteredItems={ ( allItems, inputValue ) => { | ||
if ( | ||
inputValue.length > 0 && | ||
! allItems.find( |
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.
Just a note that this will fail if it returns an item that is falsy in any way, but it looks unlikely to cause any issues here.
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.
Yeah that should be fine, plus the find
method already assume the each item contains a name
attribute, so, so the item being return will have to contain a name
attribute none the less.
...merce-admin/client/products/fields/attribute-term-input-field/attribute-term-input-field.tsx
Outdated
Show resolved
Hide resolved
type CreateAttributeTermModalProps = { | ||
initialAttributeTermName: string; | ||
attributeId: number; | ||
onCancel: () => void; |
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'm wondering if there's a possible use case in which these handlers should be optional?
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 think so, but I made them optional just incase, I defaulted them to empty functions in this commit: 2f39f27
<TextControl | ||
label={ __( 'Name', 'woocommerce' ) } | ||
{ ...nameInputProps } | ||
onBlur={ () => { |
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 the onBlur
here fires, it actually closes both the terms modal and the add attribute modal, which I'd guess wouldn't be expected. Should we stop it from bubbling down to the add modal as well?
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.
Hmm could you maybe share a video of this? Things work as expected for me and the Modal doesn't auto close for me when the onBlur
is being fired.
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 @louwie17 !
Added a few very minor comments, and I also noticed that the fields are not responsive on smaller viewports, which might be worth addressing here.
It's also worth noting that we're definitely going to have some conflicts with the edit attributes PR which includes some semi-foundational changes, so we might want to get that merged before too long.
111c87c
to
2f39f27
Compare
Thanks for the feedback @joelclimbsthings I addressed most of your feedback, the only item I couldn't reproduce was the
Get which one merged first? |
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.
Right on, thanks @louwie17 ! I'm not sure if this behavior is actually much of a problem, but I can see it being annoying to users:
At the end of the animation I'm clicking at the spot I'm circling, and you can see that it's closing both modals, not just the terms modal.
Edit: Either way on merging the PRs. I'm good to resolve the conflicts for this one, but don't want the edit modal PR to get too bogged down with other changes coming down.
Aaaha thanks that video helps a lot, I should have a fix Monday morning sometime, it should be relatively simple to handle. |
2f39f27
to
38dcbb3
Compare
@joelclimbsthings I fixed the issue in this commit: 38dcbb3 Hope you have some time to look at it again. |
Awesome @louwie17 , works beautifully. 🚢 |
Hi @louwie17, thanks for merging this pull request. Please take a look at these follow-up tasks you may need to perform:
|
All Submissions:
Changes proposed in this Pull Request:
This allows users to create a new attribute term if the term they are searching for doesn't exist within the attribute term list.
This is currently dependent on #34999 to be merged, which is why it's pointing at that branch.
Kapture.2022-10-17.at.13.25.48.mp4
Address the term creation part in #34331 .
How to test the changes in this Pull Request:
new-product-management-experience
feature flag enabled (you can do so using the latest version of the Beta tester within the mono repo).localStorage.setItem( 'debug', 'wc-admin:*' );
run prior, it should show that aproduct_attribute_term_add
andproduct_attribute_term_add_success
event has been fired.Other information:
pnpm --filter=<project> run changelog add
?FOR PR REVIEWER ONLY: