component proposal: command feedback

[iancoffey]

Describe the feature request

This is one in a series of proposed components that cover common interactions in the CLI to save plugin authors from having to duplicate efforts.
The use of a shared set of components will also contribute to the consistency of interactions and interfaces across the plugins.
This feature request is intended to capture the idea and the start of an open discussion, and not necessarily be implemented as described here. The overall goal is, as much as possible, to have a library of shared components for common interactions.

Command feedback component

The styleguide calls for a feedback statement to confirm to users the receipt of the command, and the context in which the command is running. details
The style guide also calls for color to be used in a specific way (pending PR #420) details
Rather than having each plugin implement this guidance, might there be a component that provides this behavior.
It could pull from a few templated phrases, with a fall-back option for unexpected cases.
Logging in as user [username]
Getting [resource name] from [location] as user [username]
Listing [resource type] in [location / filter condition] as user [username]
Updating [resource name] as user [username]
Creating [resource name] in [location] as user [username]
Deleting [resource name] in [location] as user [username]
fallback message idea - for when an action doesn’t map to the defined templates

• Executing task in namespace [name] as user [name]”

Describe alternatives you've considered
Plugin authors implement the behavior for their plugin, using the style guide as guidance.

Affected product area (please put an X in all that apply)

[ ] APIs
[ ] Addons
[x] CLI
[ ] Docs
[ ] Installation
[x] Plugin
[ ] Security
[ ] Test and Release
[x] User Experience

Additional context

[ali5ter]

Completely agree with having consistent feedback to provide the user with confidence that of what they've initiated and a component to help CLI authors align with the style guide.

I'd like to clarify what is meant by 'context'. I understand the templated phrases confirm the action and the target being acted upon. Is the context the combination of location and username? How does the username feature as part of the context? Should the name of the authenticated server/end-point feature as part of the context? e.g. Creating foo in cluster bar using server name foobar, Getting foo in namespace bar using endpoint name foobar, Listing foo in cluster bar using kubeconfig path/to/config, etc.

cc: @danfein

[danfein]

From the resource names I have seen so far, many are not super user user friendly (some contain guids or machine generated names)

On the apps plugin we have been experimenting with using the context name rather than the user name. Username is a pretty strong concept on TAS, which is what the feedback proposal above was based on. Username seemed to us like a less helpful bit of information to help users reason about where the CLI is targeted, and what the permissions are likely to be than the context.

Examples from the apps plugin:

Updating workload NAME using context CONTEXT_NAME
Workload NAME created in context CONTEXT_NAME

Not 100% set on using context X vs in context X Both seem like they could work, but there may be some nuance that makes one or the other a better choice.