-
Notifications
You must be signed in to change notification settings - Fork 682
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
New MiniCart #2494
New MiniCart #2494
Conversation
desktop vs mobile
to toggle the cart drawer
|
Performance Test Results The following fails have been reported by WebpageTest. These numbers indicates a possible performance issue with the PR which requires further manual testing to validate. https://pr-2494.pwa-venia.com : LH Performance Expected 0.85 Actual 0.52, LH Best Practices Expected 1 Actual 0.92, WPT Cache Expected 90 Actual 83.333333333333 |
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 some comments - not a formal review.
…dio into supernova/600_minicartv2
PR Updated:
|
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.
Reviewed!
|
||
const [getItemCount, { data }] = useLazyQuery(getItemCountQuery, { | ||
fetchPolicy: 'cache-and-network' | ||
}); | ||
const [fetchCartId] = useMutation(createCartMutation); | ||
const fetchCartDetails = useAwaitQuery(getCartDetailsQuery); | ||
|
||
const [miniCartIsOpen, setMiniCartIsOpen] = useState(false); |
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 we gain from using local state? I think we can still get away with using toggleDrawer
. You could even just call it cart-2
for now and in the new mini cart talon we would just check for drawer === 'cart-2'
instead of threading the isOpen
prop around.
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.
toggleDrawer
is app-wide / global state and originally designed so that only one drawer was open at a time. Dialog
introduced the concept of these components doing their own masking (as opposed to the app itself having to do it), so I was running with that.
Basically, I am intentionally trying to bring the state local here - aren't we trying to get away from the site-wide contexts (useAppContext::toggleDrawer
)?
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.
Basically, I am intentionally trying to bring the state local here - aren't we trying to get away from the site-wide contexts (useAppContext::toggleDrawer)?
We're avoiding global state for things that aren't global state. If the new mocks call for multiple drawers being opened at once then this would no longer fit into the old drawer pattern. So that's fine.
} | ||
|
||
.body { | ||
margin-top: 1rem; |
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.
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 switched to a grid gap
in 9e3683b. There's still that whitespace but at least it is consistent on the top and bottom now. You're right, I'm not sure what to do about this.
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.
Resolved by 2ae1589. It uses padding
now instead, which allows the contents to scroll into the whitespace.
@@ -0,0 +1,13 @@ | |||
import { useCallback } from 'react'; | |||
|
|||
export const useMiniCart2 = 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.
I think we should come up with a real name for this component.
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.
Current proposal is ShoppingBag
, which is also a term we can begin to use in place of "minicart" more generally.
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.
Updated to ShoppingBag
in 6524bd7.
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.
Renamed to MiniCart
in 535485c.
@@ -1,9 +1,29 @@ | |||
.root { | |||
.root_desktop { |
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.
Generally, we use the .root
classname for the component's root element. Here, the root is a fragment, so we wouldn't really have a root.
We also generally use the x_y
format to indicate that y
is one state of x
. Here, root_desktop
and root_mobile
are sibling elements, so we should probably not use that format here. Further, desktop
and mobile
don't really get at the heart of the distinction here, so perhaps trigger
(desktop, triggers a dropdown) and link
(mobile, links to a new page) would distinguish the two elements better.
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.
Resolved by 29cb5be.
display: none; | ||
} | ||
|
||
.background { |
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've had a few conversations about this in Slack, but I'd like to avoid creating (and naming) elements just for presentational quirks. In this case, since I anticipated this situation, I've been pushing back against the design calling for a background on the trigger. Can we find a different way to highlight the trigger when the dropdown is active?
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 is still outstanding pending an alternate approach / design.
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.
Resolved with a new design in f13d4fe.
} | ||
|
||
.mask { | ||
/* The mask takes up the entire screen. */ |
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 the design calls for the mask to obscure the body but not the header. This is a slightly complicated requirement, since shadow interactions start to matter.
Also, keep in mind that clicking the header—or the trigger a second time—must close the dropdown if it's open. The implementation here (clicking on the mask) relies on the mask overlaying the header, so it may need a new approach.
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.
Eeesh, yeah good call. This is outstanding pending an alternate approach / design.
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.
Resolved with the new design in f13d4fe. There is no mask anymore.
} | ||
|
||
.footer { | ||
border-top: solid 0.4rem rgb(var(--venia-grey)); |
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.
Recall that we try to aim for integer pixel values when using rem
units. Here, though, I'd like to stick to a 2px
border; the design's thick border here seems inconsistent with the rest of our design.
border-top: solid 0.4rem rgb(var(--venia-grey)); | |
border-top: 2px solid rgb(var(--venia-grey)); |
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.
Resolved in 18d615e.
box-shadow: 1px 1px 5px rgb(var(--venia-grey-darker)); | ||
display: grid; | ||
/* The header and footer heights may change based on PWA-116 and PWA-601. */ | ||
grid-template-rows: 2rem 1fr 8rem; |
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.
It seems more likely that the final row's height should depend on its content. If there's a minimum height, try minmax()
.
grid-template-rows: 2rem 1fr 8rem; | |
grid-template-rows: 2rem 1fr minmax(2rem, auto); |
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. Resolved in 18d615e.
} | ||
|
||
.contents { | ||
align-content: space-between; |
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.
Generally, at least in this app, we try to avoid space-between
, since it results in variable gaps.
Whenever you have a situation where the allocation of space isn't fixed, you'll have to decide whether the tracks or the gaps will be fixed in size, while the other is variable; here, we prefer fixed gaps (gap
) and variable tracks.
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 didn't need this after all anyway - the body track is sized at 1fr
so there was no space to allocate in the first place. Removed and replaced with gap
in 9e3683b.
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! I did notice that on mobile the cart trigger appears on the cart/checkout pages but doesn't do anything. Might be worth removing in those cases.
I ran this by UX: consensus is it's like clicking the VENIA logo while you're on the homepage. It won't do anything but we don't want to remove it. |
<span className={classes.counter}>{itemCountDisplay}</span> | ||
) : null; | ||
const maybeMiniCartOpenIndicator = miniCartIsOpen ? ( | ||
<div className={classes.openIndicator} /> | ||
) : null; |
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 normally do presentational elements; ordinarily this would be a border or shadow on the button. Did you have a motive for this approach?
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.
Oops, didn't think it through - I'll change this
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.
Resolved by a4cf8a0.
Thanks for going through, renaming everything, and fixing the tests. Hopefully this naming will stick. 👍 |
…dio into supernova/600_minicartv2
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.
Looks good to me. I may do some layout cleanup around the header in a separate PR, but this is good for now. 👍
@supernova-at Some conflicts to resolve and an observation on desktop >> while opening/closing mini cart, page shifts a bit to accommodate scroll bar. This might be exists on |
PR Updated:
I cannot reproduce this, even though I can clearly see it happening in your image. What browser are you using here? |
…dio into supernova/600_minicartv2
@supernova-at it happens on Chrome for me but also on dev: |
@supernova-at as discussed, I have created bug https://jira.corp.magento.com/browse/PWA-735 in backlog. Issue is in Chrome and Safari, Firefox works fine. |
Description
This PR introduces a skeleton for the new
MiniCart
.The new
MiniCart
's display is controlled by theCartTrigger
button in the site header.On Desktop, the
CartTrigger
will show this newMiniCart
.On mobile, the
CartTrigger
will take the user directly to the Cart page.Once the
MiniCart
is visible, clicking anywhere outside of it will dismiss it.It also:
MiniCart
toLegacyMiniCart
Venia
categoryFollow up tasks in the new MiniCart epic will implement this component's actual functionality.
Related Issue
Closes PWA-600.
Acceptance
Verification Stakeholders
@jimbo
Specification
Verification Steps
On Desktop
On Mobile
In Storybook
yarn workspace @magento/venia-ui run storybook
Screenshots / Screen Captures (if appropriate)
Checklist