Customizing saved view UI

Use this guide when saved views are the right feature, but the shipped dropdown and dialogs still need to match your product language and collaboration model.

1. Start by deciding whether your product should expose views at all

Saved views are for named presets.

Use them when users should be able to:

• return to a meaningful table setup later
• share a preset with teammates
• promote a preset to a personal or workspace default

Do not use them as a substitute for quiet autosave. That job belongs to persistState.

2. Shape the visible views workflow from the top-level views config

The views trigger only appears when both pieces exist:

• a views adapter configuration
• toolbar.views: true

<Datatable
  tableKey="customers"
  data={customers}
  columns={columns}
  toolbar={{
    views: true,
  }}
  views={{
    adapter: trpcViewAdapter,
    workspaceId: workspace.id,
    userId: currentUser.id,
  }}
/>

This is the first customization boundary: decide whether the surface exists before you change its labels or layout.

3. Treat adapter capability as part of the UI design

The shipped saved view UI changes based on adapter support.

react-datatable checks whether the adapter can:

• share views with a workspace
• set user defaults
• set workspace defaults

That means the product should only promise actions the adapter can really perform.

For example:

• localStorageDatatableViewAdapter supports private views and user defaults
• it does not support sharing or workspace defaults
• a backend adapter can support the full collaboration workflow

If the table is anonymous, public, or single-user, disable collaboration-oriented affordances explicitly.

<Datatable
  tableKey="customers"
  data={customers}
  columns={columns}
  toolbar={{ views: true }}
  views={{
    adapter: localStorageDatatableViewAdapter,
    userId: currentUser.id,
    enableWorkspaceSharing: false,
    enableUserDefaults: true,
  }}
/>

4. Keep the two list sections meaningful: Private and Workspace

The current dropdown groups views into:

• Private — views that are not shared and not acting as shared defaults
• Workspace — shared views plus views carrying workspace or user-default meaning

That grouping is useful because it tells users whether a view is personal or social.

When you customize the labels or visual design, preserve that distinction.

A saved view should not look identical whether it is:

• visible only to one user
• shared with the workspace
• acting as a default for everyone

5. Customize naming and labels to fit the product domain

Most view-surface customization starts with language.

Good candidates for product-specific wording include:

• what your product calls a “view”
• create and rename dialog descriptions
• share-action wording
• default labels and helper text
• empty-state text for first-time users

The shipped UI currently uses generic language such as:

• Views
• Create new view
• Share with workspace
• Set as my default
• Set workspace default

If your product has a clearer term such as “Queue,” “Preset,” or “Saved search,” this is a good source-level customization target.

6. Preserve the dirty-state workflow even if the visuals change

The current views trigger shows a dot when the active saved view has unsaved changes.

Inside the dropdown, an active dirty view can expose:

• Update for overwriting the active view
• Save as for creating a new view from the current state

That is an important behavior contract.

It tells users three different things clearly:

• which named preset is active
• whether they have drifted away from it
• whether they are editing the current preset or creating a new one

You can restyle these controls, but avoid collapsing them into a single ambiguous save action.

7. Decide carefully which users can rename, delete, share, or default a view

The shipped menu already gates actions by ownership and capability.

Examples from the current source:

• rename and delete only appear for the view owner
• share only appears for private views when sharing is supported
• workspace default only appears for shared views
• user defaults are shown only when default management is enabled

That means UI customization should not be only decorative.

It should also keep permission meaning legible.

A helpful pattern is:

• keep destructive actions secondary
• make ownership obvious when views are shared
• avoid showing unavailable actions as dead controls

8. Use the dialogs to clarify what state a view actually captures

The create dialog currently promises to save:

• filters
• sorting
• column layout
• display options

That is a good baseline because it reminds users that a view is a durable table preset, not just a bookmark.

If your product adds stronger sharing or governance language, the create and rename dialogs are often the right place to explain it.

For example, you may want to clarify:

• whether defaults affect only the current user
• whether sharing is irreversible
• whether a workspace default becomes the first experience for teammates

9. Separate views customization from persistence customization

Saved views and current-view persistence reuse a similar state snapshot while serving different product surfaces.

Keep these roles distinct in the UI:

• persistence remembers private in-progress work automatically
• saved views are named presets users manage intentionally
• URL sharing sends a specific query state through a link

If a customization starts making views feel like invisible autosave, the product meaning gets blurry fast.

10. Edit the copied source when you need a different workflow

The shipped surface is implemented in the copied views components, including:

• DatatableViewDropdown.tsx
• ViewsDropdownContent.tsx
• ViewItem.tsx
• CreateViewDialog.tsx
• RenameViewDialog.tsx

Edit those files directly when the product needs deeper changes such as:

• different grouping or section rules
• a richer share flow
• custom badges for ownership or defaults
• extra metadata in each view row
• a different trigger shape or menu layout

When you do, keep the underlying model intact:

• active view selection
• dirty-state detection
• adapter capability gating
• ownership-based actions
• distinction between private, shared, and default states

11. Verify the views surface like a collaboration workflow, not a single button

Before shipping a customized saved view UI, check that:

• the trigger only appears when views are truly enabled
• private versus workspace meaning is visually clear
• unsupported actions are hidden, not implied
• dirty-state update/save-as actions remain understandable
• rename, delete, and sharing flows respect ownership
• default actions match the adapter's real capabilities
• the UI still distinguishes named presets from autosaved current state

Where to go next

• For the memory model behind this UI, read Persistence and Sharing.
• For the practical setup of the feature itself, read Add saved views.
• For the toolbar cluster that contains this trigger, read Customizing toolbar and controls.
• For deeper source-level swaps after prop-level customization runs out, read Replacing built-in UI elements.