-
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
Uses graphQl mutation to create/fetch cartId. #1988
Conversation
…ateCart asyncAction with removal of cartId and an effect that refetches a new cart.
import { clearCheckoutDataFromStorage } from '../checkout'; | ||
|
||
import actions from './actions'; | ||
|
||
const { request } = Magento2; | ||
const storage = new BrowserPersistence(); | ||
|
||
export const signIn = credentials => |
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 have deleted this in the #1904 but I didn't. Doing it now since I'm trying to clean up refs to getCartDetails.
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.
Did you create a ticket to bring this action back? Would be nice if it referenced this comment on the off chance one of us doesn't pick it up.
You also left SIGN_IN
in the action map, but I'm fine not touching it since it should be coming back.
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 -- I don't think it's necessary right now. 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.
I would probably want it moved before the next release, just so we're providing a consistent pattern for other developers to follow. Given useSignIn
doesn't have any data fetching or effects that make our custom hooks harder to understand, doesn't have to be right now.
|
@@ -74,10 +76,7 @@ const reducerMap = { | |||
isAddingItem: false | |||
}; | |||
}, | |||
[actions.updateItem.request]: (state, { payload, error }) => { | |||
if (error) { | |||
return initialState; |
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 should not be passing error to the request
sync actions, only the receive
.
@@ -43,7 +46,6 @@ const reducerMap = { | |||
return { | |||
...state, | |||
detailsError: payload, | |||
cartId: 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.
Removing cartId
should be done through removeCart
.
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 makes me nervous why this existed, but I couldn't find any components observing this state, so seems safe 🤞
return { | ||
...state, | ||
cartId: String(payload), |
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.
The only thing setting cartId
should be getCart
action.
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.
For context, why did this action accept cartId
as a payload in the first place, and why did the reducer take this opportunity to set it in state?
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.
No idea. Requests are only meant to set loading
states in redux right now. Even that will eventually move to UI I believe. At that point all we will are about are .receive
sync actions.
'Missing required information: cartId' | ||
); | ||
missingCartIdError.noCartId = true; | ||
throw missingCartIdError; |
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 we reach this case? I don't mind throwing a helpful error, but I want to ensure that something like this should never occur.
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 should never not have a cartId. These are just leftover from before. I can remove them. They won't matter when we move these functions to the UI components.
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.
No, please don't remove them. It doesn't hurt to have a helpful error thrown if we reach a state we shouldn't.
I just wanted to make sure that we weren't expecting this case to come up.
return { | ||
...state, | ||
cartId: String(payload), |
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.
For context, why did this action accept cartId
as a payload in the first place, and why did the reducer take this opportunity to set it in state?
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.
So clean; loved that a bulk of the change was in actions, and reviewing the UI code was super simple. Minor suggestions to remove legacy logic and clean things up. Very nice 👌
@@ -43,7 +46,6 @@ const reducerMap = { | |||
return { | |||
...state, | |||
detailsError: payload, | |||
cartId: 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.
This makes me nervous why this existed, but I couldn't find any components observing this state, so seems safe 🤞
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 like this approach. This should help us get onto GraphQL without too much churn while we wait for Suspense to mature.
We'll need to do a pretty thorough QA pass on it.
@@ -38,7 +43,7 @@ export const cancelCheckout = () => | |||
export const resetCheckout = () => | |||
async function thunk(dispatch) { | |||
await dispatch(closeDrawer()); | |||
await dispatch(createCart()); | |||
await dispatch(removeCart()); |
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 be fine.
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.
LGTM 👍
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.
Merge conflict resolution looks good 👍
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.
Discussed IRL, change is needed given GraphQL limitation in 2.3.3. Will re-visit once 2.3.4 drops, and we can fetch persistent Customer carts.
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.
Sorry 😬 please add a test for this
packages/peregrine/lib/store/actions/cart/__tests__/asyncActions.spec.js
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.
Description
NOTE: REST endpoint returns data for "authed" cart created through graphql. To repro, log in, add item to cart, then delete sign in token from local storage and refresh. Cart details should be fetched but you should not be able to add/update/remove. If you take an action on the cart it will reset to a new cart. This could be a bug in REST. It should not matter since those actions are moving to graphql which won't return data for unauthed user.
This PR precedes #1987.
Changes include:
GraphQL endpoints use the masked (hashed) cartId regardless of auth state. REST uses the "actual" (table key value) cartId as quoteId for authed requests and masked cartId as quoteId for guest requests. This means that while we are in this intermediate state of some requests being through graphql (such as
createCart
andaddItemToCart
) we have to make sure the REST calls use the appropriate cartId.createCart
The majority of this PR is to pass the mutation callback into the actions that may need to call
createCart
.We were passing and spreading unnecessary info to the store in the
receive
actions of certain asyncActions. I removed this as it was extraneous.Related Issue
Closes PWA-140.
Acceptance
Verification Stakeholders
@jimbo
Specification
Verification Steps
createCart
. Note the response cartId.Screenshots / Screen Captures (if appropriate)
Checklist