🖼️
KASKO Frontend Documentation
  • README
  • Getting started
    • Setting up a new webapp
    • Webapp manifest
    • Building the flow
    • Defining layouts
    • Defining computed values
    • Defining dynamic paths
  • Core concepts
    • Forms
    • Validation
      • Using existing validators
      • Adding custom validators
    • Configuration
      • Price format
      • Date format
    • Performing API calls
    • Toggling visibility of components
    • Translations
    • Rules For Robust Application
  • Guides
    • Using logical statements (JsonLogic)
    • Adding discount codes
    • Developing Custom Plugins
    • Setting required requests
    • Adding save quote for later
    • Transforming request data
    • Manifest merging strategy
    • Knockout flow
    • Local pricing logic
    • Setting up dashboard policy profile
    • Handling offers
    • Repeater
  • Snippets
    • Reset input state
  • Useful resources
    • All component descriptions
    • JsonLogic core documentation
    • Kasko.js documentation
    • Example webapp
    • Example plugins (w/ various frameworks)
Powered by GitBook
On this page
  • Screen component definition
  • Dynamic config
  • Full screen definition
  1. Getting started

Building the flow

Last updated 9 months ago

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.

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

{ ... }

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.

Dynamic config

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"

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"

required_requests

No

["policy"]

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.

object handling the visibility of the component. For more information see the .

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

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

Unique URI path that will be used to identify this screen. Path can also by nested and dynamic. See for more information.

Path of the next screen as a string or .

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 for more information.

component storybook
JsonLogic
JsonLogic
Visibility Condition guide
dynamic path guide
JsonLogic
required requests guide
Example Screen