In various situations, it’s beneficial to enhance standard markup with generic features. This is commonly achieved by creating and attaching managers to elements. These managers have the flexibility to perform a wide range of tasks, essentially offering limitless possibilities.

To illustrate this concept in a more practical context, consider two examples where you want the capability to write the code once and then selectively activate or deactivate the feature as required.

1. keyboard navigation and interaction on list items.
2. collection virtualization

Lets say that I have a list of menu items.
These menu items are grouped so that you can have sub menu items.
By default they are collapsed but all the nodes are there.
All you really need to do is manage the navigation of the menu items, expand and collapse group nodes and manage selection.

This is a very common use case and you really should only write the code once and enable or disable the feature as you need it.

We do this using the process api.

// enable the keyboard manager for the given collection
await crs.call("keyboard", "enable", { element: "#my-list" });

// disable the keyboard manager from the given collection\
await crs.call("keyboard", "disable", { element: "#my-list" });

The “enable keyboard action” initializes an instance of the keyboard manager and attaches it to the element, assigning a property named “__keyboardManager”. Upon creation, the manager sets up all necessary events and resources for operation.

Deactivating this feature when it’s no longer needed is crucial to prevent memory leaks. Leaving it enabled can lead to unnecessary resource consumption and potential performance issues.

Enabling and disabling features as needed is a crucial aspect of efficient UI management. For instance, in scenarios where the UI is temporarily suspended, relevant features should be disabled until they are required again. A more intricate example is the implementation of nested virtualization. Consider a kanban component with virtualized swim lanes, allowing for an unlimited number of lanes. Each swim lane itself is also virtualized to accommodate any number of cards. When a swim lane is actively used in the kanban, its virtualization should be enabled. Conversely, when the swim lane is not in use, its virtualization should be disabled to optimize performance and resource usage.