Currently it is possible to create a checkout without an email:
checkoutCreate(input: {email:""}) {
errors {
field
message
}
checkout {
token
email
}
}
As want to support tracking abandoned checkouts later, checkout without an email has no value from this perspective and would be removed anyway at some point.
A related issue in Storefront 2.0: https://github.com/mirumee/saleor-storefront/issues/224
As checkouts is also used as carts in the frontend, do we really need to provide email for a cart? Should we only require email or login when customer would like to checkout for the cart? IMHO I think this required email logic should be moved to frontend instead of backend. Specifically, the shop should require the customer to input the email by calling checkoutEmailUpdate or login directly and calling CheckoutCustomerAttach when they do want to checkout. In both of the two ways, the checkouts will have emails and can be treated as valid.
But in this way, checkouts without email may still be valid sometimes such as they are used by guests who haven't left the storefront 2.0 yet and these checkouts might still be attached to a user or added a email when the customer do want to checkout. So the abandoning chekcouts logic can be removing checkouts without email which are not updated within maybe 10 days or whatever.
So the main point is that with this logic (required email for creating checkout), the guests should input their emails even they only click Add to cart button which is quite inconvinent.
Also in this ticket updateCheckoutShippingAddress needs to be updated in the same manner. Currently, email is not required here as well.
@jxltom Carts for guest customers would be stored only in localStorage. We don't want to create unnecessary objects in the database and we'll be creating checkouts only when they actually go to checkout and provide their email.
@maarcingebala Yeah I totally get your idea :D They are just two different approaches. One way is implementing cart logic in frontend and only creating checkout in backend with required email or login user when user do want to checkout. But this requires more code in frontend such as calculating total price, checking stocks, etc. The other way is always creating cart as checkout in backend without required email or login. The email or login user is assigned to checkout when they do want to checkout. This requires less logic in frontend but may creating too many useless checkouts in db. A celery task removing these invalid checkout is required.
For now personally I prefer the latter approach but I will spend more time evaluating these two approaches later 😄
I'm in the process of implementing the checkout and I was very surprised to discover that the email was required. Having to duplicate all the cart logic depending on whether the user is logged in or not — including calculations, numbers and currency formatting — would be a lot of useless work as well as useless code shipped to the client browser.
I think Saleor should leave the choice to the developer by not requiring the email, which would still allow to create anonymous checkout on the client-side only. I'll personally create checkouts with fake email address now as I don't have the time to implement it twice.
I'd be glad if you could reconsider this decision as I think it's quite opinionated without much benefit for the user nor the developer experience to be justified.
Most helpful comment
I'm in the process of implementing the checkout and I was very surprised to discover that the email was required. Having to duplicate all the cart logic depending on whether the user is logged in or not — including calculations, numbers and currency formatting — would be a lot of useless work as well as useless code shipped to the client browser.
I think Saleor should leave the choice to the developer by not requiring the email, which would still allow to create anonymous checkout on the client-side only. I'll personally create checkouts with fake email address now as I don't have the time to implement it twice.
I'd be glad if you could reconsider this decision as I think it's quite opinionated without much benefit for the user nor the developer experience to be justified.