feat: Nested Commands & Project Group Create #109
Conversation
| CmdPath string | ||
| } | ||
|
|
||
| func (co *CreateOptions) Commit() error { |
There was a problem hiding this comment.
I like the commit pattern for each command
| @@ -0,0 +1,6 @@ | |||
| package cmd | |||
|
|
|||
| type NestedOpts interface { | |||
There was a problem hiding this comment.
This does the same job as the TaskExecutor abstraction.
The advantage this has is that it's simpler because you're sticking commands directly in the collection, rather than having a separation between gather input / perform action.
The disadvantage this has is that the questions are bound (via a closure) to the commit. You can't ask the question differently in a nested command that you could at the root level.
The reason I added that separation for TaskExecutor was to avoid circular package references, to help provide some code structure as the project grew, and to allow for nested questions to be asked differently, but share the underlying 'send to server' bit.
I don't mind that you've gone a different way here, but it would be good to understand.
- Why didn't you just use the TaskExecutor pattern?
- This appears to force nested questions to be asked in the same way as they are at the root. Is this worth it?
- Have we thought through whether there are any other differences that might be significant?
If the team would like to go with this approach, then it obsoletes the TaskExecutor design. We should pay down our tech-debt and delete all that stuff.
| for _, o := range optsArray { | ||
| o.GenerateAutomationCmd() | ||
| } | ||
| } | ||
|
|
No description provided.