Extensibility model

[shlomiassaf]

The library is strict in what API is exposed.
Most of the classes are either internal or sealed making it very hard to extend it.

For example, I would like to add handling for a the character * (asterisk) so pressing it on a list/multi-list will select all items.
This simple functionality is very hard to achieve, as far as my understanding.

A component library can not handle all scenarios, I might think this * function is so basic it should be in, other may not.
And that's just one, each feature adds tech debt, maintenance costs and more...
I'm not expecting this project to support every crazy feature I want to add.

This is why extensibility is important, especially in a UI component library.

Spectra is amazing, we need to be able to extend it.
The fact that one can not inherit or access core constructs of the library is very limiting and slows adoption.

We will be amazed what people can/will do once it is more accessible to them.

Anyway, thank you for the wonderful work done here!

[shlomiassaf]

Take #711 as an example:, supporting ESC to exit the selection prompt.

It's the same thing.

Extensibility can be done by specific API, i.e allow reacting to key presses + exposing properties in the prompt to be able to do stuff

or, by removing sealed and internal modifiers to allow more control.

The first option is more guided, safe and easy to understand approach while requires more development resources from you guys and is more limited which will lead to endless requests.

The second is more easy for you guys to implement, just expose stuff but it will require adopters to understand the core library better while allowing them endless possibilities. The end result is more people being able to contribute along the way as they get to know the core code better.

My 2 cents here is the second option is a good starting point, fast and easy win and if later possible also add another path based on the first option