Skip to content

Latest commit

 

History

History
35 lines (29 loc) · 1.54 KB

README.md

File metadata and controls

35 lines (29 loc) · 1.54 KB

FSCheckout

Problems to solve

  • Generally, checkout flows have similar features like state management and step trackers so we shouldn't reinvent the wheel.
  • Checkout is complicated so we don't want 10 projects with 10 different code structures to manage.
  • Despite some similarities, many checkouts have unique features so we don't want an inflexible library that makes it hard to customize.

Goal

  • Create a way to standardize the checkout structure.
  • Make common functionalities reusable.
  • Make it flexible for customization.

How

  • Project checkout has to built with FSCheckout component.
  • Leverage TypeScript to force a standardized code structure for:
    • how steps are structured
    • how checkout state and data are managed
    • how api request is made
    • how step progress is managed
  • Each step must be separated into its own component and passed to FSCheckout as props with their name and status.
  • Step Component must be StatelessComponent, and all the states have to go into the main Checkout component as a single state.
  • checkoutState and checkoutActions are required to pass to FSCheckout for defining checkout state and actions
  • Step progress is managed internally in FSCheckout, and reference function is provided to perform arbitrary step jump.
  • step changing hook is provided to do stuff like analtyics
  • A global loading view is provided to mask user interaction. It can be overridden with a custom render.
  • Built in a step tracker. It's customizable with style props and can be overridden with a custom render.