-
Notifications
You must be signed in to change notification settings - Fork 679
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
[PWA-272] [Feature]: "Edit Item" From Cart Page Kebab Menu #2191
Conversation
- Reuse product details from parent and render first half of modal content
- Update some option props so they don't submit my form - Drill down saving state and sync with mutations
style={finalStyle} | ||
title={label} | ||
type="button" |
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.
Swatch and tile were missing type="button" prop, and were triggering form submission on selection.
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 was wondering why you re-ordered the props, now I get it Alphabetical order.
Is that OCD or our standard? I ask because, I have OCD too 😆
|
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 did not review the changes completely. Heard you are refactoring the code. Try to think about my comments while doing that.
packages/peregrine/lib/talons/CartPage/ProductListing/EditModal/useEditModal.js
Outdated
Show resolved
Hide resolved
packages/peregrine/lib/talons/CartPage/ProductListing/EditModal/useEditModal.js
Outdated
Show resolved
Hide resolved
['OUT_OF_STOCK', 'Out of stock'] | ||
]); | ||
|
||
export const useProductDetail = props => { |
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.
Does this needs to be a talon? It looks like a props mapper instead.
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 would still consider destructuring or flattening of the graph logic, which I do want to contain in a talon. Open to extracting somewhere if you have a proposal.
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.
We don't have anything formally defined for such use cases but it looks like the mapStateToProps
we used to have in the olden golden days. Let's ask @jimbo
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 found a place where we have done something similar but it is in a peregine
talon. Not sure if we can just have the flatten/mapper functions in the component file.
const flattenProduct = item => { |
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.
Don't look at the git blame
😉 that was also me. The intention was once we started to see overlap, that could be broken out into a utility; but these components differ slightly.
packages/venia-ui/lib/components/CartPage/ProductListing/EditModal/editModal.css
Show resolved
Hide resolved
|
||
if (isLoading) { | ||
return ( | ||
<LoadingIndicator |
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 believe we can achieve some optimization by moving the loading indicator component instance to a useMemo
and returning the result if isLoading
. Since only 2 states exist for the component either loading or not potentially only creating 2 instances.
....
const loadingIndicator = useMemo(() => {
if (isLoading) {
return (
<LoadingIndicator
classes={{ root: classes.loading }}
>{`Fetching Product Options...`}</LoadingIndicator>
);
} else {
return null;
}
}, [isLoading, classes.loading]);
if (isLoading) { return loadingIndicator }
....
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 remember @jimbo left some comments on my PR about useMemo
. Don't do this yet. Let me check with Jimmy 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.
Very interested in this discussion. I have not been a huge fan of our overuse of useMemo
and useCallback
, so would be nice to define some usage criteria. Relevant article:
packages/venia-ui/lib/components/CartPage/ProductListing/EditModal/productForm.js
Show resolved
Hide resolved
packages/venia-ui/lib/components/CartPage/ProductListing/product.js
Outdated
Show resolved
Hide resolved
style={finalStyle} | ||
title={label} | ||
type="button" |
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 was wondering why you re-ordered the props, now I get it Alphabetical order.
Is that OCD or our standard? I ask because, I have OCD too 😆
- Write tests to cover all functionality
useAppContext: jest.fn() | ||
})); | ||
|
||
describe('return correct open status', () => { |
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 personally like using describe
but I remember I was asked not to use it unless there is no way and you want to mock/perform something for only certain tests. Check with @jimbo or other files.
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 did find other usages that use it to group tests, so I'm going to leave this for now.
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 couple of minor things. Let me know what you think about those.
return <i talonProps={talonProps} />; | ||
}; | ||
|
||
const configItemResponse = { |
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.
What do you think about moving this to __fixtures__/configResponses.js
?
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.
Moved in ec2be48
loading: false | ||
}; | ||
|
||
const cartItem = { |
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.
Even this guy to a __fixtures__
file.
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.
Moved in ec2be48
}); | ||
|
||
test('renders open drawer with active item', () => { | ||
const mockItem = { |
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.
Since thig guy is small, it can stay 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.
UX approved.
NOTE: there is some buggy-ness in that the option selection should reset (to the original config) if the edit drawer is closed without tapping the "Update" button.
Noted a minor issue with this PR on the new cart page. When trying to update the quantity when on the Cart page via the Mini Cart, the items are removed from the Cart page but not updated: Totals are also still the old value. |
@schensley Please check below observations related to UX.
|
Thank you @dpatil-magento for posting the comment.
Thnx. Scott |
- Ensure that item state is being cleared when the modal is closed
…udio into tommy/cart-page-edit-item
…ld not trigger a save
- Fixup tests after mainline merge
QA Pass, good to merge. @fooman Thanks for checking but Cart/Mini-Cart sync work is not done yet, so that issue is not addressed in scope of this PR. |
Description
As a shopper, I want to edit my product from within the cart page workflow in order to change configurable options (size, color, quantity, etc.) prior to purchasing.
Today, edit exists within the mini-cart experience but during the build out of the new Cart page we realized that reusing this same experience requires additional design. This is a follow up story to PWA-238.
Need to decide on design treatment for edit item experience within the full cart.
Related Issue
Acceptance
Verification Stakeholders
Specification
Verification Steps
/cart
pageScreenshots / Screen Captures (if appropriate)
Checklist