@lowdefy/docs-content 0.0.0-experimental-20260928120643 → 6.1.0

package/content/operators/_error.md

@@ -25,7 +25,7 @@ Dot notation is supported for reading fields of the error, such as `_error: stat
 Inside a `:catch`, `_error` is an Error rebuilt from the caught error with only these fields:
 
 - `name`: The error class name, such as `RequestError`.
-- `message`: The real error message, with the values of known secrets (`_secret` values, `CRON_SECRET` and `BETTER_AUTH_SECRET`) replaced by `[REDACTED]`.
+- `message`: The real error message, with the values of known secrets (`_secret` values, `CRON_SECRET` and `AUTH_SECRET`) replaced by `[REDACTED]`.
 - `code`: The error's `code`, if it has one.
 - `statusCode`: The error's HTTP status, if it has one.
 - `handled`: `true` once the server has logged the error.
@@ -60,28 +60,6 @@ error:
 
 `code` and `statusCode` follow one rule across connection libraries. `code` is the error's own `code`, such as `ERR_BAD_REQUEST` from AxiosHttp or `11000` from MongoDB. `statusCode` is the first number among the error's `statusCode`, `status` and `response.status`. A request error takes both from the error the connection threw, so `_error: statusCode` reads the HTTP status of a failed `AxiosHttp` request without reading the cause.
 
-##### Service errors and rate limits
-
-A request that fails because of the service it calls, not its config, is a `ServiceError`: a network failure, a timeout, a 5xx response, or a rate limit (HTTP 429, including a provider's throttling error). Every other request failure is a `RequestError`. A routine can tell a rate limit from a fault and try again later:
-
-```yaml
-- :try:
-    - id: summarize
-      type: GenerateText
-      connectionId: claude
-      properties:
-        model: claude-haiku-4-5
-        prompt:
-          _payload: text
-  :catch:
-    - :if:
-        _eq: [{ _error: statusCode }, 429]
-      :then:
-        - :return:
-            status: busy
-    - :throw: Summary failed
-```
-
 #### Arguments
 
 ###### string

package/content/operators/_get.md

@@ -37,12 +37,12 @@ _get:
   key:
     _state: status
   from:
-    new: add-circle
-    escalated: CircleAlert
-    investigation_started: Wrench
-    client_contacted: Volume2
-    awaiting_confirmation: ThumbsUp
-    closed: Ban
+    new: AiTwoTonePlusCircle
+    escalated: AiOutlineExclamationCircle
+    investigation_started: AiTwoToneTool
+    client_contacted: AiTwoToneSound
+    awaiting_confirmation: AiOutlineLike
+    closed: AiOutlineStop
 ```
 Returns: The icon corresponding to the status in state.
 

package/content/operators/_operator.md

@@ -1,7 +1,7 @@
 # _operator
 
 ```
-(arguments: {name: string, params: any, operators?: string[]}): any
+(arguments: {operator: string, params: any): any
 ```
 
 The `_operator` operator evaluates an operator with the given params. This is useful if the operator needs to be chosen dynamically. The `_operator` cannot evaluate itself.
@@ -11,16 +11,15 @@ The `_operator` operator evaluates an operator with the given params. This is us
 #### Arguments
 
 ###### object
-  - `name: string`: The name of the operator to evaluate, such as `_sum` or `_number.round`. Names written in `name`, including the names an `_if` returns from `then` and `else` and a `_switch` returns from its branches, are loaded with the page.
+  - `operator: string`: The name of the operator to evaluate.
   - `params: any`: The params to give to the operator.
-  - `operators: string[]`: The operators the call may evaluate. Required when `name` is read at runtime, from state, a request or a payload: the build fails without it, loads exactly these operators with the page (or the server), and `_operator` refuses any other name. A listed operator (`_number`) allows all its methods; a listed method (`_number.round`) allows only that method.
 
 #### Examples
 
 ###### Get a value from `urlQuery` if specified, else use the value in `state`:
 ```yaml
 _operator:
-  name:
+  operator:
     _if:
       test:
         _eq:
@@ -32,16 +31,3 @@ _operator:
     key: field_to_get
 ```
 Returns: Value from `urlQuery` if `location_selector == url_query`, else the value from `state`.
-
-###### Apply an aggregation chosen by the user:
-```yaml
-_operator:
-  name:
-    _state: aggregation # _sum or _product
-  operators:
-    - _sum
-    - _product
-  params:
-    _state: values
-```
-Returns: The sum or product of `values`. Any other name in `aggregation` is refused.

package/content/operators/_ref.md

@@ -78,261 +78,3 @@ The file path to the referenced file, from the root of the project directory.
 > Within module content, the `module` field can reference a declared dependency name (from the module's `dependencies` in `module.lowdefy.yaml`). The build resolves abstract names to concrete entry IDs via the dependency wiring. From app-level config, `module` is always a concrete entry ID.
 
 #### Examples
-
-###### Reference pages:
-```yaml
-# lowdefy.yaml
-lowdefy: 6.0.0
-pages:
-  - _ref: pages/page1.yaml
-  - _ref: pages/page2.yaml
-```
-```yaml
-# pages/page1.yaml
-id: page1
-type: PageHeaderMenu
-blocks:
-  # ...
-```
-```yaml
-# pages/page2.yaml
-id: page2
-type: PageHeaderMenu
-blocks:
-  # ...
-```
-Returns:
-```
-lowdefy: 6.0.0
-pages:
-  - id: page1
-    type: PageHeaderMenu
-    blocks:
-      # ...
-  - id: page2
-    type: PageHeaderMenu
-    blocks:
-      # ...
-```
-
-###### Using a standardized input label template:
-```yaml
-blocks:
-  - id: name
-    type: TextInput
-    properties:
-      label:
-        _ref:
-          path: label.yaml
-          vars:
-            title: Name
-            description: Your name and surname.
-  - id: age
-    type: NumberInput
-    properties:
-      label:
-        _ref:
-          path: label.yaml
-          vars:
-            title: Age
-            description: Your age.
-```
-```yaml
-# label.yaml
-title:
-  _var: title
-extra:
-  _var: description
-span: 8
-colon: false
-extraStyle:
-  color: '#546358'
-```
-Returns:
-```yaml
-blocks:
-  - id: name
-    type: TextInput
-    properties:
-      label:
-        title: Name
-        extra: Your name and surname.
-        span: 8
-        colon: false
-        extraStyle:
-          color: '#546358'
-  - id: age
-    type: NumberInput
-    properties:
-      label:
-        title: Age
-        extra: Your age.
-        span: 8
-        colon: false
-        extraStyle:
-          color: '#546358'
-```
-
-###### Use key:
-```yaml
-# lowdefy.yaml
-lowdefy: 6.0.0
-version:
-  _ref:
-    path: package.json
-    field: version
-```
-```json
-// package.json
-{
-  "version": "1.0.0"
-}
-```
-Returns:
-```
-lowdefy: 6.0.0
-version: 1.0.0
-```
-
-###### Local or shared resolver:
-
-This resolver function will first look for the configuration file in the current working directory, but if the file is not found it will be read from an adjacent "shared" directory. This pattern can be used to build apps that mostly use a shared configuration, with a few components that are customised per app.
-
-```js
-// resolvers/useLocalOrSharedConfig.js
-const fs = require('fs');
-const path = require('path');
-const { promisify } = require('util');
-
-const readFilePromise = promisify(fs.readFile);
-
-async function useLocalOrSharedConfig(refPath, vars, context) {
-  let fileContent
-  try {
-    fileContent =  await readFilePromise(path.resolve(refPath), 'utf8');
-    return fileContent;
-  } catch (error) {
-    if (error.code === 'ENOENT') {
-      fileContent = readFilePromise(path.resolve('../shared', refPath), 'utf8');
-      return fileContent;
-    }
-    throw error;
-  }
-
-
-}
-
-module.exports = useLocalOrSharedConfig;
-```
-
-```yaml
-// lowdefy.yaml
-lowdefy: 6.0.0
-
-cli:
-  refResolver: resolvers/useLocalOrSharedConfig.js
-
-pages:
-  - _ref: pages/local-page.yaml
-  - _ref: pages/shared-page.yaml
-```
-
-###### This transformer adds a standard footer to each page:
-
-```js
-//  transformers/addFooter.js
-
-function addFooter(page, vars) {
-  const footer = {
-    // ...
-  };
-  page.areas.footer = footer;
-  return page;
-}
-module.exports = addFooter;
-```
-```yaml
-// lowdefy.yaml
-lowdefy: 6.0.0
-
-pages:
-  - _ref:
-      path: pages/page1.yaml
-      transformer: transformers/addFooter.js
-```
-###### Reference a module component:
-```yaml
-blocks:
-  - _ref:
-      module: notifications
-      component: notification-badge
-      vars:
-        position: top-right
-```
-
-###### Data export with key extraction:
-```yaml
-icon:
-  _ref:
-    module: events
-    component: event_types
-    key: login.icon
-```
-
-###### Cross-module component ref within a module:
-```yaml
-# contacts module embedding companies' selector
-blocks:
-  - _ref:
-      module: companies    # abstract dependency name
-      component: company-selector
-      vars:
-        field_id: company_id
-```
-
-###### Module menu inside a MenuGroup:
-```yaml
-menus:
-  - id: main
-    links:
-      - id: home
-        type: MenuLink
-        pageId: home
-      - id: team-admin
-        type: MenuGroup
-        properties:
-          title: Team Admin
-        links:
-          _ref:
-            module: team-users
-            menu: default
-```
-
-###### Using ES Modules with `.mjs` file extension:
-
-```js
-// resolvers/useLocalOrSharedConfig.mjs
-import fs from 'fs';
-import path from 'path';
-import { promisify } from 'util';
-
-const readFilePromise = promisify(fs.readFile);
-
-async function useLocalOrSharedConfig(refPath, vars, context) {
-  let fileContent
-  try {
-    fileContent =  await readFilePromise(path.resolve(refPath), 'utf8');
-    return fileContent;
-  } catch (error) {
-    if (error.code === 'ENOENT') {
-      fileContent = readFilePromise(path.resolve('../shared', refPath), 'utf8');
-      return fileContent;
-    }
-    throw error;
-  }
-
-
-}
-
-export default useLocalOrSharedConfig;
-```

package/content/operators/_type.md

@@ -29,7 +29,6 @@ The regex operator has shorthand argument definitions that can be used on web cl
     - `null`
     - `undefined`
     - `none` (`null` or `undefined`)
-    - `empty` (`null`, `undefined`, `''`, or `[]` - note that `0`, `false` and `{}` are not empty)
     - `primitive` (`undefined`, `null`, `string`, `number`, `boolean`, or `date`)
   - `on: any`: The value to test. One of `on` or `key` must be specified unless the operator is used in an input block.
   - `key: string`: The key of a value in `state` to test. One of `on` or `key` must be specified unless the operator is used in an input block.
@@ -61,23 +60,13 @@ Returns: `true` if a number.
 id: input
 type: TextInput
 validate:
-  - message: This field is required.
+  - message: This field id required.
     status: error
     pass:
       _not:
-        _type: empty
+        _type: none
 ```
-Returns: `true` if the input has a value. This is the test the `required` block field applies.
-
-###### Check if a value is empty:
-```yaml
-_type:
-  type: empty
-  on:
-    _state: selected_tags
-```
-Returns: `true` if `selected_tags` is `null`, `undefined`, `''` or `[]`, and `false` for any
-other value, including `0`, `false` and `{}`.
+Returns: `true` if the input is none.
 
 ###### Test if an id in the `urlQuery` is undefined or null:
 ```yaml

package/content/operators/_user.md

@@ -10,7 +10,7 @@
 }): any
 ```
 
-The `_user` operator gets a value from the [`user`](/user-object) object — the caller Lowdefy resolves for the signed-in user in their active organization. It has a [fixed shape](/user-object); see that page for the available fields.
+The `_user` operator gets a value from the [`user`](/user-object) object. The `user` object contains the data in the user idToken if OpenID Connect authentication is configured and a user is logged in.
 
 #### Arguments
 
@@ -50,7 +50,7 @@ Returns: The entire `user` object.
 ###### Dot notation:
 Assuming user:
 ```yaml
-id: abc123
+sub: abc123
 name: User Name
 my_object:
   subfield: 'Value'
@@ -76,7 +76,7 @@ Returns: The value of `might_not_exist`, or `"Default value"`.
 ###### Block list indices:
 Assuming `user`:
 ```yaml
-id: abc123
+sub: abc123
 name: User Name
 my_array:
   - value: 0

package/content/other/introduction.md

@@ -14,7 +14,7 @@ pnpx lowdefy@5 init && pnpx lowdefy@5 dev
 
 This will create a file called `lowdefy.yaml` in the current working directory that contains the configuration for a Lowdefy app (as well as a `.gitignore`) and launch a local development server at http://localhost:3000. Make changes in the `lowdefy.yaml` file to see them reflect in the app.
 
-> You need Node v24 or newer and pnpm installed to run Lowdefy. For more details see [the tutorial](/tutorial-start).
+> You need Node v22 or newer and pnpm installed to run Lowdefy. For more details see [the tutorial](/tutorial-start).
 
 ## Why create web apps using a YAML schema?
 

package/content/plugins/plugins-dev.md

@@ -31,7 +31,6 @@ Lowdefy uses the [`exports`](https://nodejs.org/api/packages.html#exports) packa
     "./auth/providers": "./src/auth/providers.js",
     "./blocks": "./src/blocks.js",
     "./connections": "./src/connections.js",
-    "./iconSets": "./src/iconSets.js",
     "./metas": "./src/metas.js",
     "./operators/client": "./src/operators/client.js",
     "./operators/server": "./src/operators/server.js",
@@ -68,7 +67,6 @@ export default {
   },
   blocks: ['Block'],
   connections: ['Connection'],
-  iconSets: ['my-icons'],
   requests: ['Request'],
   operators: {
     build: ['_build_operator', '_shared_operator'],
@@ -78,8 +76,6 @@ export default {
 };
 ```
 
-`iconSets` declares icon sets, which the `./iconSets` entry point exports as data. See [Icon Sets](/plugins-icon-sets).
-
 The type names do not need to be hard coded, and can be generated by importing the plugin types.
 
 ###### Example `types.js` for connections
@@ -115,20 +111,6 @@ export default extractBlockTypes(metas);
 
 The `extractBlockTypes` function returns `{ blocks, icons, blockMetas }` which the build pipeline uses to resolve plugin types without loading React components or heavy dependencies.
 
-A block that runs actions itself, through events it registers with `methods.registerEvent`, lists those action types in `meta.actions` and the operators their params use in `meta.operators`. Each page loads only the plugin code it uses, so the build adds these types to every page that uses the block:
-
-```js
-// src/blocks/MyUpload/meta.js
-export default {
-  category: 'input',
-  icons: [],
-  // Registers { id: 'policy', type: 'Request', params: { _event: 'requestId' } }
-  actions: ['Request'],
-  operators: ['_event'],
-  // ...events, properties
-};
-```
-
 See the [default Lowdefy block packages](https://github.com/lowdefy/lowdefy/tree/main/packages/plugins/blocks) for full examples.
 
 ### Named export files
@@ -151,54 +133,6 @@ Most types are written as standard Javascript functions, and blocks are written
 
 Lowdefy uses object [destructuring](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment) to provide parameters to the type functions. These parameters include the parameters or properties defined by the user in the Lowdefy configuration. Any operators used in the configuration will be evaluated before it is passed to the type function. Other relevant metadata and helper functions are also passed to the plugin function.
 
-### Lazy loading heavy blocks
-
-A page loads the code of every block type it uses before it renders. A block that pulls in a large library, such as a chat, a chart engine or a rich text editor, can make that code much bigger, even when the block sits in a closed drawer, an unopened tab or a modal. `createLazyBlock` from `@lowdefy/block-utils` loads such a block's implementation only when the block first mounts.
-
-Make a block lazy when it adds more than about 100 kB gzip to the page, **and** it is commonly off-screen at first paint or the page shows useful content without it. Otherwise keep it eager: a lazy block that is visible at first paint appears a moment later.
-
-Move the block's component into a file named `*.lazy.js`, and export a wrapper in its place:
-
-```js
-// src/blocks/MyChart/MyChart.js - exported from blocks.js as before
-import { createLazyBlock } from '@lowdefy/block-utils';
-import meta from './meta.js';
-import MyChartFallback from './MyChartFallback.js';
-
-export default createLazyBlock({
-  load: () => import('./MyChart.lazy.js'),
-  meta,
-  Fallback: MyChartFallback, // optional
-});
-```
-
-- `load` returns `import()` of the implementation, whose default export is the block component. Do not import the `*.lazy.js` file statically anywhere else, or it is bundled with the page again.
-- `meta` is the block's `meta.js` object. The wrapper copies it to `.meta`.
-- `Fallback` is optional. It renders while the implementation loads and receives the same props as the block. Use it to keep the block's size, or to show the part users see first, such as a launcher button. Without it the block renders nothing until it has loaded.
-
-The wrapper also has a `preload()` function, which starts the load and returns its promise. A `Fallback` can call it on hover.
-
-The `.lazy.js` name matters. In production, the Lowdefy server prefetches the `*.lazy.js` chunks of the blocks on a page, so the code is often in the browser cache by the time the block mounts. Other dynamic imports are never prefetched.
-
-###### Block methods
-
-Declare every method the block registers with `methods.registerMethod` in `meta.methods`:
-
-```js
-// src/blocks/MyChart/meta.js
-export default {
-  category: 'display',
-  methods: {
-    reset: 'Reset the zoom.',
-    download: 'Download the chart as an image.',
-  },
-};
-```
-
-The wrapper registers these methods as soon as the block mounts, so `CallMethod` works before the implementation has loaded. Calls made before then wait in order and run once the implementation has registered its methods. After that, calls go straight to the block, as for any other block. A waiting call fails if the block never registers that method, if the load fails, or if the block is removed first. A method that is not declared in `meta.methods` cannot be called before the block loads, and the dev server logs a warning when the block registers it.
-
-Do not spread the `methods` prop (`{ ...methods }`) in a lazy block's implementation; pass it on as it is.
-
 ### Localizing plugin strings
 
 Plugins can ship locale-keyed default messages so consumers see translated strings out-of-the-box, and translate strings at runtime via `methods.translate(key, values)` in block / action code. See [i18n](/i18n) for the full plugin-author contract — `./messages` export shape, `package.json` `exports` registration, namespacing convention, and merge precedence.

package/content/plugins/plugins-introduction.md

@@ -2,7 +2,7 @@
 
 Lowdefy plugins provides an interface to extend the platform functionality with custom javascript code. Plugins are installed into the Lowdefy app during the Lowdefy build process, and as a result are included as part of the Vite client build output. This enables plugin developers to use any npm packages when building Lowdefy plugins.
 
-Lowdefy plugins can be used to create custom blocks, connections, requests, action, operators and auth providers, adapters, callbacks and events. [Icon-set plugins](/plugins-icon-sets) add icons as data. These plugins are written as standard [npm modules](https://docs.npmjs.com/about-packages-and-modules#about-modules), so community plugins can be published to npm, and the workspace and git protocols can be used for project specific or private plugins. Since plugins are npm packages most Javascript features and third-party npm packages can be used in plugins.
+Lowdefy plugins can be used to create custom blocks, connections, requests, action, operators and auth providers, adapters, callbacks and events. These plugins are written as standard [npm modules](https://docs.npmjs.com/about-packages-and-modules#about-modules), so community plugins can be published to npm, and the workspace and git protocols can be used for project specific or private plugins. Since plugins are npm packages most Javascript features and third-party npm packages can be used in plugins.
 
 ## Using a plugin
 
@@ -27,29 +27,3 @@ plugins:
     version: 1.0.0
     typePrefix: Other
 ```
-
-## Plugin meta
-
-Every plugin type can describe itself to the build and to AI coding agents through a `meta` object. For blocks it is the `meta.js` next to the block (`category`, `valueType`, `initValue`, `cssKeys`, `events`, `properties`, ...), for requests it is the `meta` property on the request function (`checkRead`, `checkWrite`), and for operators a package may export a `./metas` module with one object per operator, mirroring `./schemas`.
-
-All three accept `meta.hazards`: a list of behaviours of the type that its schema cannot express, which the dev server's docs and MCP endpoint return to agents alongside the schema (see [AI agent docs](/ai-agent-docs)). Each hazard is:
-
-```yaml
-hazards:
-  - id: html-style-stripped # kebab-case, unique within the type
-    message: Content is sanitised with DOMPurify, so <style>, <script> and inline event handlers are removed. Use DangerousHtml for a trusted <style> block.
-    see: display-blocks/html # a docs slug, or null
-```
-
-The `message` is one or two plain sentences saying what happens and what to do instead. Only add a hazard for a behaviour that is verified in the plugin's code — an agent will rely on it.
-
-A block marks each property that holds a URL with `urlKind` in its `properties` schema: `url` for a link the engine opens (a colon-less value is read as `https://`), `href` for a link the browser opens, `src` for a resource the block loads, and `srcSet` for a list of sources. A [dynamic blocks policy](/dynamic-page-content#dynamic-blocks-policies) checks marked properties against its pages and origins whatever they are called. Every other property is judged by its name (`url`, `href`, `src`, `image`, ...), so a property whose name looks like a URL key but holds something else, such as a field name, is marked `urlKind: false`.
-
-```js
-properties: {
-  type: 'object',
-  properties: {
-    indexUrl: { type: 'string', urlKind: 'src', description: 'URL of the search index.' },
-  },
-},
-```

package/content/testing/e2e-configuration.md

@@ -14,7 +14,7 @@ export default createConfig();
 
 This will:
 - Look for your Lowdefy app in the current directory
-- Build and start the app's e2e server on port 3000, or reuse it if it is already running there
+- Build and start on port 3000
 - Run tests from the `e2e/` directory matching `**/*.spec.js`
 - Take screenshots only on failure
 
@@ -42,10 +42,6 @@ export default createConfig({
 });
 ```
 
-## Reusing a running server
-
-Playwright reuses a server that is already listening on the configured port, so starting it once with `pnpm e2e:server` in another terminal skips the build on later runs. Before any test runs, the config asks that server which build it serves. Any other server on the port, such as `lowdefy dev`, a production build, or the e2e server of another app or git worktree, stops the run with an error that names the port, instead of the tests running against it. Stop that server, or give each app or worktree its own `port`.
-
 ## Multi-app configuration
 
 If your project has multiple Lowdefy apps (for example, in a monorepo), use `createMultiAppConfig`:
@@ -85,8 +81,6 @@ export default {
 };
 ```
 
-Keep `globalSetup` from the base configuration (spreading `base` does), since it runs the server check. To add your own global setup, pass both: `globalSetup: [base.globalSetup, './global-setup.js']`.
-
 ## Environment variables
 
 The configuration sets these environment variables automatically:
@@ -95,7 +89,6 @@ The configuration sets these environment variables automatically:
 |----------|---------|
 | `LOWDEFY_BUILD_DIR` | Absolute path to build artifacts — used by test fixtures to generate the block manifest |
 | `LOWDEFY_E2E_MOCKS_FILE` | Absolute path to `mocks.yaml` — used by test fixtures to load static mocks |
-| `LOWDEFY_E2E_SERVERS` | Port and build directory of each app server — used by the global setup to check a reused server |
 
 ## Assertion timeouts
 

package/content/testing/e2e-getting-started.md

@@ -40,7 +40,7 @@ Run tests with the Playwright UI (useful for debugging):
 pnpm e2e:ui
 ```
 
-> The first run will take longer because Playwright needs to build and start your Lowdefy app. Later runs reuse the app's e2e server if it is still running (for example after `pnpm e2e:server`). If another server holds the port, such as `lowdefy dev`, the run stops with an error that names the port.
+> The first run will take longer because Playwright needs to build and start your Lowdefy app. Subsequent runs reuse the server if it is still running.
 
 ## Your first test
 

package/content/testing/e2e-introduction.md

@@ -24,7 +24,7 @@ The e2e server build exposes internal state on `window.lowdefy`, so your tests c
 
 ## Prerequisites
 
-- **Node.js 24+**
+- **Node.js 22+**
 - A working Lowdefy app (your app must build successfully)
 - **Playwright** (installed automatically during setup)
 

package/content/tutorial/tutorial-actions-operators.md

@@ -29,7 +29,7 @@ blocks:
         properties:
           title: Reset
           block: true
-          icon: Eraser
+          icon: AiOutlineClear
 ################ -------- Copy from here -------- ################
         events:
           onClick:
@@ -92,7 +92,7 @@ blocks:
           block: true
           color: primary
           variant: solid
-          icon: save
+          icon: AiOutlineSave
 ################ -------- Copy from here -------- ################
         events:
           onClick:

package/content/tutorial/tutorial-add-blocks.md

@@ -50,7 +50,7 @@ blocks:
           title: Reset
           block: true # Make the button fill all the space available to it
           type: default # Make the button a plain button
-          icon: Eraser
+          icon: AiOutlineClear
       - id: submit_button
         type: Button
         layout:
@@ -59,7 +59,7 @@ blocks:
           title: Submit
           block: true
           type: primary # Make the button a primary button with color
-          icon: save
+          icon: AiOutlineSave
 ################ -------- Copy to here ---------- ################
 ```