Customization state

After a blueprint is built and loaded, Customizer clients are expected to main a configuration state. A configuration state:

• Determines the currently active components

• Drives changes in the user experience

• Allow to preview product configuration

• Needs to be submitted to the server to create a recipe (saved design).

A configuration state is comprised of:

• A list of all product placements

• A list of components selected in each placement

• A list of globally active tags

Additionally, for multi-product configurators, a configuration state would include:

• A list of socket connectors for all currently loaded products

• A list of products selected into each socket. Sockets may have associated products or may be left empty.

Valid and invalid states

A state must be valid in order to be accepted by the server to save a recipe. However, a state may be temporarily invalid while a user is configuring a product. A user interface layer is expected to resolve all state issues prior to saving a recipe.

A state is considered valid when:

• For every placement

• … there is a selected component

• … that is “allowed” and “active”

Invalid state examples include:

• A state where some placements do not have any available components and thus no selection can be made

• A state where a placement is assigned a component but that component is not allowed

Buildable state

A valid state can be buildable or not-buildable. In order for a state to be able to be built:

• A state must be valid

• State placements must not have placeholder components selected

  • However, placeholders that are marked as optional are allowed

A non-buildable state can be used to save a recipe still. It is typically recommended that the e-commerce platform performs a status check on the recipe to validate whether a recipe can be used to place an order.

Typical use cases for saving a non-buildable state include:

• Save-for-later or continue a previous design

• Social sharing