New checkout

[orzechdev]

I want to merge this change because... it adds stateful checkout and cart to SDK with new cart and checkout UI.

New checkout and cart UI

New checkout and cart UI with completely refactored components which uses new hooks within them.

New hooks for checkout and cart

• added new useCheckout and useCart hooks, which has all data and methods associated with checkout and cart to use within React components:

const {
  checkout,
  billingAsShipping,
  selectedShippingAddressId,
  selectedBillingAddressId,
  availableShippingMethods,
  payment,
  availablePaymentGateways,
  promoCodeDiscount,
  loaded,
  load,
  setShippingAddress,
  setBillingAddress,
  setBillingAsShippingAddress,
  setShippingMethod,
  addPromoCode,
  removePromoCode,
  createPayment,
  completeCheckout,
} = useCheckout();

const {
  items,
  discount,
  shippingPrice,
  subtotalPrice,
  totalPrice,
  loaded,
  load,
  addItem,
  subtractItem,
  updateItem,
  removeItem
} = useCart();

SDK changes

• as illustrated below, new hooks are prepared based on SaleorCheckoutAPI and SaleorCartAPI classes aggregated in SaleorAPI class. State for those API classes is derived from new SaleorState object, which is altered based on results form GraphQL queries/mutations, local storage changes and job executions. All data from SaleorState is observable, what means that SaleorCheckoutAPI and SaleorCartAPI classes observes appropriate data from there and automatically recalculate its own state based on notified changes. After that, SaleorAPI is notified about changes, which in turn notifies react context provider about them. Context provider then recreates context object with references to SaleorCheckoutAPI and SaleorCartAPI classes, which are used by new hooks. Effectively, React triggers components tree update and all instances of new hooks are up to date.
  
• end developer might use API straight from SDK using SaleorManager, i.e.:

const manager = new SaleorManager(apolloClient, optionalCustomConfig);
manager.connect(saleorAPI => /* do something with saleor API */)

• or end developer might utilize SaleorProvider which provides SaleorAPI in context, which is used among all new React hooks, i.e.:

<SaleorProvider client={apolloClient} config={optionalCustomConfig}>
    {/* use new React hooks anywhere in the components tree */}
</SaleorProvider>

Error handling

There are two types of functions returned by useCart and useCheckout hooks:

• immediately executed functions (e.g. completeCheckout()), which return promise with:

{
  data, // altered data by function, do not need to be user, as same data in hooks are automatically updated
  dataError, // errors returned by backend
  functionError, // errors performed on frontend within SDK
  pending, // always false, indicates if function finished its job
}

• queued functions to be executed as soon as possible, when internet connection exists (e.g. addItem()):

{
  pending, // indicates if function finished its job
}

For queued functions, errors might be catched, by adding error listeners:

const {
  addOnErrorListener,
  removeOnErrorListener,
} = useCheckout();

useEffect(() => {
  addOnErrorListener(onErrorListener);
  return () => {
    removeOnErrorListener(onErrorListener);
  };
}, []);

const onErrorListener = (
  error: ApolloErrorWithUserInput,
  type: ErrorTypes
) => {
  const errors = error.extraInfo.userInputErrors;
  if (type === ErrorCartTypes.SET_CART_ITEM && errors) {
    // do something with errors
  }
};

Fixes

• fixes Adapt the appearance of Stripe components to the current design #487
• fixes Why we need to "ADD NEW ADDRESS"again and again? #645
• fixes Entered has not been saved - purchase as a logged user #665
• fixes Changing quantity in product #668

[netlify]

Deploy preview for saleor-storefront-stage processing.

Building with commit 62d083a

https://app.netlify.com/sites/saleor-storefront-stage/deploys/5eafd4d6bc5ff0000906fb12

[dominik-zeglen]

...why?

[orzechdev]

I'll fix it, but in some cases I see that it may facilitate creating new components, where you might not know in advance which html tags should be styled and which should not, so the assumption that we do all styled tags eliminates the need to change tags in JSX and move them to styles.ts file on a regular basis. Eventually every styled tag is rendered as single html tag, so it does not change a lot.

[dominik-zeglen]

I believe that Formik has useFormik hook now, we should probably use it

[orzechdev]

Yes, it might be much better, but I guess we may switch to useFormik in another PR as many components are already prepared with render props way

[dominik-zeglen]

It looks like it could be replaced by some gql fragment type. Actually, a lot of props in this PR can be written using some fragments or types coming from queries.

[orzechdev]

I'm not sure about it, because if we want to rely on SDK in a separate package in the future, it might hide from us those interfaces generated by Apollo in that package.

[lgtm-com]

This pull request fixes 5 alerts when merging 1cf7c8a into 3cfdeef - view on LGTM.com

fixed alerts:

• 2 for Unused variable, import, function or class
• 1 for Useless conditional
• 1 for Assignment to constant
• 1 for Unused or undefined state property

[lgtm-com]

This pull request fixes 5 alerts when merging 62d083a into 3cfdeef - view on LGTM.com

fixed alerts:

• 2 for Unused variable, import, function or class
• 1 for Useless conditional
• 1 for Assignment to constant
• 1 for Unused or undefined state property