@lowdefy/docs 4.0.0-alpha.7 → 4.0.0-alpha.8

package/concepts/blocks.yaml

@@ -1,249 +0,0 @@
-# Copyright 2020-2021 Lowdefy, Inc
-
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-
-#     http://www.apache.org/licenses/LICENSE-2.0
-
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-_ref:
-  path: templates/general.yaml.njk
-  vars:
-    pageId: blocks
-    pageTitle: Blocks
-    section: Concepts
-    filePath: concepts/blocks.yaml
-    content:
-      - id: md1
-        type: MarkdownWithCode
-        properties:
-          content: |
-            #### TLDR
-              - All user interfaces in Lowdefy are assembled out of blocks.
-              ##### Block types
-              - There a five block categories: `display`, `input`, `context`, `container` and `list`.
-              - Operators re-evaluate on every [`state`](/context-and-state)  update or as request calls complete. This allows blocks to _live update_.
-              - Lowdefy has built in default block types, however this can be overwritten or extended with custom blocks by defining `types` on the Lowdefy config root.
-              - `input` blocks maintain a value in `state` matching the block `id` key. _Dot notation_ applies to specify nested fields.
-              ##### Block validation
-              - Field level input validation can be achieved by marking a `input` block as `required` or by specifying a list of `validate` tests.
-              - Validation is invoked using the [`Validate`](/Validate) action.
-              ##### Block events
-              - All blocks have`onMount` and `onMountAsync` events.
-              - Each block implements it's own additional events such as `onClick` etc.
-              ##### Block loading
-              - By default all blocks render a loading skeleton when the block's source code is fetched or while the block is waiting on data from a request.
-              - A block's default loading can be overwritten by defining custom `loading` settings on a block.
-
-            -------
-            A Lowdefy page is compiled out of an arrangement of blocks. Every HTML element of this page is render as a result of a block placed and configured on the page. Blocks make it simple for Lowdefy developers to create apps since they only have to decide what block type to use, where in the layout the block should render, and what the block should do by defining the block's `properties`. How a block implements these `properties` is up to the specific block type selected.
-
-            Lowdefy offers a list of over 30 block types to cater for a wide range of use cases. All blocks are categorized according to their primary function:
-            - `display` - Display page elements.
-            - `input` - Modify a value in [`state`](/context-and-state).
-            - `context` - Create a new [`context`](/context-and-state).
-            - `container` - Render other blocks into [`content areas`](/layout).
-            - `list` - Render `content areas` and blocks for each element in the data array.
-
-            When `state` updates or a requests call completes, the Lowdefy engine reevaluates all operators and rerenders blocks for which the operator evaluation is different from the previous render result. The result is _live updates_  to all blocks on a page. Operators can be used to build _live update_ logic into all block fields, except for the `id`, `type`, `areas`, `blocks` and `loading` fields.
-
-            # Block Schema
-
-            The schema for a Lowdefy block is:
-
-            - `id: string`: __Required__ - A unique identifier for a block. For `Input` blocks the block `id` sets the field key which the block will modify in `state`. Field _dot-notation_ can be used to express fields which are nested in objects or arrays.
-            - `type: string`: __Required__ - The is the block type identifier and defines what block to used. The block type used must either be a default block type or must defined in your app's `types` configuration.
-            - `properties: object`: All the settings passed to a block component. __Operators are evaluated__.
-            - `areas: object`: Used to set the content areas and content layout settings for `container`, `context` and `list` blocks. See [layout](/layout) for more details on how to use `areas`.
-            - `blocks: array`: A array of blocks to render to the default `content` area for `container`, `context` and `list` blocks. See [layout](/layout) for more details on how to use the `blocks` array.
-            - `events: object`: Used to defined [`actions`](/events-and-actions) that run when the block triggers an [`event`](/events-and-actions).
-            - `layout: object`: Used to define the [layout](/layout) properties for a block. __Operators are evaluated__.
-            - `loading: object`: Used to overwrite a block's default loading behavior.
-            - `required: boolean | string`: For `input` blocks, whether or not a value value is required in `state` when the [`Validate`](/Validate) action is called. Can be either a boolean or a string that is used as the validation error message . __Operators are evaluated__.
-            - `style: css object`: Used to apply css style settings to the block's top level `div` element. __Operators are evaluated__.
-            - `validate: array`: A list of validation tests to pass when the [`Validate`](/Validate) action is called. __Operators are evaluated__.
-            - `visible: boolean`: Controls whether or not to render a block. Operators  are generally used here, and must evaluate to `false` to make the block invisible. Blocks with `visible: false` are excluded from `state`. __Operators are evaluated__.
-
-            # Block types
-
-            Lowdefy has list of default block types as defined in the Lowdefy docs. The default Lowdefy blocks aim to cover a very generic implementation of the [Ant Design](https://ant.design/components/overview/) react component library. To use all the default block types, you can simply use the block `type` key, like [`Button`](/Button), [`TextInput`](/TextInput), or [`Box`](/Box).
-
-            ###### Default block type config example:
-            ```yaml
-            lowdefy: LOWDEFY_VERSION
-            pages:
-              - id: example_dashboard
-                type: PageHeaderMenu
-                blocks:
-                  - id: basic_chart
-                    type: Button
-                    properties:
-                      # ... Button details
-            ```
-
-            However, the default types can overwritten or additional types can be define as required. For example, to set a `type` for a custom implementation of [AmCharts](https://www.amcharts.com/), we can do the following. We have created a custom [Lowdefy block for AmCharts v4](https://www.npmjs.com/package/@lowdefy/blocks-amcharts) that we can use.
-
-            ###### Custom block type config example:
-            ```yaml
-            lowdefy: LOWDEFY_VERSION
-            types:
-              AmChartsXY:
-                url: https://blocks-cdn.lowdefy.com/v3.10.1/blocks-amcharts/meta/AmChartsXY.json
-            pages:
-              - id: example_dashboard
-                type: Context
-                blocks:
-                  - id: basic_chart
-                    type: AmChartsXY
-                    properties:
-                      # ... AmCharts details
-            ```
-
-            More details on custom blocks can be found [here](/custom-blocks).
-
-
-            # Input block validation
-
-            All `input` block types maintain a value in [`state`](/context-and-state). This value is set to the field name matching the block `id`. Nested fields can be created by using _dot notation_ in the `id` to specify the field path.
-
-            Client side field validation can be applied setting the `required` and / or `validate` block fields. The following schema applies to `required` and `validate`.
-
-            Field validation is first evaluated when the [`Validate`](/Validate) action is invoked on a page.
-
-            ##### `required` schema:
-            `required` can be a `boolean` or `string` type. When `required: true` the field label will indicate this with a red dot for user feedback, and a value will have to be supplied in to the field in order to pass validation. If `required` is set to a `string`, this string will be used as the feedback message when the validation fails.
-
-            ```yaml
-            - id: name
-              type: TextInput
-              required: Please provide your name.
-              properties:
-                title: Name
-            ```
-
-            ##### `validate` schema:
-            The `validate` field takes a `array` of test `objects` to evaluate before passing the field validation. This list of tests are evaluated sequentially, so the test that fails first will be used as the feedback message to the user.
-
-            The schema for the validation test `objects`:
-            - `pass: boolean`: __Required__ - The test that validates if this item passes or not. This is usually written as operators which evaluates to a `true` or `false`. __Operators are evaluated__.
-            - `message: string`: __Required__ - The feedback message to the user if this validation tests fails. __Operators are evaluated__.
-            - `status: enum`: The feedback type to present to the user. Option are `error` and `warning`. Default is `error`. __Operators are evaluated__.
-
-            The following `validate` example first verifies that something was entered into the `email` field, then checks that the field passes a email regex validation using the [`_regex`](/_regex) operator:
-            ```yaml
-              - id: email
-                type: TextInput
-                validate:
-                  - message: Please enter a email address.
-                    status: error
-                    pass:
-                      _not:
-                        _not:
-                          _state: email
-                  - message: Please provide a valid email address.
-                    status: error
-                    pass:
-                      _regex: '^(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$'
-                properties:
-                  title: Email
-            ```
-
-            # Block events
-
-            By default all blocks implements `onMount` and `onMountAsync` events. Both the `onMount` and `onMountAsync` events are triggered when the block is mounted. For the `onMount` event, the block only mounts when the event action chain is completed, however, for the `onMountAsync` event, the block will mount as soon as possible while the event actions completes execution.
-
-            Apart from the `onMount` and `onMountAsync` events, most blocks also implements their own block specific events such as `onOpen` for [Modal](/Modal) or `onClick` for [Button](/Button). See the events tab on each block's documentation for more details.
-
-            See [the events and actions page](/events-and-actions) for more details.
-
-            # Block loading
-
-            Block loading renders a placeholder block while the block component is being fetched, or a block is waiting on a request to return before to rendering the block. This allows for a smoother user experience and reduces 'bounce' in the user interface as more blocks takes up their full width and height on the page while in a loading state.
-
-            By default, Lowdefy tries to give a reasonable definition for how much space a block should take up in while loading, however this can vary depending on how the block is used. The `loading` property on blocks allows the Lowdefy developer to set a custom loading configuration for a block.
-
-            ##### Custom block `loading` example:
-
-            ```yaml
-            pages:
-              - id: page_one
-                type: Context
-                blocks:
-                  # ...
-                  - id: paragraph_one
-                    type: Title
-                    loading:
-                      type: SkeletonParagraph
-                      properties:
-                        lines: 1
-                    properties:
-                      content: Lorem ipsum dolor sit amet.
-                  # ...
-            ```
-
-            ## Loading placeholder types
-
-            The following loading placeholder types are available:
-
-            ##### Spinner
-            A Lowdefy logo loading spinner placed at the center of the block. Often used as the full page loading spinner logo. The following `properties` apply to `Spinner`:
-
-            - `barColor: string`: Color of the bars in the Lowdefy spinner logo.
-            - `color: string`: Color of spinner logo. Default is `#f1f1f1`.
-            - `height: number | string`: Height of the spinner block including background. Default is `100%`.
-            - `shaded: boolean`: Masks the spinner block including background.
-            - `size: number | string`: Size of the spinner icon. Default is `50px`.
-
-            ##### IconSpinner
-            A spinning loading icon. The following `properties` apply to `IconSpinner`:
-
-            - `size: number | enum`: Size of the spinner icon. Options are `small`, `medium` and `large`. Default is `20px`.
-
-            ##### Skeleton
-            A rectangular loading skeleton to fill the full size of the block. The following `properties` apply to `Skeleton`:
-
-            - `height: number | string`: Height of the skeleton block. Default is `100%`.
-            - `width: number | string`: Width of the skeleton block. Default is `100%`.
-
-            ##### SkeletonAvatar
-            A avatar loading skeleton. The following `properties` apply to `SkeletonAvatar`:
-
-            - `size: number | enum`: Size of the avatar skeleton. Options are `small`, `medium` and `large`. Default is `32px`.
-            - `shape: enum`: Shape of the avatar skeleton. Options are `square` and `round`. Default is `round`.
-
-            ##### SkeletonButton
-            A button loading skeleton, matches the size of [`Button`](/Button) blocks. The following `properties` apply to `SkeletonButton`:
-
-            - `size: enum`: Size of the button skeleton. Options are `small`, `medium` and `large`. Default is `medium`.
-            - `shape: enum`: Shape of the button skeleton corners. Options are `square` and `round`. Default is `round`.
-            - `height: number | string`: Height of the button skeleton. Overwrites the size setting.
-            - `width: number | string`: Width of the button skeleton. Default is `100%`.
-
-            ##### SkeletonInput
-            A input loading skeleton, used as a placeholder for input blocks with labels. The following `properties` apply to `SkeletonInput`:
-
-            - `size: enum`: Size of the input skeleton. Options are `small`, `medium` and `large`. Default is `medium`.
-            - `labelHeight: number | string`: Height of the label part of the input skeleton.
-            - `inputHeight: number | string`: Height of the input part of the input skeleton. Overwrites the size setting.
-            - `labelWidth: number | string`: Width of the label part of the input skeleton. Default is `100%`.
-            - `width: number | string`: Width of the input part of input skeleton. Default is `100%`.
-
-            ##### SkeletonParagraph
-            A paragraph loading skeleton, used as a placeholder for text intensive section. The following `properties` apply to `SkeletonParagraph`:
-
-            - `lines: number`: The number of paragraph lines to render. Default is `4`.
-            - `width: number | string`: Width of the paragraph skeleton. Default is `100%`.
-
-      - _ref:
-          path: templates/navigation_buttons.yaml
-          vars:
-            previous_page_title: Context and State
-            previous_page_id: context-and-state
-            next_page_title: Layout
-            next_page_id: layout

package/concepts/cli.yaml

@@ -1,173 +0,0 @@
-# Copyright 2020-2021 Lowdefy, Inc
-
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-
-#     http://www.apache.org/licenses/LICENSE-2.0
-
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-_ref:
-  path: templates/general.yaml.njk
-  vars:
-    pageId: cli
-    pageTitle: The CLI
-    section: Concepts
-    filePath: concepts/cli.yaml
-    content:
-      - id: md1
-        type: MarkdownWithCode
-        properties:
-          content: |
-            The Lowdefy CLI is used to develop a Lowdefy app locally, and to build Lowdefy apps for deployment.
-
-            We recommend running the CLI using `npx`, to always use the latest version:
-
-            ```
-            npx lowdefy@latest <command>
-            ```
-
-            or, to use a specific version:
-
-            ```
-            npx lowdefy@version <command>
-            ```
-
-            Alternative, you can install the CLI globally or to a npm project (with a `package.json` file) via npm or yarn.
-
-            To install the CLI globally run:
-
-            ```
-            npm install lowdefy -g
-            ```
-
-            The CLI can then be run using `lowdefy` as the executable name:
-
-            ```
-            lowdefy <command>
-            ```
-
-            # CLI commands
-
-            ## build
-
-            The `build` command runs a Lowdefy build. The options are:
-
-            - `--config-directory <config-directory>`: Change config directory. The default is the current working directory.
-            - `--blocks-server-url <blocks-server-url>`: The URL from where Lowdefy blocks will be served. See below for more information.
-            - `--disable-telemetry`: Disable telemetry.
-            - `--output-directory <output-directory>`: Change the directory to which build artifacts are saved. The default is `<config-directory>/.lowdefy/build`.
-            - `--ref-resolver <ref-resolver-function-path>`: Path to a JavaScript file containing a `_ref` resolver function to be used as the app default `_ref` resolver.
-
-            ## build-netlify
-            The `build-netlify` command creates a production build for the [Netlify](https://www.netlify.com) web hosting service. It is designed to run as the Netlify build command.
-
-            We recommend setting the build command to `npx lowdefy@latest build-netlify`. The Netlify publish directory should be set to `.lowdefy/publish`, and the functions directory set to `.lowdefy/functions`.
-
-            - `--config-directory <config-directory>`: Change config directory. The default is the current working directory (The config directory should rather be configured in the Netlify build settings).
-            - `--blocks-server-url <blocks-server-url>`: The URL from where Lowdefy blocks will be served. See below for more information.
-            - `--disable-telemetry`: Disable telemetry.
-            - `--ref-resolver <ref-resolver-function-path>`: Path to a JavaScript file containing a `_ref` resolver function to be used as the app default `_ref` resolver.
-
-            ## clean-cache
-
-            The Lowdefy CLI caches block metadata, and build and server scripts in the `.lowdefy/cache` directory. These cached files can be removed using the `clean-cache` command.
-
-            - `--config-directory <config-directory>`: Change config directory. The default is the current working directory.
-            - `--disable-telemetry`: Disable telemetry.
-
-            ## dev
-
-            The `dev` command starts a Lowdefy development server, running locally. It can be accessed in a browser at [http://localhost:3000](http://localhost:3000). The CLI watches the file system, and rebuilds the app and reloads served pages every time a change is made to any of the files in the project directory.
-
-            - `--config-directory <config-directory>`: Change config directory. The default is the current working directory.
-            - `--blocks-server-url <blocks-server-url>`: The URL from where Lowdefy blocks will be served. See below for more information.
-            - `--disable-telemetry`: Disable telemetry.
-            - `--port <port>`: Change the port the server is hosted at. The default is `3000`.
-            - `--ref-resolver <ref-resolver-function-path>`: Path to a JavaScript file containing a `_ref` resolver function to be used as the app default `_ref` resolver.
-            - `--watch <paths...>`: A list of paths to files or directories that should be watched for changes.
-            - `--watch-ignore <patterns...>`: A list of paths to files or directories that should be ignored by the file watcher. Globs are supported.
-
-            #### Examples
-
-
-            Run the dev server, watching a relative directory for file changes:
-            ```txt
-            npx lowdefy@latest dev --watch ../other-project
-            ```
-
-            Run the dev server, ignoring the public directory:
-            ```txt
-            npx lowdefy@latest dev --watch-ignore public/**
-            ```
-
-            # Configuration
-
-            All the CLI options can either be set as command line options, or the `cli` config object in your `lowdefy.yaml` file. Options set as command line options take precedence over options set in the `lowdefy.yaml` file. The config in the `lowdefy.yaml` cannot be referenced using the `_ref` operator, but need to be set in the file itself.
-
-            Options set in the `lowdefy.yaml` should be defined in camelCase. The options that can be set are:
-            - `blocksServerUrl: string`: The URL from where Lowdefy blocks will be served. See below for more information.
-            - `disableTelemetry: boolean`: Disable telemetry.
-            - `outputDirectory: string`: Change the directory to which build artifacts are saved. The default is `<config-directory>/.lowdefy/build`.
-            - `refResolver: string`: Path to a JavaScript file containing a `_ref` resolver function to be used as the app default `_ref` resolver.
-            - `port: number`: Change the port the server is hosted at. The default is `3000`.
-            - `watch: string[]`: A list of paths to files or directories that should be watched for changes.
-            - `watchIgnore: string[]`: A list of paths to files or directories that should be ignored by the file watcher. Globs are supported.
-
-            The `--config-directory` option cannot be set from the `lowdefy.yaml` file.
-
-
-            # Telemetry
-
-            The CLI collects usage and error information to help us fix bugs, prioritize features, and understand how Lowdefy is being used.
-
-            All telemetry can be disabled by setting the `disableTelemetry` flag in `cli` config object in your `lowdefy.yaml` file (this cannot be a reference to another file), or by using the `--disable-telemetry` command line flag.:
-
-            ###### `lowdefy.yaml`
-            ```yaml
-            lowdefy: LOWDEFY_VERSION
-
-            cli:
-              disableTelemetry: true
-            ```
-
-            We collect the following information:
-
-            - The CLI version.
-            - The Lowdefy version of your app.
-            - A random local app id (stored locally in your project folder at `.lowdefy/cli.json`).
-            - The CLI command used.
-            - If the CLI is being used in the Netlify CI environment (when using the `build-netlify` command).
-            - Your IP address.
-            - Error messages and stack traces for any errors.
-
-            # Blocks Server
-
-            The Lowdefy default blocks are not included in the Lowdefy build output, but are served from a CDN, and imported into the app using webpack module federation. All the default Lowdefy blocks are hosted at:
-
-            ```yaml
-            https://blocks-cdn.lowdefy.com/v{LOWDEFY_VERSION}/
-            ```
-
-            If you wish to host your own blocks instead, this url can be configured using the `--blocks-server-url` CLI option. This URL should serve the build artifacts of the Lowdefy default block packages (located in the `dist` directory). Each blocks package should be served under a path that corresponds to the package name. For example, `@lowdefy/blocks-basic` should be served under `{BLOCK_SERVER_URL}/blocks-basic/`. The required blocks packages and server paths are:
-
-              - `@lowdefy/blocks-basic` to be hosted at `{BLOCK_SERVER_URL}/blocks-basic/`.
-              - `@lowdefy/blocks-antd` to be hosted at `{BLOCK_SERVER_URL}/blocks-antd/`.
-              - `@lowdefy/blocks-color-selectors` to be hosted at `{BLOCK_SERVER_URL}/blocks-color-selectors/`.
-              - `@lowdefy/blocks-markdown` to be hosted at `{BLOCK_SERVER_URL}/blocks-markdown/`.
-              - `@lowdefy/blocks-echarts` to be hosted at `{BLOCK_SERVER_URL}/blocks-echarts/`.
-
-            If you wish to run the CLI dev server, the `@lowdefy/renderer` package build artifacts (located in the `dist` directory) should also be served from `{BLOCK_SERVER_URL}/renderer/`.
-
-      - _ref:
-          path: templates/navigation_buttons.yaml
-          vars:
-            previous_page_title: Overview
-            previous_page_id: overview
-            next_page_title: Lowdefy App Schema
-            next_page_id: lowdefy-schema

package/concepts/connections-and-requests.yaml

@@ -1,114 +0,0 @@
-# Copyright 2020-2021 Lowdefy, Inc
-
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-
-#     http://www.apache.org/licenses/LICENSE-2.0
-
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-_ref:
-  path: templates/general.yaml.njk
-  vars:
-    pageId: connections-and-requests
-    pageTitle: Connections and Requests
-    section: Concepts
-    filePath: concepts/connections-and-requests.yaml
-    content:
-      - id: md1
-        type: Markdown
-        properties:
-          content: |
-            ### TLDR
-              - `connections` define links to other services, like connecting to a database. They are defined at the root of the lowdefy configuration.
-              - `requests` use connections to make a call to the connected external services.
-              - Use the [`_secret`](/_secret) operator to reference API keys or other secrets as required - do not code secrets into your config or commit secrets to your config source control.
-
-            -----------
-            In a Lowdefy app you can integrate with other services like API's or databases using `connections` and `requests`. Connections configure the connection settings to the service, and often contain parameters like connection strings, urls and secrets like passwords or API keys. Requests are used to interact with the connection, like inserting a data record, executing a query or calling a API end-point.
-
-      - id: alert2
-        type: Alert
-        properties:
-          type: warning
-          showIcon: false
-          message: Sensitive information like passwords or API keys are often required to use external services. The _secret operator should be used to reference these secrets, they should never be coded directly in your app, or committed to source control.
-
-      - id: md2
-        type: Markdown
-        properties:
-          content: |
-            # Connections
-
-            Connections are defined at the root of your Lowdefy configuration, in the `connections` array. Each connection must have an `id`, a `type`, and `properties` defining the connection. Operators in connection properties are evaluated every time a request is called.
-
-            # Connection Schema
-
-            The schema for a Lowdefy connection is:
-
-            - `id: string`: __Required__ - A unique identifier for the connection. This is used by requests to specify which connection to use.
-            - `type: string`: __Required__ - The connection type to be used.
-            - `properties: object`: The settings passed to the connection. __Operators are evaluated__.
-
-            ###### Connections definition example:
-            ```yaml
-            lowdefy: LOWDEFY_VERSION
-            connections:
-              - id: connection1
-                type: ConnectionType1
-                properties:
-                  # ...
-              - id: connection2
-                type: ConnectionType2
-                properties:
-                  # ...
-            pages:
-              # ...
-            ```
-
-            Our goal is to make connections for everything. As the Lowdefy community grows, we will continue to develop the most requested connections. If the connection you require is not supported yet, please head over to our [new connections voting board](https://github.com/lowdefy/lowdefy/discussions/309) to request and vote for new connections.
-
-            # Requests
-
-            Requests can be defined on any block, and the results of the request are available to any block in the same context. Requests must have an `id`, `type`, `connectionId` field specifying the connection to use, and `properties` defining the request settings. Requests can be called using the [`Request`](/Request) action. Operators in request properties are evaluated every time a request is called.
-
-            # Request Schema
-
-            The schema for a Lowdefy request is:
-
-            - `id: string`: __Required__ - A identifier for the request. It must be unique within the context the request is defined in.
-            - `type: string`: __Required__ - The request type to be used. It must be a type supported by the connection type.
-            - `connectionId: string`: __Required__ - The `id` of the connection that should be used.
-            - `properties: object`: The settings passed to the request. __Operators are evaluated__.
-
-            ###### Requests definition example:
-            ```yaml
-            id: block_with_requests
-            type: BlockType
-            requests:
-              - id: request1
-                type: RequestType1
-                connectionId: connectionId1
-                properties:
-                  # ...
-              - id: request2
-                type: RequestType2
-                connectionId: connectionId2
-                properties:
-                  # ...
-            properties:
-              # ...
-            ```
-
-      - _ref:
-          path: templates/navigation_buttons.yaml
-          vars:
-            previous_page_title: Layout
-            previous_page_id: layout
-            next_page_title: Events and Actions
-            next_page_id: events-and-actions

package/concepts/context-and-state.yaml

@@ -1,82 +0,0 @@
-# Copyright 2020-2021 Lowdefy, Inc
-
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-
-#     http://www.apache.org/licenses/LICENSE-2.0
-
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-_ref:
-  path: templates/general.yaml.njk
-  vars:
-    pageId: context-and-state
-    pageTitle: Context and State
-    section: Concepts
-    filePath: concepts/context-and-state.yaml
-    content:
-      - id: md1
-        type: Markdown
-        properties:
-          content: |
-            #### TLDR
-              - The first block on a page must be a `context` category block.
-              - A page can have multiple `context` blocks.
-              - Every `context` has a single `state` object.
-              - All input blocks write their value to `state`, with the their `id` as the key in the `state` object.
-              - Input blocks which are not visible are removed from `state`.
-              - The `SetState` action can also modify the `state` object.
-
-            -------
-
-            A Lowdefy block with category `context` provides the environment for a part of a Lowdefy app to run in. More than one context can be placed on a page, but generally only one is needed. The first block on a page must be a `context` category block.
-
-            The standard page blocks like [`PageHeaderMenu`](/PageHeaderMenu) or [`PageSiderMenu`](/PageSiderMenu) are all `context` category blocks, and the [`Context`](/Context) block is a simple container that also provides a context.
-
-            Each context provides encapsulation to the blocks inside it. It has it's own `state` object as well as requests.
-
-            Every `input` category block inside the context will have a value in the `state` object, with the their `id` as the key in the `state` object, unless the block is not visible, in which case the input value is removed the state object.
-
-            The only other way to modify the `state` object is to use a `SetState` action. See [`SetState`](/SetState) and [`events-and-actions`](/events-and-actions) for more details.
-
-            Contexts remain even as users navigate to new pages, so if a user returns to a page, the state as they left it will remain.
-
-            # Url queries
-
-            A new context is created for each distinct URL query parameters seen by the app. This means that if a page is open with two different URL queries, two different contexts, with separate `state` objects will be created.
-
-            # Context IDs
-
-            Each context created has a identifier with the following structure:
-            ```
-            {pageId}:{blockId}:{JSON stringified urlQuery object}
-            ```
-
-            # Context data objects
-
-            A Lowdefy `context` makes some additional data object accessible via operators. These include:
-
-            - [`_global`](/_global): The `global` object is a single app level data object defined in the Lowdefy [config root](/lowdefy-schema). This object is the same for every `context`, it is also passed between the client and server. If the [`SetGlobal`](/SetGlobal) action is called, it is not consistent between clients, like different users, or a single user with multiple tabs open.
-
-            - [`_state`](/_state): A `state` object is unique to a `context` and every [`input` block](/blocks) maintains a value in it's parent `state` object. This `state` object is passed to the server when requests are called. The [`SetState`](/SetState) action can be used to modify the value of a `state` object in the same `context` from which `SetState` is called.
-
-            - [`_url_query`](/_url_query): The `urlQuery` object is used to access variables set in the url. Url query parameters can be set using the `urlQuery` field in the [`Link`](/Link) action. It can be useful to create sharable links containing some additional information other than the page route. For example setting a document id in the url so that the document can be retrieved when the link is opened during the page [`onEnter`](/events-and-actions) event. __Note that any variables set to `urlQuery` will be publicly visible__.
-
-            - [`_input`](/_input): The `input` object is unique to a page, and works similar to the `urlQuery` object. The `input` object is used to pass information between page transitions. This variable set to the `input` object are not written to the url, so they are not visible publicly but also cannot be used to share the data in a link since a `input` object is only consistent between one `context` and the next to which it links. A `input` object is set to the `input` field of the [`Link`](/Link) action when linking from one page `context` to the next.
-
-            - [`_media`](/_media): The `media` object contains some information about the client screen size etc. This is useful in order to add additional responsive logic to a page.
-
-            - [`_user`](/user-object): The `user` object contains the data in the user idToken if OpenID Connect authentication is configured and a user is logged in.
-
-      - _ref:
-          path: templates/navigation_buttons.yaml
-          vars:
-            previous_page_title: Lowdefy Schema
-            previous_page_id: lowdefy-schema
-            next_page_title: Blocks
-            next_page_id: blocks