Fetcher Viewer Components

fetcher-viewer-components

Workflow

1. Choose FetcherViewer for the full data-loading and view-persistence orchestrator.
2. Choose Viewer or View when the caller controls loading, persistence, or layout state directly.
3. Define field, filter, column, action, and pagination contracts before composing components.
4. Use registries for filter and cell customization instead of scattering one-off render logic.
5. Load references/api.md for prop maps, component hierarchy, filter/cell examples, and integration patterns.

Key Practices

• Keep operational UI dense and predictable; avoid marketing-style layouts around viewer components.
• Prefer typed cell renderers and filter components over ad hoc table render functions.
• Route data-fetching hook questions to fetcher-react-hooks unless the table/viewer integration is central.

References

• references/api.md: Detailed package API, examples, and edge-case guidance. Load it only when the task needs component hierarchy, package imports, FetcherViewer props, Viewer and View examples, filter system, cell components, data entry controls, locale support, and React hook integration.

Related Skills

• $fetcher-react-hooks: Use for data-fetching and query state hooks.
• $fetcher-wow-cqrs: Use for Wow query clients backing viewer data.
• $fetcher-cosec-auth: Use when viewer data access is tenant or policy aware.