Local data

What this accomplishes

Store form submissions and tables locally — query, display, and export CSV.

The local data block is the storage for form submissions and other user-collected data in the maker surface. The data block is a typed database with a schema; the data block is stored in the user’s project directory; the data block is queryable from the Canvas and the data surface.

This page is the local data block. The form builder (which writes to the data block) is in form builder; the canvas builder (which uses the data block for gallery, table, and chart components) is in canvas builder.

Current availability

This page documents behaviour verified in Miton development builds. Miton is still pre-release and is not publicly downloadable; invited beta users will receive a signed desktop build with automatic updates.

Before you start

• A Miton development build, an active project and Canvas open.
• A connected model and permission to write project files when the task changes the app.

The data block schema

The data block has a schema. The schema is a list of fields, with the field type, the field name, and the field’s display label. The user can add a field; the user can remove a field; the user can rename a field; the user can change a field’s type.

The supported field types are:

• Text — a single-line text value.
• Long text — a multi-line text value.
• Email — a single-line text value with email validation.
• Number — a numeric value.
• Date — a date value.
• Boolean — a true / false value.
• Single-select — a value from a fixed list of options.
• Multi-select — a set of values from a fixed list of options.
• File — a reference to a file in the asset library.
• Reference — a reference to another data block.

The schema is per project. The user can export the schema as a JSON schema; the user can import a schema from a JSON schema file. The export and import are useful for sharing a schema across projects.

The schema enforces types on submission. A form that submits a non-numeric value to a number field is rejected. The user sees the rejection as a validation error in the form.

The local SQLite storage

The data block’s data is stored in a SQLite database in the user’s project directory. The database location is .miton/data/<dataBlockId>.db. The database is a standard SQLite file; the user can open the database in a third-party SQLite tool; the user can query the database with standard SQL.

The database is per project. The user can configure a shared database across projects; the shared database is in the user’s application data directory; the shared database is opt-in.

The database is observable. The user can see the database’s size, the number of records, the number of fields, the most recent submission timestamp. The user can also see the database’s schema in the inspector.

The data display

The data block’s data can be displayed in the Canvas as a gallery, a table, a chart, or a count. The user picks the display type in the inspector.

• Gallery — a grid of cards, each card showing one record. The user can configure the card’s fields; the user can also configure the card’s layout.
• Table — a tabular view, each row showing one record, each column showing one field. The user can sort by any column; the user can filter by any column; the user can also hide columns.
• Chart — a bar chart, a line chart, or a pie chart. The user can configure the chart’s data source (which field is the x-axis, which field is the y- axis); the user can also configure the chart’s appearance.
• Count — a count of the records, with an optional filter. The user can use the count in a metric card or a dashboard.

The data display updates in real time as new submissions arrive. The data display is per project; the user can have multiple data displays for the same data block (e.g. a gallery on one page, a chart on another page).

The data surface

The data surface is a CoW panel in the Canvas that shows every data block in the project. The data surface is a read-only view; the user can navigate between data blocks; the user can drill into a data block; the user can export a data block.

The data surface is per project. The data surface is the right shape for the user to see the project’s data at a glance; the data surface is not the right shape for the user to edit the data directly (the user uses the inspector for that).

The data surface also shows the submission history. The history is a chronological list of every submission, with the submission’s data, the submission’s timestamp, and the submission’s source (form, API, manual).

The CSV export

The data block’s data can be exported to CSV. The export is a download; the CSV is RFC-4180-compliant; the CSV is importable into a spreadsheet, a database, or a data-analysis tool.

The user can configure the CSV export in the inspector:

• Columns — the columns the user wants to include in the export. The user can include all columns, or include a subset.
• Header row — whether the export includes a header row. The default is yes.
• Date format — the format for date values. The default is ISO 8601.
• Encoding — the encoding for the CSV file. The default is UTF-8.
• Delimiter — the delimiter between values. The default is comma; the user can also pick tab, semicolon, or custom.

The CSV export is per project. The user can re-export the data at any time; the export is a snapshot of the data block’s current contents.

The live binding

The data block’s data can be referenced from other parts of the app. A gallery component can pull images from a data block. A chart component can pull counts from a data block. A text component can pull a value from a data block. The reference is a live binding; the displayed value updates when the data block updates.

The live binding is configured in the component’s properties. The user clicks the component; the user picks the data block; the user picks the field; the binding is created. The binding is preserved across sessions; the binding is re-evaluated when the data block updates.

The live binding is per component. The user can have multiple bindings in the same component (e.g. a gallery that displays the image from one field and the title from another field).

What the local data does not cover

The local data block does not cover:

• Multi-user collaboration on the data — the data block is per project; the user can share the data across machines, but the data is not real-time collaborative.
• Data analysis — the data block is a storage surface; the data block is not an analysis surface. The user can export the data to a third-party analysis tool (CSV export).
• Schema migration — the schema is a single version; the user can change the schema, but the user cannot migrate the data between schemas. The user can use a third-party tool for schema migration.

The local data block focuses on the per-project storage surface. The less common cases are covered by the user’s existing tools.

What success looks like

The local data block is the right shape for the user to store form submissions and other user-collected data. The data is typed; the data is local; the data is queryable.

The data display is the right shape for the user to show the data in the app. The user picks a display type (gallery, table, chart, count); the user configures the display; the display updates in real time.

The data surface is the right shape for the user to see the project’s data at a glance. The user can navigate between data blocks; the user can export a data block.

The CSV export is the right shape for the user to share the data with a third-party tool. The export is a snapshot; the user can re-export the data at any time.

The live binding is the right shape for the user to reference the data from other parts of the app. A gallery can pull images; a chart can pull counts; a text component can pull a value.

Common failures and recovery

• Confirm Canvas is editing the intended project and page.
• Check the selected breakpoint, project permissions and model connection.
• Reopen the last known-good project state before applying the change again.

Related next action

Return to the Canvas overview to choose the next part of the project.