Action Config

Type: FluiKitActionConfig.

Properties

Property	Type	Required	Description
`key`	`string`	No	Stable action key.
`enabled`	`boolean`	No	Enables or disables the action.
`label`	`string`	No	Visible action label.
`icon`	`string`	No	Iconify icon name.
`tooltip`	`string`	No	Tooltip text.
`ariaLabel`	`string`	No	Accessible label for icon actions.
`display`	`"button" \| "icon"`	No	Action display mode.
`iconOnly`	`boolean`	No	Icon-only display metadata.
`variant`	`"default" \| "primary" \| "secondary" \| "danger" \| "ghost"`	No	Visual variant.
`confirm`	`boolean \| FluiKitConfirmConfig`	No	Confirmation config.
`endpoint`	`FluiKitEndpointItem`	No	Endpoint override.
`method`	`FluiKitHttpMethod`	No	HTTP method override.
`handler`	`string`	No	Registry action handler key.
`permission`	`string \| string[]`	No	Required permission key(s).
`visibleWhen`	`FluiKitCondition`	No	Conditional visibility.
`disabledWhen`	`FluiKitCondition`	No	Conditional disabled state.
`refreshOnSuccess`	`boolean`	No	Refreshes list after success when runtime flow applies.
`className`	`string`	No	Action class name.

Resolution order

When an action runs, VibeFlui resolves what actually executes in this order:

action.handler (registry action handler key on the action itself)
schema.handlers[action.key] or schema.handlers[operation] (registry handler keyed by action/operation name)
schema.provider (a named runtime provider registered through FluiKitProvider, or the built-in REST provider when provider.type is "rest" and no name is set)
action.endpoint or schema.endpoint (REST-style endpoint config)

The first source that resolves wins. If both handler and endpoint are set on the same action, handler always runs and endpoint is ignored.

No-op behavior

If none of the sources above resolve — for example, an action references a handler key that was never registered, or has no endpoint/provider at all — VibeFlui does not throw an error. It displays success feedback assuming the operation completed, because VibeFlui only handles the FE/UI layer and is not responsible for backend results. The list still reloads and the form or dialog still closes as if a real request had succeeded.

Always wire a real handler, provider, or endpoint before treating an action as complete — an unwired action will look like it works in the UI even though no request was ever made.

Action groups

actions: {
  create: { enabled: true, label: "Create user" },
  edit: { enabled: true },
  delete: { enabled: true, variant: "danger", confirm: true },
  row: [
    { key: "invite", label: "Invite", handler: "users.invite" }
  ],
  bulk: [
    { key: "export", label: "Export selected", handler: "users.exportSelected" }
  ],
  toolbar: [
    { key: "sync", label: "Sync", handler: "users.sync" }
  ]
}

Handler example

const registry = createRegistry({
  actionHandlers: {
    "users.invite": async ({ row }) => ({
      status: true,
      code: 200,
      message: `Invite sent to ${String(row?.email ?? "user")}`
    })
  }
});