MetaTypes CRUD

Purpose

Use metaTypesCrud for a focused administrative surface that lists root MetaTypes and creates, updates, or deletes a MetaType.

When to use

Choose it when users need only basic MetaType maintenance. Choose Core Apps dataModel when they also need MetaLinks, attributes, methods, lifecycle templates, or permissions.

Prerequisites and ownership

• The user and deployed API must allow MetaTypes read/write operations.
• The panel integration owns API calls, loading state, root reloads, and toast feedback.
• Installed @ornn-mes/metatypes-crud-panel@2.2.0 owns the TreeTable UI, forms, and emitted create/update/delete intents.
• There are no variant-specific JSON options beyond type.

Capability map

Area	Supported behavior
Initial data	Loads children of root_type on mount
Display	Package-owned MetaType TreeTable
Create	Posts a one-item array to /MetaTypes, reports success/error, then reloads roots
Update	Puts the edited payload to /MetaTypes/{typeName}, then reloads roots
Delete	Deletes /MetaTypes/{typeName}, then reloads roots
State	Shared loading state and current root items
Helpers	Store exposes detail and child fetch helpers, but the current wrapper does not connect them to package events

Behavioral model

Mounting fetches root types and maps them to TreeTable nodes. Package UI emits a CRUD intent; the panel store performs the API operation, shows feedback, and re-fetches root nodes. JSON config does not alter fields, endpoints, hierarchy, or package UI.

Alternatives, defaults, and precedence

metaTypesCrud has one mode and no variant-specific defaults. Common panel layout and visibility still apply. For the broader data-model workflow, use coreApps with app: "dataModel".

Limitations

• The wrapper renders only the package's current root/CRUD flow.
• fetchChildren and fetchType exist in the store but are not wired by the current wrapper; do not claim lazy hierarchy or detail loading from them.
• API endpoints, MetaType schema, validation, and form fields are not configurable in panel JSON.
• The local fixture is disposable and in-memory; it does not reproduce backend authorization, validation, persistence, or concurrent edits.
• Fixture mutations are shared within one demo server process and reset only when that process restarts. The linked demo therefore targets an isolated single-session or access-restricted documentation deployment, not a shared public multi-user service.

Minimal configuration

{
  "id": "metatypes",
  "type": "metaTypesCrud"
}

Scenario: dedicate an administration application

{
  "version": "1.0.0",
  "layout": { "padding": true },
  "panel": {
    "id": "metatypes-administration",
    "type": "metaTypesCrud",
    "ui": {
      "title": {
        "en": "MetaTypes",
        "ru": "Метатипы"
      }
    }
  }
}

Expected result: the application loads root MetaTypes and exposes the package create/update/delete controls allowed by the current user.

Runnable demos

Open the stateful MetaTypes CRUD demo

The demo mounts the installed package UI through the real metaTypesCrud renderer. It loads two full root MetaTypes from GET /MetaTypes/ByParent/root_type; create, edit, and delete use the same POST /MetaTypes, PUT /MetaTypes/{typeName}, and DELETE /MetaTypes/{typeName} calls as the panel store. Each mutation re-fetches the root list. Data is isolated in the local fixture server and resets on server restart.

Validate the same journey against a development API before giving users delete access because the fixture intentionally does not model production permissions or validation.

Exact parameter reference

• panel.type

The absence of variant rows is intentional: metaTypesCrud exposes no variant-specific JSON configuration.

Related guides and next task

• Core Apps Data Model
• Common panel configuration

Next, exercise list, create, update, delete, feedback, and root refresh in the local demo, then repeat the permission and validation checks against the deployed MetaTypes API.