Support Best Practices

Use support requests as a way to make the schema, registry, and example clearer.

Reduce the problem

Before reporting an issue, remove anything unrelated:

• Keep one resource schema.
• Keep one table, form, detail, or dashboard view.
• Keep only the custom renderers involved.
• Replace private data with small sample rows.
• Replace real endpoints with a short response example when possible.

Separate the layers

Most VibeFlui issues become easier to solve when files are separated clearly:

• Schema files describe UI intent.
• Registry files connect schema keys to renderers, handlers, and helpers.
• Component files contain reusable JSX.
• Page files compose FluiKit and pass data or handlers.
• Service files call backend APIs when the app needs server data.

This separation also makes examples easier to render in the official docs.

Prefer source-aligned wording

When writing docs or issue reports, avoid claiming that a feature is supported until it is verified in the current VibeFlui package.

Use precise language:

• "The schema accepts this key" when only the schema is verified.
• "The runtime renders this behavior" when the renderer is verified.
• "The provider executes this flow" when provider behavior is verified.

Keep examples runnable

Examples should be small, realistic, and ready to render.

Avoid:

• Inline async mutation functions inside FluiKit props.
• JSX embedded directly in registry objects.
• Placeholder schema keys that are not available in the current source.
• Backend-only examples without a local fallback.
• Large user-management examples for every advanced feature.

Prefer reusable sample domains such as products, invoices, support tickets, content review, inventory, subscriptions, or project tasks.