@brandingbrand/fscheckout10.4.0 • Public • Published
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.
- Create a way to standardize the checkout structure.
- Make common functionalities reusable.
- Make it flexible for customization.
- Project checkout has to built with
- 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.
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.
npm i @brandingbrand/fscheckout