React Saved Views
The feature power users demand first. Reconstructing the same six filters every morning is the tax that makes people stop using a tool — so the filters become a thing you name, keep, and share.
Installation
Props
| Prop | Type | Description |
|---|---|---|
| views | SavedView[] | { id, name, filters, shared?, owner?, isDefault? } |
| defaultFilters | ActiveFilter[] | Applied when no default view exists |
| resultCount | number | Shown beside the chips |
| onChange | (filters: ActiveFilter[]) => void | Fires whenever the filter set changes |
| onSaveView | (name, filters, shared) => void | Fires when a new view is saved |
Dirty state, and locked filters
Two details do most of the work.
The dirty dot. Loading a view and then adjusting a filter puts you in a state that belongs to neither — and silently overwriting the saved view is the wrong default, because shared views belong to other people too. The component compares the current filter set against the loaded view's and shows an amber dot plus a banner, leaving you to save a new view deliberately.
Locked filters. ActiveFilter.locked marks a scope the user must not remove — a tenant, a site, a permission boundary. It renders with a padlock and no dismiss control, and survives "Clear all". Treating a security scope as just another removable chip is how someone ends up looking at another customer's data; enforce it server-side too, but do not present it as optional in the UI.
Shared views carry an owner and a group icon so it is obvious you are about to modify something the process team relies on.
New components every week
Get the week's new Kelvin UI components and templates in one short email. No spam, unsubscribe anytime.