Separate the checkout flow states from the order states

[athal7]

The order state machine is heavily tied to the solidus_frontend checkout states. It would be nice to remove that tie, and allow the order to be handled without those specific states, or maybe without the state_machine gem at all.

[cbrunsdon]

In this episode of Solidus Issue Background History:

Historically Spree::Order.state was a state machine very tightly integrated to the "checkout steps" a user would go through in order to complete a checkout.

A "cart" would enter the "checkout" state when the checkout button was made.
The Spree::Order would progress to the "address" state when "continue" was clicked on the checkout page, prompting the user to enter their address.
"delivery" would be next, prompting the user to select a shipment method.
"payment" would follow, prompting for payment information
"confirm" would (optionally) show up with an order summary
"compete" would follow that, when an order was complete.

An order progresses through these states with the magic ".next" method, which just pushes an order through the states if it meets the criteria of being able to move forward.

As checkout's became more customized (single page API driven, re-ordered flow, etc) and the number of "states" we considered an order in increased (fraud, cancelled) it became clear that state_machine model we have is overly complex and tied to an outdated _frontent checkout flow.

The core team has identified that the checkout flow should not be dictated by an Order's state machine and should be pulled out and supported in a different way, which we hypothesize should improve comprehension and reduce complexity of an order.

Extracting the address/delivery/payment/checkout state from the Spree::Order should be considered a very advanced topic, likely only accomplish-able by someone with a very thorough understanding of the spree order state machine.

[BenMorganIO]

Dibs. (On cracking the order state machine code.)

[hhff]

Keen to follow along / help out here where possible - at least from a "chatting things out" perpective. The Spree Ember Checkouts package is a promise aware state machine that wraps the current order. Keen to do what I can to support the new approach!

Related: https://github.com/hhff/spree-ember/blob/master/packages/checkouts/app/services/checkouts.js

[cbrunsdon]

Hawth and I are going to kill this, as while we would love to see it done, it's not actionable with how the codebase is now. We have many more tasks we need to accomplish first before this can be tackled reasonably.