# [SFT-1148](https://carewellfamily.atlassian.net/browse/SFT-1148) - [SPIKE] Architecture: Autoship in Checkout

This is a quick write-up of a SPIKE into the feasibility of implementing a new AutoShip component in the BigCommerce-hosted checkout.

**Questions:**
- Can we implement this feature without forking & uploading [checkout-js](https://github.com/bigcommerce/checkout-js)?
- Can we update & edit line items in the cart?
- When autoship coupon is applied, is it correctly reflected in the UI?

## Checkout architecture overview

[checkout-js](https://github.com/bigcommerce/checkout-js) is a react app built & hosted by BigCommerce themselves embdedded at `/checkout`

The app holds internal state based on an instance of [checkout-sdk](https://github.com/bigcommerce/checkout-sdk-js) which is another library open sourced by BigCommerce which wraps their Storefront API where appropriate for building a checkout app.

## Questions

### Can we update & edit line items in the cart?

`checkout-sdk` operates a subscription architecture. State from checkout-sdk is held within a react context which is updated whenever the subscription fires.

componentDidMount(): void {
    const { checkoutService } = this.props;

    this.unsubscribe = checkoutService.subscribe(checkoutState =>
        this.setState({ checkoutState })
    );
}

This means that if we'd like the cart UI to update as customers interact with the Autoship component, we'd need to update the cart through the Storefront API using the same instance of `checkout-sdk` used by `checkout-js` in order to trigger the subscription & hence re-render.

### When autoship coupon is applied, is it correctly reflected in the UI?

Yes - we're already doing this & we've submitted coupons via the DOM in the past. Ideally we'd update coupons via e.g. the instance of `checkout-sdk` as above.

### Can we implement this feature without forking & uploading checkout-js

I don't believe so. `checkout-js` does not expose a way in which interact with, or inject an instance of `checkout-sdk`. Interaction with the same instance of `checkout-sdk` is required in order to trigger UI updates in `checkout-js` due to the subscription/state model.

## Conclusion

I believe there are two ways to go ahead with implementation - however both require forking `checkout-js`. The downside to this is that we will no longer receive automatic updates to the checkout page from BigCommerce. We'd need to manage this ourselves with regular merging/rebasing.

### Option #1: Minimal fork A

1) Fork [checkout-js](https://github.com/bigcommerce/checkout-js)
2) When the app initializes, attach the `checkout-sdk` to the window object
3) Implement the autoship components in vanilla js using the checkout-sdk in `window` object

#### Advantages

- Merge/rebase on updates should be simple

#### Disadvantages

- Autoship component would need to be written in vanilla javascript i.e. would require DOM manipulation.
- Potential security issue with checkout-sdk on global window object?

### Option #2: Minimal fork B

1) Fork [checkout-js](https://github.com/bigcommerce/checkout-js)
2) Expand the loader/auto-loader to include ability to pass custom instance of `checkout-sdk` which can now be shared between `checkout-js` and `checkout-sdk`
3) Implement the autoship components in vanilla js

#### Advantages

- Merge/rebase on updates should be simple
- No need for global checkout-sdk object

#### Disadvantages

- Autoship component would need to be written in vanilla javascript i.e. would require DOM manipulation.

### Option #3: Implement component with fork

1) Fork [checkout-js](https://github.com/bigcommerce/checkout-js)
2) Implement entire component within the fork

#### Advantages

- Less hacky, more robust
- Can hook directly into checkout steps

#### Disadvantages

- Maintenance could be trickier e.g. merge/rebase as BigCommerce make updates to checkout-js