本文へ移動
cccskills
無料GitHub で公開

nuxt-ui-tools-table-runtime

Use this skill when implementing, refactoring, or extending the internal table runtime inside this repository. Covers the current architecture layers, state model, composable flow, where different responsibilities live, how to add features cleanly, and what kinds of refactors are encouraged.

インストール方法を見る

含まれるファイル(2)

  • SKILL.md6.1 KB
  • references/architecture.md6.1 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

nuxt-ui-tools Table Runtime

Use this skill for internal repository work on:

  • table runtime architecture
  • table state management
  • composables
  • runtime components
  • schema/builder internals
  • adding new table capabilities
  • refactoring table internals

Read First

  • AGENTS.md
  • .agents/skills/nuxt-ui-tools-maintainer/SKILL.md
  • .agents/skills/nuxt-ui-tools-table-runtime/references/architecture.md

Current Mental Model

The current table runtime is a schema-driven system with these major layers:

  1. public schema and public entrypoints
  2. schema/building and normalization helpers
  3. reactive orchestration in composables
  4. pure or mostly pure utilities
  5. rendering components
  6. playground integration surface

The important split is:

  • public shape and schema definition
  • runtime orchestration
  • pure transformations
  • rendering

Do not collapse those layers together.

Current File Routing

Start from these depending on the task:

  • public package surface: src/runtime/table/index.ts
  • schema definition entry: src/runtime/table/schema/index.ts
  • internal orchestration root: src/runtime/table/composables/use-table-internals.ts
  • public table API shape: src/runtime/table/composables/use-table.ts src/runtime/table/composables/use-table-api.ts
  • query-state bridge: src/runtime/table/composables/use-query-state.ts
  • data orchestration: src/runtime/table/composables/use-table-data.ts
  • columns pipeline: src/runtime/table/composables/use-table-columns.tsx src/runtime/table/utils/columns/*
  • filter pipeline: src/runtime/table/composables/use-table-filters.ts src/runtime/table/composables/use-table-filter-presentation.ts src/runtime/table/composables/use-table-filter-options.ts src/runtime/table/utils/filters/*
  • rendering shell: src/runtime/table/components/DataList.vue src/runtime/table/components/data-list/*
  • data-list UI and viewport contexts: src/runtime/table/composables/use-data-list-ui.ts src/runtime/table/composables/use-data-list-viewport.ts

Important Current Reality

The current implementation works, but it is not the final shape.

There are known improvement targets:

  • reduce reactive waste
  • reduce layers of derived state
  • simplify query-state integration
  • move toward cleaner structure
  • preserve or improve inference while simplifying internals

Do not treat the current layering as sacred. If an abstraction is wasteful or too indirect, refactor it.

Feature-Addition Rules

When adding a table feature:

  1. identify the public contract first
  2. decide whether it belongs in schema, API, runtime orchestration, pure utils, or rendering
  3. keep normalized or config-driven handling when multiple variants exist
  4. isolate variant-specific behavior behind a shared contract
  5. update tests, playground, and consumer skills when the surface changes

Preferred shape:

  • schema-facing definition in types/schema/building layer
  • normalization or resolution in utils
  • orchestration in composables
  • view-only consumption in components

Avoid:

  • burying domain logic directly in components
  • feature behavior implemented only in playground
  • one giant helper handling every variant inline

Specific Internal Guidance

State

  • prefer one strong state abstraction over many computed bridges
  • avoid derivation of derivation of derivation
  • avoid temporary reactive wrappers when direct state modeling is possible
  • if local draft state exists only to mirror another reactive source, reconsider the abstraction

Columns

  • columns are a pipeline, not a flat render blob
  • runtime columns, ordering, visibility, pinning, menu items, and render adapters should stay separated

Filters

  • filters should be definition-driven
  • filter definitions currently organize around behavior, display, source, editor, and preview
  • each filter kind should have standardized behavior and isolated implementation where logic is non-trivial
  • preview generation is a good model: normalized contract plus per-kind implementation files
  • filter presentation is a separate orchestration concern from filter semantics
  • client facet counts belong to the data/query engine, not the filter render layer

Components

  • DataListRoot.vue owns provider and lifecycle behavior while rendering no mandatory wrapper
  • DataList.vue is the stable assembled recipe and must be built from the same public parts consumers compose directly
  • granular parts own rendering only and must consume prepared state from table internals
  • popup parts expose a standard custom trigger slot; full and incremental data states stay separate
  • every granular part exposes a typed flat ui slot map; page defaults belong to DataListRoot.ui, while underlying Nuxt UI primitives retain application theme inheritance
  • renderer internals should consume prepared state rather than reinvent logic

Pagination

  • pagination is a none, offset, or cursor strategy selected by schema
  • only offset page and size state is URL-backed; cursor accumulation stays in TanStack infinite-query state
  • filter, search, and sorting owners call the pagination reset command instead of writing page fields
  • cursor pages flatten and de-duplicate by rowKey; loaded and total counts remain distinct
  • the public API is conditional so offset-only and cursor-only commands do not leak across schema modes

When To Reorganize

Reorganize without hesitation when:

  • a file is carrying multiple unrelated concerns
  • a feature introduces another variant into a growing domain
  • the state model is becoming layered and wasteful
  • a top-level folder should really become a subdomain under utils/

Builder-specific note:

  • existing top-level src/runtime/table/builders is transitional
  • prefer the long-term direction of utils/builders/ when touching or growing builder code

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Use this skill when working with the nuxt-ui-tools package as a consumer or integrator. It provides the current package overview and routes to table, form, dashboard, file preview, query-state, shared responsive helpers, remote option loaders, and i18n usage.

日本語の概要は準備中です。原文の説明を表示しています。

ChronicStone/nuxt-ui-tools22026年10月8日 更新

Use this skill for internal architecture work around config-driven, registry-driven, and pattern-driven feature design in the nuxt-ui-tools repository. Covers how to organize variant-heavy features, where to put implementations, and how to keep both internals and public APIs standardized.

日本語の概要は準備中です。原文の説明を表示しています。

ChronicStone/nuxt-ui-tools22026年10月8日 更新

Use this skill when building analytics dashboards with nuxt-ui-tools as a package consumer. Covers schema and view functions (defineDashboardSchema, defineDashboardView) that take their context as typed params, useDashboard with a getter that rebuilds on input change, typed injection (useDashboardView, injectDashboard, InferDashboard, InferDashboardView), filters declared inline with the f builder and synced with the URL, memory, or an external store (one value per key across views), headless filters, filter controls and the shipped UI (UiDashboardPage, UiDashboardFilters, UiDashboardFilter, UiDashboardViewTabs) with slot overrides, remote paginated pickers and remoteTableOptions, staged queries (essential / background / deferred) with select and dependent requires, lazy enabled conditions on views, queries, and filters (blocks of disabled queries hidden, grids closing up), derived values, views (tabs), query-scoped filters, number formats (presets, Intl options, useDashboardFormat), and the dashboard blocks (stats with trends, goals, and comparisons, stat groups, gauges, unovis charts with highlights, value labels, and totals, lists with progress rings, bars, funnel, alerts, activity feeds, sortable tables, custom widgets) with their automatic loading, error, empty, and refresh states, card menus, header and footer actions, row actions, drill-down and selected state, card tabs, split cards, comparison periods, auto-refresh, and data freshness.

日本語の概要は準備中です。原文の説明を表示しています。

ChronicStone/nuxt-ui-tools22026年10月8日 更新

Use this skill when previewing files with nuxt-ui-tools as a package consumer. Covers mounting UiFilePreviewProvider, opening one file or a gallery with useFilePreview() or useNuxtApp().$filePreview, file descriptors (URL, File/Blob, or a function that returns a signed URL), options (index, mode, gallery, loop, pdf page, callbacks), the returned handle, the built-in renderers (image, video, audio, PDF, text/JSON, CSV, Markdown, Office and archive fallbacks), renditions, download and custom header actions, the markdown render hook, custom renderers with defineFilePreviewRenderer and UiFilePreviewTools, theming tokens, and how the upload field uses the preview.

日本語の概要は準備中です。原文の説明を表示しています。

ChronicStone/nuxt-ui-tools22026年10月8日 更新

Use this skill when working with the nuxt-ui-tools form runtime as a package consumer. It covers schema-driven forms, the provider-backed form API, inline rendering, overlay rendering, form pages with a section navigation, choice cards, and typed submit results.

日本語の概要は準備中です。原文の説明を表示しています。

ChronicStone/nuxt-ui-tools22026年10月8日 更新

Use this skill for internal i18n work in this repository. Covers locale ownership, provider wiring, lazy schema text contracts, and the maintenance surfaces that must stay in sync when package or playground translations change.

日本語の概要は準備中です。原文の説明を表示しています。

ChronicStone/nuxt-ui-tools22026年10月8日 更新

ChronicStone のスキルをすべて見る

このスキルの問題を報告する