# 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](https://1976828758-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fxa5zP0ggbUWVqZL79DQK%2Fuploads%2Fgit-blob-b55e1d43317316c6d915c84b467934b5fe8f4c0e%2Fdemo-screen.png?alt=media) The above screen's component definition would look like this: ```json [ { "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" } } } ], "footer_components": [ { "type": "error-list" }, { "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](https://docs.kasko.io/kasko-frontend-documentation/guides/jsonlogic) object handling the visibility of the component. For more information see the [Visibility Condition guide](https://docs.kasko.io/kasko-frontend-documentation/core-concepts/visibility-condition). | | class | No | `"color-primary"` | Optional `class` attribute added to the component. Useful for custom styling. Can also be a [JsonLogic](https://docs.kasko.io/kasko-frontend-documentation/guides/jsonlogic) object for dynamic classes (see below). | 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**](https://webapp-framework.developers.kasko.io/)**.** ## Dynamic config Each of these properties can also be [JsonLogic](https://docs.kasko.io/kasko-frontend-documentation/guides/jsonlogic) except for `"type"`, that should be static as we need to statically analyze manifest and that should never by dynamic. Example: ```diff { "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. ## Dynamic class The `class` property can also use [JsonLogic](https://docs.kasko.io/kasko-frontend-documentation/guides/jsonlogic) to dynamically set CSS classes based on state: ```json { "type": "container", "class": { "type": "jsonlogic", "schema": { "if": [ {"===": [{"var": "input.data.theme"}, "dark"]}, "dark-theme", "light-theme" ] } } } ``` This is useful for conditionally applying styles based on user selections or application state. ## 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](https://docs.kasko.io/kasko-frontend-documentation/getting-started/manifest-flow-dynamic-path) 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](https://docs.kasko.io/kasko-frontend-documentation/guides/jsonlogic). | | flow\_complete | No | `true` | Marks this screen as a terminal/final screen. When set to `true`, the flow is considered finished and all fields become disabled for editing. Typically used on success screens. Screens with `flow_complete: true` should not have a `next` property. Flow completion can also be triggered by events listed in `config.flow_finish_events` in the manifest. Default events include `offer_update`, `offer_purchase`, `policy_update`, `policy_purchase`, `claim_update`, and `claim_created`. | | required\_requests | No | `["policy"]` | A list of requests that must have been completed to access this screen. Available values: any request type enabled in the manifest, or JsonLogic that resolves to a request type. 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](https://docs.kasko.io/kasko-frontend-documentation/guides/required-requests) 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. | Router behavior notes: paths can be static strings, `**` for a catch-all route, and `404` for a not-found route.