Building the flow

Each webapp needs a visual flow that a customer can be guided through. Individual pages in the flow are called screens. Think of a screens as nodes on a graph. These nodes can point to one or many other nodes. Each node has elements (components) attached to it as well as some optional configuration.

Let's take a look at the component definition of screens.

Screen component definition

Each webapp consists of various components. You can think of them as lego bricks.

A screen may consist of many lego bricks. One's for the title image, another for title text, input box and the submit button. The collection of these components builds a screen.

Example Screen

The above screen's component definition would look like this:

[
  {
    "type": "image",
    "config": {
      "src": "https://path.to/image.png"
    }
  },
  {
    "type": "title",
    "config": {
      "content_key": "flow.contact_details.title"
    }
  },
  {
    "type": "form",
    "config": {
      "components": [
        {
          "type": "form-input",
          "config": {
            "show_label": true,
            "field_name": "data.some_field",
            "content_key": {
              "label": "form.some_field.label",
              "placeholder": "form.some_field.placeholder"
            }
          }
        },
        {
          "type": "error-list"
        }
      ],
      "footer_components": [
        {
          "type": "form-button-next",
          "config": {
            "content_key": "flow.buttons.next"
          }
        }
      ]
    }
  }
]

It's an array of component definition objects. The component definition object consists of these primary variables:

Variable	Required	Example	Description
type	Yes	"title"	Unique identifier for the component to be used.
config	No	{ "content_key": "flow.contact_details.title" }	Configuration object that is passed on to the component - unique per component.
visibility_condition	No	{ ... }	JsonLogic object handling the visibility of the component. For more information see the Visibility Condition guide.
class	No	"color-primary"	Optional class attribute added to the component. Useful for custom styling.

Some components even feature transclusion. In the example above, form component features two transclusions. One in body level (components) and one in footer section (footer_components). This means that one component can be embedded within the other.

For a full list of components and their descriptions visit the component storybook.

Dynamic config

Each of these properties can also be JsonLogic except for "type", that should be static as we need to statically analyze manifest and that should never by dynamic.

Example:

{
  "type": "form-input",
  "config": {
-   "field_name": "data.static_field",
+   "field_name": {
+     "type": "jsonlogic",
+     "schema": { "var": "input.data.dynamic_field_name" }
+   }
  }
}

In this case we changed field name of this component from static "data.static_field" to dynamic one. Now if we update input.data.dynamic_field_name value to hello, then this form input component will receive "hello" as a field name.

Full screen definition

Variable	Required	Example	Description
path	Yes	"start"	Unique URI path that will be used to identify this screen. Path can also by nested and dynamic. See dynamic path guide for more information.
name	No	"Start"	Name of the screen that is used just as a human readable identificator.
layout	No	"my-custom"	Layout name that will be used for this screen. Defaults to the default layout ("default").
components	Yes	[{ ... }]	An array of component definitions.
next	Yes	"payment"	Path of the next screen as a string or JsonLogic.
required_requests	No	["policy"]	A list of requests that must have been completed to access this screen. Available values: quote, policy, lead and payment. This is useful especially in success screen where success messages are not shown if one or many of the required requests have not completed. See required requests guide for more information.
fields	No	["cc_name", "cc_cvc"]	Sometimes a component adds fields automatically to a screen (for example payment component). If the API errors the framework must know to what screen to redirect the customer to. This array of field names solves that issue. Usage of fields is deprecated.