Built-in Grid UI for state persistence with multi-layout management

Add first-class Save/Load layout tools to the Grid toolbar that persist and restore Grid state without custom wiring. The default provider should use localStorage, with an extensibility point to plug in server storage. Users should be able to:
- Save multiple named layouts (columns/order/visibility, sorting, filtering, grouping, paging, search panel state).
- Open a built-in popup to manage layouts (save as, rename, delete, set default) and load a selected layout.
- Choose storage scope per layout (local vs. server) with a simple toggle; the server provider API can be implemented by the app.

Behavior and scope
- Persist and restore via an internal provider abstraction; ship a default localStorage provider and document a server provider interface.
- Support full or partial restores; allow picking which parts to include (for example, only columns/layout vs. full DataSource state) to align with existing guidance on selectively applying options through `setOptions({ ... })` and DataSource APIs like `dataSource.filter(...)` [1] [2] [3] [4].
- Avoid double reads and support automatic persistence flows similar to the documented beforeunload/ready pattern; native implementation should mirror the current best-practice approach that saves on leave and restores on load, with an option to disable automatic behavior when using explicit Save/Load actions [2] [5].
- Respect known constraints for SignalR binding by restoring layout via `setOptions({ columns, ... })` and reapplying data state via DataSource methods to keep the hub connection intact; provide an out-of-the-box “SignalR-safe” mode that applies filters/sort/page through DataSource APIs [1] [3] [4].
- Include search box value persistence and ensure multi-check filter lists load their full option sets when state is restored, consistent with existing recommendations to persist search input and configure filter DataSources [6].

Developer experience
- New built-in toolbar tools: “Save Layout,” “Load Layout,” and “Manage Layouts…”, plus a public API to trigger the same actions programmatically [7] [8].
- Config options to:
  - Enable the feature and set a default storage provider (local or custom).
  - Define which state segments to include (columns, sorting, filtering, grouping, paging, search).
  - Provide hooks/events for pre-save, post-save, pre-load, post-load to modify payloads or enforce policies.
- A documented provider interface for custom storage so apps can store/retrieve named layouts from a server.

Rationale
- State persistence is officially supported via `getOptions()`/`setOptions()` and is commonly implemented with localStorage and beforeunload/ready flows, but requires custom buttons and wiring today [2] [5].
- Partial restore and DataSource API reapplication are established practices to handle limitations such as SignalR-bound grids where full `setOptions()` is not viable; the feature should codify these patterns into a turnkey, user-facing experience [1] [3] [4].
- Developers frequently need to persist search input and ensure multi-check filter option lists are correct after restore; including these in first-party behavior reduces extra glue code [6].

Requested deliverables
- Built-in toolbar Save/Load/Manage UI with a popup for multiple named layouts and defaults.
- Default localStorage provider; extensible provider model for server storage.
- Options to scope which state is saved/restored and a SignalR-safe mode.
- Public API and events for integration and policy control.
- Docs and demos covering automatic and manual flows, local vs. server storage, and SignalR scenarios.

[1] [3] [4] [2] [5] [6] [7] [8]

[1]: https://www.telerik.com/forums/localstorage-persistence-not-working-with-kendo-grid
[2]: https://www.telerik.com/aspnet-core-ui/documentation/knowledge-base/grid-automatically-persist-state
[3]: https://www.telerik.com/forums/localstorage-persistence-not-working-with-kendo-grid
[4]: https://www.telerik.com/forums/localstorage-persistence-not-working-with-kendo-grid
[5]: https://www.telerik.com/aspnet-core-ui/documentation/knowledge-base/grid-automatically-persist-state
[6]: https://www.telerik.com/forums/grid-state-persistance-with-column-filters-or-search-bar
[7]: https://www.telerik.com/aspnet-core-ui/documentation/html-helpers/data-management/grid/overview
[8]: https://www.telerik.com/aspnet-core-ui/documentation/html-helpers/data-management/grid/toolbar

The current demo is showing  a contains predicate. To enhance the current application, I am requesting the feature to use a starts with predicate to meet a practical business need. 

The minimum length property will need to changed to 1 to limit the number of characters to be typed.

 

Bug report
For the Telerik Scheduler Timeline View, since the update from somewhere in between version 2022.3.1109 to 2024.2.154, a custom timeline view cannot be selected if the view name has dot(s) in its name (e.g. "kendo.ui.customTimelineView").

Reproduction of the problem

Add a custom Timeline View by extending the kendo.ui.TimelineView

Current behavior

Unlike older versions (I know that it worked with version <= 2022.3.1109, but don't know when exactly it was introduced)  now the ui blocks, when the custom select view button is clicked. Specifically, the problem is in kendo.scheduler.js at line 4554:

Expected behavior

In this code line, the find method does not work when the variable "name" contains something like "kendo.ui.CustomTimelineView". As a solution, I suggest escaping the name beforehand:

With that or a similar solution , my custom Timeline View can be selected as before.