Composing Tuffex Interfaces

This guide targets Tuff / Dashboard / Admin pages. The goal is not to add more components; it is to structure a page as “actions → status → data” so users can understand state and act quickly.

Component Suites & Imports

Tuffex is organised into three suites: Basics (base), Advanced (pro) and AI (ai). Besides the full package, you can import per suite from the category entries to keep dependencies organised:

import { TxButton, TxDataTable } from '@talex-touch/tuffex/base'
import { TxCommandPalette, TxLiquid } from '@talex-touch/tuffex/pro'
import { ChatList, TxPromptBar } from '@talex-touch/tuffex/ai'

The union of the three entries is identical to the main @talex-touch/tuffex entry; styles are still loaded from @talex-touch/tuffex/style.css, or per component via each style.css. See the components overview for each component's suite.

1. Page Groups

2. Minimal Working Slice

3. Search And Filter Path

Do not split “enter keyword”, “choose scope”, and “no matches” into disconnected regions. Compose TxSearchInput, TxSearchSelect, and TxSearchEmpty inside one filter container so users can see active conditions, match count, and recovery actions together.

4. Operations Status Header

Dashboard / Admin pages should first answer “is the system healthy?”. Structure the first screen in this order:

5. Trend Sections

Dashboard trend charts should reuse DashboardSparklineChart / DashboardMetricChart instead of page-local svg polylines. This keeps tooltip behavior, dark theme styling, ResizeObserver resizing, and empty states consistent.

6. Data Recovery Paths

Every data panel needs three recovery paths: loading, no data, and request failure. They should occupy the same container to avoid layout jumps and duplicated placeholders.

7. Data Lists And Pagination

Dashboard data regions should keep “table body, selection state, pagination, and loading placeholders” inside one workspace. The table should not own ad-hoc status copy, pagination should stay near the table footer, and longer waits should preserve space with skeletons.

8. Task Feedback Path

Admin task feedback should split “action explanation, result notification, local blocking, and inline waiting” into separate roles: TxTooltip explains the button, TxToastHost shows short feedback, TxLoadingOverlay blocks a refreshing data block, and TxSpinner is only for short waits without percentages.

9. Permission Orchestration Path

Admin authorization pages should first answer “which scope is being authorized?”, then “who owns it, which resources are granted, and where is the audit flow?”. Use TxTree for left-side scopes, TxTreeSelect for owner teams, TxTransfer for resource grants, and TxTimeline for audit progress.

10. Navigation And Configuration Shell

Dashboard settings pages should first answer “which section am I in?”, then answer “what can I do here?”. Keep first-level sections in TxTabs, one-off actions in TxDropdownMenu, short explanations in TxPopover, and dense configuration in TxDrawer.

11. Release Policy Configuration

Release configuration pages should not dump every field into one large form. Choose scope first with TxCascader, keep low-noise single choices in TxFlatSelect, put discrete risk into TxSegmentedSlider, continuous percentages into TxSlider, and keep TxTagInput limited to short metadata.

12. Review Checklist

• One primary action: keep one highest-weight button per panel; use secondary / ghost for supporting actions.
• Filter loop: keyword, scope filtering, match count, and no-match recovery should come from the same reactive model.
• Attached pagination: pagination must stay near the list footer and share the same filtering and selection model.
• Shared state: table selection, progress, and badges should come from the same reactive model instead of duplicated constants.
• Visible empty state: use empty-state components when no data exists; do not leave a blank table.
• Feedback roles: Toast handles short feedback, Tooltip handles short hints, LoadingOverlay blocks local refreshes, and Spinner communicates short waits.
• Authorization roles: Tree shows hierarchy, TreeSelect chooses ownership, Transfer assigns resources, and Timeline records audit history.
• Configuration layering: put short actions in menus, short notes in popovers, and long configuration in drawers; do not make one Popover carry a complex form.
• Release policy roles: Cascader owns scope, FlatSelect owns single-choice policy, SegmentedSlider owns discrete risk, Slider owns continuous ratios, and TagInput owns short metadata.
• Screenshot evidence: after adding or changing demos, open the local Tuff page and capture at least one key light/dark/mobile state.

13. Continue Reading

• Tuffex Components
• SearchInput
• SearchSelect
• SearchEmpty
• StatCard
• DataTable
• Pagination
• Skeleton
• Cascader
• FlatSelect
• SegmentedSlider
• Slider
• TagInput
• Tree
• TreeSelect
• Transfer
• Timeline
• LayoutSkeleton
• Tabs
• DropdownMenu
• Popover
• Drawer
• StatusBadge
• ProgressBar
• EmptyState
• Toast
• Tooltip
• LoadingOverlay
• Spinner