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

package/concepts/custom-blocks.yaml

@@ -1,190 +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: custom-blocks
-    pageTitle: Custom Blocks
-    section: Concepts
-    filePath: concepts/custom-blocks.yaml
-    content:
-      - id: warning
-        type: Alert
-        properties:
-          message: |
-            SECURITY WARNING: Blocks execute JavaScript inside your Lowdefy app. Insecure code can expose your app or data. Make sure that you only load blocks from a trusted source.
-          type: warning
-      - id: md1
-        type: MarkdownWithCode
-        properties:
-          content: |
-            Blocks in Lowdefy are simple, most often state-less, [React components](https://reactjs.org/docs/components-and-props.html). Lowdefy uses [webpack module federation](https://webpack.js.org/concepts/module-federation/) to implement a micro front-end strategy. This means blocks are imported at load time, and not part of the Lowdefy app build.
-
-            The decoupling of blocks provides the considerable advantages:
-            - Block developers can extend the UI capabilities of Lowdefy by building blocks for the community to utilize.
-            - Lowdefy app developers can use community blocks to experiment and extend their apps.
-            - Lowdefy blocks are simple, most often stateless React components, thus blocks can be developed quickly and can be used inside Lowdefy apps with ease.
-            - The build process is simple and fast since you only build the code for your block, and not the entire application.
-            - The Lowdefy engine takes care off the application state, the the block only has to concern itself with a easy application interface.
-
-            ## Using Custom Blocks
-
-            To use a custom block type inside a Lowdefy app, configure the `types` object in the root of the Lowdefy config. For example to use a AmCharts block we can add a `AmChartsXY` type to the `types`.
-
-            ```yaml
-            name: dashboard-app
-            lowdefy: 3.23.2
-            types:
-              AmChartsXY:
-                url: https://blocks-cdn.lowdefy.com/v3.10.1/blocks-amcharts/meta/AmChartsXY.json
-            # ...
-            pages:
-              - id: dashboard
-                type: PageHeaderMenu
-                blocks:
-                  - id: my_chart
-                    type: AmChartsXY
-                    properties:
-                      #...
-            #...
-            ```
-
-            By default Lowdefy build apps with a set of pre-configured, default block types to make it easier to build apps, for example using [`Button`](/Button), [`TextInput`](/TextInput), [`Box`](/Box), etc. All the blocks documented in the Lowdefy docs are default types. We will continue to build out this list of default blocks to make it as easy as possible to build excellent feature rich apps.
-
-            It is possible to overwrite the default a block type by simply defining a url for the default type in the `types` object. This is especially useful when you need to use a older version of a block, or would like to do something unique.
-
-            #### Examples of Custom Blocks
-
-            ##### AmCharts:
-
-            [AmCharts](https://www.amcharts.com/) enables you to render powerful javascript charts. We have created the [AmCharts Lowdefy blocks](https://github.com/lowdefy/blocks-amcharts) making it easy to use highly customizable charts in your apps.
-
-            ##### Ag-Grid:
-
-            [Ag-Grid](https://www.ag-grid.com/) enables you to render feature rich tables. We have created the [AgGrid Lowdefy blocks](https://github.com/lowdefy/blocks-aggrid) making it easy to use advanced tables in your apps.
-
-            ## Steps to develop a custom block
-
-            #### 1. Clone the blocks template repository
-
-            To develop a custom block, first clone the [Lowdefy blocks template repository](https://github.com/lowdefy/blocks-template). This template provides a project structure for building a custom block. This structure can be modified to your preferences with the following exceptions:
-            - Keep the webpack configuration to ensure your custom block works with Lowdefy block module federation.
-            - Blocks need meta data in the block schema format which Lowdefy uses to interpret how to render your block.
-
-            #### 2. Start your local block server
-
-            Once the repository is cloned, `yarn install` the block dependencies. Then start the local block server by running `yarn start`. The default is to start you block server on `http://localhost:3002`. Open `http://localhost:3002/meta/DisplayBlock.json` in your browser and confirm the the block meta data is served.
-
-            You can create multiple blocks in the same repository, or run multiple block servers from different block repositories. Use `yarn start --port {{ port_number }}` when you need to run multiple block servers.
-
-            #### 3. Configure your block types
-
-            In your `lowdefy.yaml` file, add your custom block type to the `types` object with the local path.
-
-            ```yaml
-            name: dashboard-app
-            lowdefy: 3.23.2
-            types:
-              MyCustomBlock:
-                url: http://localhost:3002/meta/MyCustomBlock.json
-            # ...
-            ```
-
-            You can then test your block locally by running `npx lowdefy@latest dev` to develop your Lowdefy app together with your custom block.
-
-            #### 4. Code your Lowdefy block
-
-            A Lowdefy block consist of two files, your schema file and your React component. With Lowdefy we try to keep blocks stateless and let the Lowdefy engine mange application state.
-
-            For most applications this is fine and it simplifies the block logic, the result is "smaller" blocks and more flexibility to the Lowdefy app builder. It is up to the block developer to decide how to balance the trade off between configurability and complexity of the block. For example, it might be better for a UI elements like a Calender to be state-full and packaged as one piece, rather than to break the Calender up into various smaller blocks, that Lowdefy app developers need to piece together. With that said, it is worth mentioning that every time the block properties changes, Lowdefy will rerender the entire block, this can have a performance impact when blocks become large and complex.
-
-            ### Block schema definition
-
-            - `category: enum`: How this block should be rendered in the Lowdefy app. Can be either `display`, `input`, `container`, `context` or `list`.
-            - `valueType: enum`: For blocks of the `input` block category, Lowdefy enforces a value type in `state`. This can be either a `boolean`, `number`, `string`, `object` or `array`. Lowdefy provides a default value for the block. This is usually `null`, but is `false` for boolean blocks, and the empty array, `[]`, for array blocks.
-            - `loading: boolean | object`: Settings for the default loading skeleton to render while the block is in a loading status. `false` will render an empty div element while `true` will render the default block skeleton based on the block category. Else an `object` can be provided for more refined settings, see the [loading placeholder types](/blocks) for more details  A Lowdefy app developer can over write these defaults by defining the `loading` settings when configuring a block.
-            - `schema: object`: Provide a valid [JSON-Schema](https://json-schema.org/) definition for the block `properties` and `events`.
-
-            ### Block React Component Props
-
-            The React component will receive the following props:
-
-            - `basePath: string`: The base path setting for the application. This variable is used to prefix route paths for example `${basePath}/public/logo-square-light-theme.png`. The default base path is ''.
-            - `blockId: string`: The block's id within the Lowdefy app, this is useful for setting a unique `id` on DOM elements.
-            - `components: object`: Helper React components that are exposed to blocks to use internally.
-              - `Icon`: component`: Lowdefy standard Icon React component to render build in icons.
-              - `Link`: component`: Lowdefy standard Link React component used as links to pages or external urls. The following props apply:
-                - `ariaLabel: string`: Arial-label to apply to link tag.
-                - `back: boolean`: When the link is clicked, trigger the browser back.
-                - `home: boolean`: When the link is clicked, route to the home page.
-                - `input: object`: When the link is clicked, pass data as the input object to the next Lowdefy page.  Can only be used with pageId link and newTab false. See [Input]( TODO: Link to input page? ).
-                - `newTab: boolean`: When the link is clicked, open the page in a new browser tab.
-                - `pageId: string`: When the link is clicked, route to the provided Lowdefy page.
-                - `rel: string`: The relationship of the linked URL as space-separated link types.
-                - `replace: boolean`: Prevent adding a new entry into browser history by replacing the url instead of pushing into history. Can only be used with pageId link and newTab false.
-                - `scroll: boolean`: Disable scrolling to the top of the page after page transition. Can only be used with pageId link and newTab false.
-                - `url: string`: When the link is clicked, route to an external url.
-                - `urlQuery: object`: When the link is clicked, pass data as a url query to the next page. See [url query]( TODO: Link to url query page? ).
-            - `content: object`: Passed to `container` and `context` block categories. The `content` object with methods to render sub blocks into content areas. The method name is the same as the area key, for example, 'content.content()` renders a blocks default `content` area.
-            - `events: object`: All events defined on the block in the Lowdefy app config.
-              - `[event_key]: object`: Event keys gives a handle name to the event details.
-                - `loading: boolean`: True while the list of actions are being executed.
-                - `actions: actionObjects[]`: The list of [Lowdefy action objects](https://docs.lowdefy.com/events-and-actions) which will be  evaluated by the Lowdefy engine.
-                - `history: object[]`: A list of objects logging the event calls and responses.
-                  - `blockId: string`: The block id from which the event was called.
-                  - `endTimestamp: datetime`: Timestamp for when the event was completed.
-                  - `event: object`: The event object passed to the event.
-                  - `eventName: string`: The event name which which triggerEvent was called.
-                  - `success: boolean`: True if all actions for the event executed without throwing any errors.
-                  - `startTimestamp: datetime`: Timestamp for when the event was started.
-                  - `responses: object`: The list of action responses, where the object key is equal to the action id.
-                    - `{{ key }}: string`:
-                        - `type: string`: The type of action called.
-                        - `error: Error`: If the action throw an error.
-                        - `index: number`: Index of the action in the event array.
-                        - `response: any`: The returned result of the action.
-                        - `skipped: boolean`: True if the action was skipped.
-            - `methods: object`: All application methods built into Lowdefy, available for the block.
-              - `makeCssClass(cssObject | cssObject[]): string`: This methods creates a css class for the block to apply to DOM elements. Css classes are created using [Emotion](https://emotion.sh/docs/introduction). If a list of cssObject are given the cssObjects are shallow merged with the preceding objects properties being overwritten by the latter. Any valid css style object can be passed, including media queries. Default media queries are built in:
-                - `xs?: object`: Css object applied for screen media with max width of 576px.
-                - `sm?: object`: Css object applied for screen media with min width of 576px.
-                - `md?: object`: Css object applied for screen media with min width of 768px.
-                - `lg?: object`: Css object applied for screen media with min width of 992px.
-                - `xl?: object`: Css object applied for screen media with min width of 1200px.
-                - `xxl?: object`: Css object applied for screen media with min width of 1600px.
-              - `registerEvent(event: { name: string, actions: actionObjects[] })`: This method can be used to register internal actions for the block to trigger, and overwrites the user config if user defined actions are provided for the same event name.
-              - `registerMethod(methodName: string, fn(any))`: This method allows the block developed to expose a method to the Lowdefy app developer via the [`CallMethod`](https://docs.lowdefy.com/CallMethod) action. When the method name for the block id is triggered via a `CallMethod` action, `fn` is evaluated.
-              - `triggerEvent({name: string, event?: any })`: This methods triggers a event when called, like `onClick` for when a button is clicked. Optionally, event data can be passed which will be available inside the event actions through the [`_event`](https://docs.lowdefy.com/_event) operator.
-            - `properties: object`: The properties object provides all the block settings defined in the Lowdefy config, operators can be used when defining block properties and evaluated operators are passed to the block. When the evaluated result of these properties change, the block rerenders to display the updated block.
-            - `required: boolean`: For blocks of the `input` category, whether or not a input value is required. Required can be defined by operators and the evaluated result is passed to the block. The [`Validate`](https://docs.lowdefy.com/Validate) action will check if the required values are present else raise `validation` errors and suspend further block actions in the event queue.
-            - `validation: object`: For blocks of the `input` category, the validation property provides result of `Validate` relevant relevant to the specific block. See [block validation](/blocks) for more details.
-              - `status: enum`: The validation status result. Can be `error`, `success` or `warning`. Only validation which results in an `error` status will suspend further block actions in the event queue.
-              - `errors: string[]`: The list of error messaged raised whiled block validation was evaluated, for this block.
-              - `warnings: string[]`: The list of warnings messaged raised whiled block validation was evaluated, for this block.
-
-            ## Deploying Custom Blocks
-
-            Both the block metadata and block React component need to be built by webpack and hosted on a publicly accessible static file server. Any Lowdefy app can then load and use the block. You also need to set the `remoteEntryUrl` in `webpack.prod.js` in order to build the correct block meta data, make sure the URL is pointing to where your block is hosted.
-
-            The easiest way to host your custom block is the deploy the custom block to [npm](https://www.npmjs.com/) and [Unpkg](https://unpkg.com/) will automatically host your block for you on their CDN. Although this option is easy, the cache settings for Unpkg can result in longer load times in some cases which can result in a unreliable user experience. It is thus best to deploy you blocks to your own static file servers.
-
-            We are working on a Lowdefy blocks CDN to improve this developer experience in the future.
-      - _ref:
-          path: templates/navigation_buttons.yaml
-          vars:
-            previous_page_title: Custom Code
-            previous_page_id: custom-code
-            next_page_title: User authentication
-            next_page_id: users-introduction

package/concepts/custom-code.yaml

@@ -1,197 +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: custom-code
-    pageTitle: Custom Code
-    section: Concepts
-    filePath: concepts/custom-code.yaml
-    content:
-      - id: warning
-        type: Alert
-        properties:
-          message: |
-            SECURITY WARNING: Custom code executes JavaScript inside your Lowdefy app. Insecure code can expose your app or data. Since Lowdefy doesn't validate your custom code, make sure that you only load trusted code.
-          type: warning
-      - id: md1
-        type: MarkdownWithCode
-        properties:
-          # TODO: Remove JsAction reference.
-          content: |
-            Lowdefy runs as a single page web app (SPA). It is possible to extend the functionality of a Lowdefy app by loading custom code (HTML, CSS and JavaScript) into the HTML `head` and `body` to of the default `index.html` page.
-
-            The content loaded into the `head` and `body` tag can be any valid HTML, most often `script` tags are loaded to register a new [`JsAction`](/JsAction) or [`_js`](/_js) operator. However, third party code can also be imported, for example Google Analytics, Intercom, etc. Be sure to only load trusted code into your app, as this code will be able to execute JavaScript on all pages of your Lowdefy app, which could expose you app or data to security vulnerabilities. Your own code can easily be hosted from the [Lowdefy public folder](/hosting-files).
-
-            > __Warning__: Lowdefy implements the [Ant design](https://ant.design/) UI component framework for app layout and most blocks, thus the default Ant Design CSS is loaded for all Lowdefy apps. Take caution not to unintentionally overwrite existing style settings and classes which can result in a degraded user experience.
-
-            ## Schema to load custom code
-
-            - `app.html.appendHead: string`: Any valid HTML content can be loaded just before the `</head>` tag of the Lowdefy app `index.html` file.
-            - `app.html.appendBody: string`: Any valid HTML content can be loaded just before the `</body>` tag of the Lowdefy app `index.html` file.
-
-            Most often it is convenient to abstract this HTML out to a separate file using the [`_ref`](/_ref) operator.
-
-            > __Warning__: Code imported using `appendHead` or `appendBody` will be loaded, and can execute JavaScript on every page of your Lowdefy app.
-
-            #### Examples
-
-            ###### Loading third party code snippet like Google Analytics:
-
-            To add [Google Analytics](/https://developers.google.com/analytics/devguides/collection/analyticsjs) to a Lowdefy app, the `lowdefy.yaml` can be setup with:
-
-            ```yaml
-            name: google-analytics-example
-            lowdefy: 3.23.2
-            # ...
-            app:
-              html:
-                appendHead: |
-                  <!-- Google Analytics -->
-                  <script>
-                  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
-                  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
-                  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
-                  })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
-
-                  ga('create', 'UA-XXXXX-Y', 'auto');
-                  ga('send', 'pageview');
-                  </script>
-                  <!-- End Google Analytics -->
-            # ...
-            ```
-
-            ###### Load, register and trigger a custom `JsAction` from code in the app `public` folder:
-
-            This example fetches a list of Todos from [{JSON}placeholder](https://jsonplaceholder.typicode.com/), and updates [state](/context-and-state).
-
-            1) First, add the JavaScript code to the `public` folder and resister the `JsAction`:
-            ```js
-            // /public/fetchTodos.js
-            function async fetchTodos(context, numItems, skip) {
-              const data = await fetch('https://jsonplaceholder.typicode.com/todos');
-              const todos = await data.json();
-              return todos.slice(skip, skip + numItems);
-            }
-            // Register the JsAction for the Lowdefy app to use.
-            window.lowdefy.registerJsAction('fetchTodos', fetchTodos);
-            ```
-
-            2) Import the JavaScript as a module into the page:
-            ```html
-            <!-- /header_modules.html -->
-            <script type="module" src="/public/fetchTodos.js"></script>
-            ```
-
-            3) Set load the custom code into the app header and trigger the action on page load:
-            ```yaml
-            # /lowdefy.yaml
-            name: json-todos
-            lowdefy: 3.23.2
-            app:
-              html:
-                appendHead:
-                  _ref: header_modules.html # Load the custom HTML into the header.
-            pages:
-              - id: todos
-                type: PageHeaderMenu
-                events:
-                  onEnter:
-                    - id: get_todos
-                      type: JsAction # TODO:
-                      params:
-                        name: fetchTodos # Trigger the custom JavaScript action.
-                        args:
-                          - 10   # numItems
-                          - 0    # skip
-                    - id: set_todos
-                      type: SetState
-                      params:
-                        todos:
-                          # Set the response of the get_todos action to state.
-                          _actions: get_todos.response
-                # ...
-            ```
-
-            ## Loading and registering a [`_js`](/_js) operator
-
-            Similar to the loading custom JavaScript actions, custom JavaScript operators can also be loaded. In order for the Lowdefy app engine to execute a custom JavaScript [operator](/operators), the JavaScript code for the operator must be loaded onto the page and registered using the `registerJsOperator` method available on the browser [`window`](https://developer.mozilla.org/en-US/docs/Web/API/window) object by calling `window.lowdefy.registerJsOperator(name: string, action: function)`.
-
-            All `_js` functions must be synchronous.
-
-            #### Examples
-
-            ###### Load, register and use a custom `_js` operator from code in the app `public` folder:
-
-            This example uses a `_js` operator to remove all duplicates from a list of names.
-
-            1) First, add the JavaScript code to the `public` folder and resister the `_js` operator:
-            ```js
-            // /public/foo_operators.js
-            function removeDuplicates(items) {
-              return [ ...new Set(items) ];
-            }
-            // Register the removeDuplicates function as a _js.deduplicate operator.
-            window.lowdefy.registerJsOperator('deduplicate', removeDuplicates);
-            ```
-
-            2) Import the JavaScript as a module into the page:
-            ```html
-            <!-- /header.html -->
-            <script type="module" src="/public/foo_operators.js"></script>
-            ```
-
-            3) Set load the custom code into the app header and use the new operator on the page:
-            ```yaml
-            # /lowdefy.yaml
-            name: operator-example
-            lowdefy: 3.23.2
-            app:
-              html:
-                appendHead:
-                  _ref: header.html # Load the custom HTML into the header.
-            pages:
-              - id: some_names
-                type: PageHeaderMenu
-                blocks:
-                  - id: names
-                    type: ButtonSelector
-                    properties:
-                      title: Select your new friend
-                      options:
-                      # use the removeDuplicates function and pass a list of names as a function argument
-                        _js.deduplicate:
-                          - - Anne
-                            - Sam
-                            - Joe
-                            - Micheal
-                            - Sam
-                            - Steven
-                            - Anne
-                            - Pepper
-                # ...
-            ```
-
-            ------
-
-            Custom code provides an easy way to extent the logic functionality of Lowdefy apps. However, to extend the UI capabilities beyond the existing features provided by the default Lowdefy blocks, custom blocks can be loaded onto apps.
-
-      - _ref:
-          path: templates/navigation_buttons.yaml
-          vars:
-            previous_page_title: Lists
-            previous_page_id: lists
-            next_page_title: Custom Blocks
-            next_page_id: custom-blocks

package/concepts/events-and-actions.yaml

@@ -1,224 +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: events-and-actions
-    pageTitle: Events and Actions
-    section: Concepts
-    filePath: concepts/events-and-actions.yaml
-    content:
-      - id: md1
-        type: MarkdownWithCode
-        properties:
-          content: |
-            ### TLDR
-            - Events are triggered when something happens on a page, like clicking a button or loading a page.
-            - A list of actions are executed sequentially by a triggered event.
-            - If an action errors, the actions that follow are skipped.
-            - Actions that are `async: true` will not executed sequentially nor stop the event if they error.
-            - Action errors can be handled by providing a list of `try` and `catch` actions to the event.
-            - Operators used in action `params` are evaluated right before the action is executed.
-            - The [`_actions`](/_actions)) operator is available for sequential actions to use the values returned from preceding actions in the chain.
-            - Actions have a `skip` field that can be used to skip action execution.
-            - The `onInit` event is triggered the first time a context is mounted and keeps the page in loading until all actions have finished.
-            - The `onEnter` event is triggered the every time a context is mounted and keeps the page in loading until all actions have finished.
-            - The `onInitAsync` event is triggered the first time a context is mounted and does not keep the page in loading.
-            - The `onEnterAsync` event is triggered the every time a context is mounted and does not keep the page in loading.
-
-            -----------
-
-            Blocks can define _events_ which the block can trigger when something happens on the page, like a button being clicked, an input's value being modified or a page being loaded. Some examples are `onClick` on a [`Button`](/Button) or `onEnter` on a [`PageHeaderMenu`](/PageHeaderMenu) block.
-
-            All blocks implements `onMount` and `onMountAsync` events. These are useful for triggering actions when a 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.
-
-            _Actions_ are tasks that can be executed, like calling a request, linking to a new page or changing a value in state. An array of actions can be defined for a event on a block. If that event gets triggered, those actions will execute sequentially. If any actions error while executing, the actions that follow it won't be executed, however, `catch` actions chain can be defined on a event to trigger when an error in a chain of actions occurs.
-
-            Actions which are `async: true` are an exception to the sequential rule of the actions chain. These actions will be executed asynchronously and the next actions in the chain will not wait for them to finish. If any `async: true` action throws an error, the chain will not be stopped and the event will still be completed successfully.
-
-            Each action has an `id`, unique to that action chain, and a `type` field which are required.
-
-            Actions can have a `params` field for specifying input parameters when executing the action. Operators used in action `params` will be evaluated right before the action is executed. Some events might have data relating to that event, like what the new value of an input is, or the row that was clicked in a table. The `event` object can be used in the action using the [`_event`](/_event) operator. Some actions also return values which can be passed to preceding actions in the same action chain using the [`_actions`](/_actions) operator.
-
-            Actions can also have a `skip` field. Operators in the `skip` field will be evaluated before an action is executed, and if the evaluated result is `true`, that action is skipped and the next action is executed.
-
-            # Action Schema
-
-            The schema for a Lowdefy action is:
-
-            - `id: string`: __Required__ - A identifier for the action. It must be unique within the action chain it is defined in.
-            - `type: string`: __Required__ - The action type to be used. It must be a valid action type.
-            - `skip: boolean`: The test that determines whether the action will be skipped or not. This is usually written as operators which evaluates to a `true` or `false`. __Operators are evaluated__.
-            - `async: boolean`: This determines whether the action will be evaluated asynchronously. Operators are __not__ evaluated on `async`.
-            - `messages: object`:  __Operators are evaluated__.
-              -  `error: boolean | string`: If `boolean`, whether an error message should be displayed if the action throws an error. Error messages are shown by default. If a `string`, the error message to show to the user.
-              -  `loading: boolean | string`: If `boolean`, whether a loading message should be displayed while the action is executing. Loading messages are not shown by default. If a `string`, the loading message to show to the user.
-              -  `success: boolean | string`: If `boolean`, whether a success message should be displayed if the action completes successfully. Success messages are not shown by default. If a `string`, the success message to show to the user.
-            - `params: object`: The input passed to the action. __Operators are evaluated__.
-
-            ###### Events and actions definition example:
-            ```yaml
-            - id: block_with_actions
-              type: Block
-              properties:
-                # ...
-              events:
-                onEvent1:
-                  - id: action1
-                    type: ActionType1
-                    skip:
-                      # Operator expression that returns true if action should be skipped.
-                    params:
-                      # ...
-                  - id: action2
-                    type: ActionType2
-                onEvent2:
-                  - id: action3
-                    type: ActionType3
-                    params:
-                      # ...
-            ```
-            # The actions object
-
-            When events are triggered, each completed action writes its response to the actions object under the action id object key. Thus all following actions in a event action list have access to the responses of all preceding actions in the same event list through the [`_actions`](/_actions) operator.
-
-            # The event object
-
-            When events are triggered, the can provide a data object describing the event (e.g. a description of the clicked item or uploaded file). This data object can be accessed using the [`_event`](/_event) operator in an action definition.
-
-            The schema for passing actions to Lowdefy events is:
-            ```
-              (eventName: action[])
-              (eventName: {
-                debounce?: {
-                  ms?: number,
-                  immediate?: boolean,
-                },
-                try: action[],
-                catch?: action[],
-              })
-            ```
-
-            # Catching action errors
-
-            If one action in the chain of event actions fails by throwing an error, the actions in the list following the failed action will not be executed. To handle any errors thrown by an action, Lowdefy event actions can be provided as lists of `try` and `catch` actions.
-
-            ###### Event try catch actions example for dealing with action errors:
-            ```yaml
-            - id: block_with_actions
-              type: Block
-              properties:
-                # ...
-              events:
-                onEvent1:
-                  try:
-                    - id: action1
-                      type: ActionType1
-                      params:
-                        # ...
-                    - id: action2
-                      type: ActionType2
-                  catch:
-                    - id: unsuccessful
-                      type: ActionType1
-                      params:
-                        # ...
-            ```
-
-            # Debouncing events
-
-            Event debouncing can be turned on by setting the `debounce` field on event objects. If `debounce.immediate` is `true`, leading edge debouncing or throttling will apply, else it will be debounced as trailing edge.
-
-            To control the debounce delay, set `debounce.ms` to the number of milliseconds to delay. The default delay is 300 milliseconds. If an event is triggered within that time, the event will not be triggered again. See [debounce vs throttling](https://redd.one/blog/debounce-vs-throttle) for a more detailed explanation.
-
-            ###### Event trailing edge debouncing example:
-            ```yaml
-            - id: block_with_actions
-              type: Block
-              properties:
-                # ...
-              events:
-                onEvent1:
-                  debounce:
-                    ms: 1000
-                  try:
-                    - id: action1
-                      type: ActionType1
-                      params:
-                        # ...
-                    - id: action2
-                      type: ActionType2
-            ```
-
-            ###### Event throttling or leading edge debouncing example:
-            ```yaml
-            - id: block_with_actions
-              type: Block
-              properties:
-                # ...
-              events:
-                onEvent1:
-                  debounce:
-                    ms: 1000
-                    immediate: true
-                  try:
-                    - id: action1
-                      type: ActionType1
-                      params:
-                        # ...
-                    - id: action2
-                      type: ActionType2
-            ```
-
-            # Context initialisation events
-
-            Four events are always defined for [`context`](/context) type blocks, called in the following order:
-              - `onInit`
-              - `onEnter`
-              - `onInitAsync`
-              - `onEnterAsync`
-
-            These events can be used to initialize the context or page.
-
-            The `onInit` event is triggered the first time a context is mounted, for example if a page is loaded for the first time. This event blocks page render, in other words, the page __will__ remain in a loading state until all the actions have completed execution. It can be used to set up a context. Actions that take a long time to execute, like `Request`, should be used sparingly here.
-
-            The `onEnter` event is triggered every time a context is mounted to a page, for example if a user left a page, and returns to it. This event also blocks page render. It can be used to execute actions that should be run each time a page is loaded, like checking if an id is present in the [url query parameters](/_url_query), and initializing the [`state`](/context-and-state).
-
-            The `onInitAsync` event is triggered the first time a context is mounted, but does not block page render. In other words, the page __will not__ remain in a loading state until all the actions have completed execution. This is a good place to execute non-blocking tasks or requests that might take longer to execute.
-
-            The `onEnterAsync` event is triggered every time a context is mounted, but does not block page render.
-
-            # Action types
-
-            The following actions can be used:
-
-            - [`CallMethod`](/CallMethod) - Call a method defined by another block.
-            - [`JsAction`](/JsAction) - Call a custom JavaScript function as an action.
-            - [`Link`](/Link) - Link to another page.
-            - [`Message`](/Message) - Show a message to the user.
-            - [`Notification`](/Notification) - Show a notification to the user.
-            - [`Request`](/Request) - Call a request.
-            - [`Reset`](/Reset) - Reset the page validation and `state`.
-            - [`ScrollTo`](/ScrollTo) - Scroll to a point on the page.
-            - [`SetGlobal`](/SetGlobal) - Set a value to the `global` variable object.
-            - [`SetState`](/SetState) - Set a value to the page `state`.
-            - [`Validate`](/Validate) - Validate the inputs on the page.
-      - _ref:
-          path: templates/navigation_buttons.yaml
-          vars:
-            previous_page_title: Connections and Requests
-            previous_page_id: connections-and-requests
-            next_page_title: Operators
-            next_page_id: operators