glideapps / glideapps/expert-issues

Fields Component: Add Inline Templates, Media, Actions, and Field-Type Rendering

Open
#82 0 comments 2 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
5
Forks
0
PR merge metrics
No merged PRs in 30d

Description

Experts want the Fields component to evolve from a simple “label + value” list into a more powerful, table-like renderer. The request is to support inline templates for values, optional media (icon/image) placement, a clickable action/button per field row, and the ability to render certain values using field “types” (e.g., tag, dropdown/choice) directly within Fields.

## Current Problem
- Fields is limited to static label + value display, with minimal formatting controls.
- Builders can simulate richer layouts using Tables by splitting data across multiple columns (e.g., one column for text/tag, another for a button), then visually styling it to appear like one unit.
- For Fields, adding adjacent UI like actions or images requires separate components, which breaks the compact “details” layout Fields is intended for and often “doesn’t really work” in practice.

## Examples/Scenarios
- **Inline value formatting:** Builder wants to display a field value using templating (similar to inline templates elsewhere), e.g., `{{Department}} ({{Cost Center}})` without needing extra components.
- **Department row action:** In a department details view, the user sees “Department: Sales” and wants an icon/button on the right to “View chart for this department” (navigate or run an action). Today, this requires a Table workaround with multiple columns (text + button).
- **Media in-field:** Builder wants to show an icon or small image aligned left/right of the value (similar to Table cell formatting options), e.g., department logo, status icon, or avatar.
- **Tag/choice rendering:** Builder wants a field to render as a Tag or Choice-style value (like table cell types), rather than plain text.

## Why This Matters
- **Reduces workaround complexity:** Builders shouldn’t need to pivot to Table layouts just to get templating or a right-aligned action affordance.
- **Improves UX consistency:** Tables have richer “cell” presentation; Fields often appears visually outdated by comparison.
- **Enables more interactive detail views:** Per-field actions let users jump to relevant charts, screens, or workflows directly from a record’s details.
- **More compact, usable layouts:** Keeping media/actions inside the field row preserves the density and clarity Fields is meant to provide.

## Suggested UX
- **Inline Templates (Value Formatting)**
- Allow value text to use inline template syntax and/or a lightweight “template” editor per field row.
- Support mixing static text + dynamic tokens.

- **Media Support (Icon/Image)**
- Optional icon/image slot for each field row.
- Placement options: left of value, right of value, or replace label icon.
- Sizing constraints to keep Fields compact and consistent.

- **Per-Field Action / Button**
- Add an optional action target per row (like Button component actions).
- UI options:
- Right-aligned icon-only button
- Icon + text button (optional)
- Action triggers could include: navigate, open link, run action, show details, etc.

- **Field-Type Rendering**
- Let builders choose a “display type” for each field row (similar to table cell types), e.g.:
- Tag style
- Choice/dropdown style
- Link (already auto)
- Date (already fine)
- Boolean (already formatted)
- Keep defaults smart, but allow overrides when needed.

Notes:
- The goal is not to turn Fields into a full Table, but to bring the most valuable table-style presentation/interaction patterns into a record-detail-friendly component.

Video: https://share.xscorp.ca/XxccDmKJ

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.