# 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](/files/DCO8dlJueZHVCfjXQorP) 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](/kasko-frontend-documentation/guides/jsonlogic.md) object handling the visibility of the component. For more information see the [Visibility Condition guide](/kasko-frontend-documentation/core-concepts/visibility-condition.md). | | class | No | `"color-primary"` | Optional `class` attribute added to the component. Useful for custom styling. Can also be a [JsonLogic](/kasko-frontend-documentation/guides/jsonlogic.md) 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](/kasko-frontend-documentation/guides/jsonlogic.md) 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](/kasko-frontend-documentation/guides/jsonlogic.md) 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](/kasko-frontend-documentation/getting-started/manifest-flow-dynamic-path.md) 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](/kasko-frontend-documentation/guides/jsonlogic.md). | | 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](/kasko-frontend-documentation/guides/required-requests.md) 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.kasko.io/kasko-frontend-documentation/getting-started/manifest-flow.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.