✨ make components.Select() generic

[afiune]

This change is adding a new SelectableItem interface that the function components.Select()
accepts so that we can select any type of slice.

Additionally, I improved the components.List() function to use the tabwriter when
running things without a TTY.

Finally, I added the following README.md

---

components package

This Go package has interactive helpers used by cnquery and cnspec.

We use a powerful little TUI framework called bubbletea.

Select component

Select is an interactive prompt that displays the provided message and displays a
list of items to be selected.

e.g.

type CustomString string

func (s CustomString) HumanName() string {
	return string(s)
}

func main() {
	customStrings := []CustomString{"first", "second", "third"}
	selected := components.Select("Choose a string", customStrings)
	fmt.Printf("You chose the %s string.\n", customStrings[selected])
}

To execute this example:

go run cli/components/_examples/selector/main.go

List component

List is a non-interactive function that lists items to the user.

e.g.

type CustomString string

func (s CustomString) PrintableKeys() []string {
	return []string{"string"}
}
func (s CustomString) PrintableValue(_ int) string {
	return string(s)
}

func main() {
	customStrings := []CustomString{"first", "second", "third"}
	list := components.List(theme.OperatingSystemTheme, customStrings)
	fmt.Printf(list)
}

To execute this example:

go run cli/components/_examples/rawlist/main.go

[github-actions]

Test Results

3 131 tests  ±0   3 130 ✅ ±0   1m 53s ⏱️ +24s
  371 suites ±0       1 💤 ±0 
   28 files   ±0       0 ❌ ±0 

Results for commit b311ed1. ± Comparison against base commit 8e42171.

♻️ This comment has been updated with latest results.

[imilchev]

why not have this added to a readme or some other development doc?

[afiune]

good idea! I can add some docs.

This example is useful to test this interactive code, you can run it with

$ go run cli/components/_examples/selector/main.go

I'll add it to the docs. 👍🏽

[imilchev]

can we have a more specific name for this interface? I find this one too generic making it unclear what it's purpose is. Perhaps call it CliListableItem or something similar?

[afiune]

Will change. 👍🏽

[imilchev]

i think this message makes no sense here. The discovery mechanism is related to asset discovery when starting a scan. You are building a generic function that can be used for any type of object (not necessarily an asset).

[afiune]

Great catch!

[imilchev]

nit: weird name. Perhaps call it FriendlyName or similar.
Would be nice to add documentation what this function is used for

[afiune]

I didn't want to re-implement the function for the assets, since it already exists and, it is the only place we use it (for now).

If we are ok with a new function, then I'll go with Display()

[imilchev]

this one also seems to generic. CliSelectableItem maybe?

[afiune]

Sure thing.

[imilchev]

I am not sure I am in favour of this construction. We are building a generic way of displaying lists of items and selecting an item from that list. I think the way an item from the list is displayed, should be defined outside of this function. The current implementation seems like it provides some "customization" options but it is actually very limited.

If you don't need the keys and values individually, why not just make the interface for Object have a function Print() string or something similar, and just call this here. Then it is up to the Object to specify how it is printed on the CLI. We also remove the PrintableKeys and PrintableValue.

[afiune]

I disagree.

Leaving the formatting to the implementation (caller) is not an option, if we want that, we should not have this function at all.

The whole point of these helpers is to help and standardize how we print/interact with "stuff".