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

[nocodeandy]

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