@lowdefy/docs 3.23.2 → 4.0.0-alpha.10

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

package/concepts/custom-blocks.yaml

@@ -1,176 +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.
-            - `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,196 +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:
-          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
-                      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