Author a custom feature

Read core and feature architecture first. Use a plugin for reusable state or behavior that must augment Table objects. Built-in options and typed tableMeta/columnMeta are usually enough for renderer callbacks and application configuration.

Implementation workflow

1. Identify the state, options, and object methods the behavior owns. If it only passes callbacks or renderer data, read scoped meta typing and use meta instead.
2. Before declaring plugin types or writing lifecycle hooks, read the complete plugin example. It enumerates all 10 public FeatureMaps, the API assignment helpers, lifecycle ordering, and the advanced row-model maps.
3. Declare the feature key in Plugins. Merge only FeatureMaps with matching runtime implementations; declarations alone install no behavior.
4. Preserve user state after defaults in getInitialState; connect state updaters in default options. Install table methods with assignTableAPIs and object methods with assignPrototypeAPIs inside the corresponding lifecycle hooks.
5. Keep the feature object and tableFeatures({ customFeature }) result stable. Register the plugin through tableFeatures so inference and composition include it.
6. Verify the advertised state, options, methods, and resets on a constructed table. Each declared API must exist at runtime; reset behavior must respect the state owner.

Lifecycle boundaries

Use initTableInstanceData for mutable data owned by one table and resetTableInstanceData for clearing its transient contents. All feature initialization finishes before any constructTableAPIs hook. Keep method installation separate from data allocation.

Prototype methods are shared across the table's rows, columns, cells, or headers. Read per-object values through the method's current instance, and use the supported instance-data hooks for mutable fields. Read the example's installation rules before adding memoized methods or advanced row-model/cache wiring.