-
Notifications
You must be signed in to change notification settings - Fork 685
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-989: Real Data Wishlists and Wishlist Create #3041
PWA-989: Real Data Wishlists and Wishlist Create #3041
Conversation
|
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.
Some minor signature improvements to future proof, but overall looks great. I did run into an issue now that this is hooked up to live data.
If you create a brand new Customer, it appears the first wishlist is not automatically created via GraphQL, so the /wishlist
page hangs. Likely an existing bug where some assumptions were made with mocked data that aren't correct. It does appear Luma will automatically create your first list for you, so we'll need to check with product if that's something Venia should do as well, or just render the page with no lists.
packages/peregrine/lib/talons/WishlistPage/createWishlist.gql.js
Outdated
Show resolved
Hide resolved
packages/peregrine/lib/talons/WishlistPage/useCreateWishlist.js
Outdated
Show resolved
Hide resolved
packages/peregrine/lib/talons/WishlistPage/useCreateWishlist.js
Outdated
Show resolved
Hide resolved
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.
Clarified some points about refetch logic, this is real close. Ping me on Slack if you have any questions.
variables: { | ||
input: data | ||
}, | ||
refetchQueries: [{ query: getCustomerWishlistsQuery }], |
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 implementation, wrong query 😄 this ended up adding another network round trip. Here's a screenshot of network requests with that mutation, which additionally showcases why we should be giving operations unique names as well.
This will be a little more involved, but totally worth it.
- Migrate
wishlistPage.gql.js
to Peregrine. UpdateuseWishlistPage
talon to use thedefaultOperations
merge pattern. import { GET_CUSTOMER_WISHLIST } from './wishlistPage.gql'
- Use that query here
- Remove
GET_CUSTOMER_WISHLISTS
fromcreateWishlist.gql.js
- Additionally, you can scale down the response of
CREATE_WISHLIST
to justid
, since we expect to refetch here anyway
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.
Have not checked network(. Corrected it.
Thank you
const visibilityLabel = | ||
visibility === 'PUBLIC' | ||
? formatMessage({ | ||
id: 'wishlist.publicText', | ||
defaultMessage: 'Public' | ||
}) | ||
: formatMessage({ | ||
id: 'wishlist.privateText', | ||
defaultMessage: 'Private' | ||
}); |
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.
Should we use the globals here instead?
const visibilityLabel = | |
visibility === 'PUBLIC' | |
? formatMessage({ | |
id: 'wishlist.publicText', | |
defaultMessage: 'Public' | |
}) | |
: formatMessage({ | |
id: 'wishlist.privateText', | |
defaultMessage: 'Private' | |
}); | |
const visibilityLabel = | |
visibility === 'PUBLIC' | |
? formatMessage({ | |
id: 'global.public', | |
defaultMessage: 'Public' | |
}) | |
: formatMessage({ | |
id: 'global.private', | |
defaultMessage: 'Private' | |
}); |
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.
Yes it makes sense for this phrase "global", and these global phrases already used in other wishlist component)
Fixed.
Thank you
|
||
return root.findByType('i').props.talonProps; | ||
}; | ||
const createWishlistMock = { |
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.
How do you test the loading state of this mutation? I'm trying to do this in my PR but I'm having trouble...
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.
Nvm, found it :D Just don't await
the act'ed click.
Thanks @eug123 those 2 fixes looks good. Please check following -
Don't think we need to extend the scope of this PR, First issue is something I believe needs a fix but on other 3 observations lets Demo to @tkacheva and create a follow up story around admin configs if needed. |
@dpatil-magento, Thank you |
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.
Let's simplify the new utility as much we can, but otherwise the rest looks good 👍 ping me if you have questions.
* | ||
* @param {ApolloClient} client | ||
*/ | ||
export const clearWishlistDataFromCache = async client => { |
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 not sure about another utility function here, since I would consider wishlist part of customer data. Fine to keep this, but would be better to have clearCustomerDataFromCache
call it.
Alternatively, there is a data security pattern we might want to establish. The clearCustomerDataFromCache
will clear entities that start with Customer
and I think we've just gotten lucky so far that they followed this pattern. You could instead define keyFields
for Wishlist and WishlistItem, and this extra utility function wouldn't be needed.
Wishlist: {
keyFields: ({ id }) => `CustomerWishlist:${id}`
},
WishlistItem: {
keyFields: ({ id }) => `CustomerWishlistItem:${id}`
},
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.
Changed according your recommendations.
Thank you!
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 look perfect, nice catch covering all the WishlistItem implementations. It does look like Coveralls is dinging us a tiny bit for not testing the params of these new keyField functions, but not a blocker for approval.
QA Approved. Currently unable to check when multiple wishlist is disabled how the wishlist gonna look but will test it in pr 3048 |
@@ -350,8 +350,6 @@ | |||
"validation.mustBeChecked": "Doit être vérifié.", | |||
"validation.validatePassword": "Un mot de passe doit contenir au moins 3 des éléments suivants: minuscules, majuscules, chiffres, caractères spéciaux.", | |||
"wishlist.emptyListText": "Il n'y a actuellement aucun élément dans cette liste", | |||
"wishlist.privateText": "Privée", | |||
"wishlist.publicText": "Publique", |
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.
packages/extensions/venia-sample-language-packs/i18n/fr_FR.json
Description
createWishlist
GQL mutation (and updates the page)Related Issue
Closes PWA-989
Acceptance
Verification Stakeholders
@dpatil-magento
Specification
Verification Steps
Screenshots / Screen Captures (if appropriate)
Checklist