Common Mistakes

This page collects common provider and endpoint mistakes that cause confusing runtime behavior.

Expecting automatic loading while passing data

FluiKit only runs automatic list loading when both data and response are omitted.

TSX

// Host app owns loading because response is provided.
<FluiKit schema={usersSchema} response={usersResponse} />

Expecting provider functions in schema

Provider functions belong in FluiKitProvider, not in JSON-friendly schema.

TSX

<FluiKitProvider providers={{ admin: adminProvider }}>
  <FluiKit schema={usersSchema} />
</FluiKitProvider>

Mixing handlers and endpoints unintentionally

Handlers win over providers and endpoints. If an action has a handler, the endpoint is still resolved for context but the handler executes.

Missing identity values

Update/delete/action URLs usually need an identity value from the row.

identity: {
  key: "id",
  param: "id"
}

If the row does not contain that key, the URL placeholder remains unresolved.

Wrong server-mode response path

If rows are nested under data.items, configure table.dataPath.

table: {
  dataPath: "data.items",
  totalPath: "data.total"
}

Treating schema-only provider types as runtime integrations

provider.type can describe a kind of provider, but VibeFlui only creates a built-in provider automatically for REST-style endpoint execution. Other provider types need runtime provider functions or plugins.

Returning unclear failure responses

Prefer responses with status, code, and message.

JSON

{
  "status": false,
  "code": 409,
  "message": "Email is already registered."
}

Calling production APIs from local demos

Demos should use mock data, mock providers, or static responses. Examples should not create backend services.