Item separator

[sindresorhus]

It would be useful to be able to insert a separator between items to group them. Could just accept a string and let the user chose if it should be empty, --------, or something else.

Example:

It would eg be useful in yo where we display a long list of options, but some should be grouped together distinctively.

[alrra]

+1 on this :)

[danielchatfield]

How do you propose the API should change to include this?

Some possibilities:

{
    choices: [{
        name: "Some option",
        value: "someOption"
    },{
        type: "separator",
        value: "----------------------------------"
    }]
}

(with value having a sensible default)

Or:

{
    choices: [{
        name: "Some option",
        value: "someOption"
    },{
        separator: "----------------------------------"
    }]
}

If separator is true instead of a string then default is used.

Or:

{
    choices: [{
        name: "Some option",
        value: "someOption"
    },{
        name: "----------------",
        value: "_separator"
    }]
}

Or:

{
    choices: [{
        name: "Some option",
        value: "someOption"
    },{}]
}

Disadvantages of this method is you can't specify the separator string (although I don't actually think that is necessary), also it isn't easy to understand what the empty object is doing without consulting the API.

My personal preference would be either of the first two. Any more ideas?

[stephenplusplus]

What if just a string was passed to the choices array? "------------", "######", whatever. That, or your first suggestion is my +1.

[danielchatfield]

@stephenplusplus Would that not conflict with the current API, as it allows just strings to be passed (set's both name and value to whatever the string is).

[stephenplusplus]

Ah, I see. Bad idea, then! Unless that functionality was ever intended to
be deprecated. Setting a value to a longer option name seems a little
problematic; eg "Run the Angular generator" and props.choices.indexOf('Run
the Angular generator') > -1

On Saturday, August 17, 2013, Daniel Chatfield wrote:

@stephenplusplus https://github.com/stephenplusplus Would that not
conflict with the current API, as it allows just strings to be passed
(set's both name and value to whatever the string is).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/53#issuecomment-22811377
.

[sindresorhus]

I'd prefer the 2nd

[danielchatfield]

@sindresorhus And do you think separator is the right word to use?

[sindresorhus]

yup

[SBoudrias]

Presently, I prefer { separator: "---------------" }.

Another option I could think of was to join choices group in sub-arrays, e.g.:

choices: [
    [
        "choice A",
        "choice B"
    ], [
        "foo"
    ]
]

That syntax wouldn't allow custom text and stuff to fill the space, but it'd be easier to implement and could enforce consistency (which may not be super useful...) - So all in all, I think @danielchatfield 2nd option is the best ATM.

[sindresorhus]

@SBoudrias i think both of your suggestions could be useful, sub groups if you dont care about the separator and separator if you need to fill in custom stuff.

[SBoudrias]

Ok, so I think I got it!

What I don't like from option 2 is that it infer a "type" based on the presence or absence of some values in an object. I usually don't like infering as it can only brings problem eventually.

So, I think that'll be perfect:

choices: [
  "choice A",
  new Inquirer.Separator("-----------------"),
  "choice B"
]

It feels like the Handlebars.SafeString constructor to notify the engine we send escaped data. And I think some parts of how Inquirer handle some objects internally could be rewritten in similar fashion.

What do you think?

[danielchatfield]

I like that. Perhaps inquirer.separator should be a function which returns
the new instance. I think it would be cleaner to just have a function call
rather than having the 'new'.

On Tuesday, 20 August 2013, Simon Boudrias wrote:

Ok, so I think I got it!

What I don't like from option 2 is that it infer a "type" based on the
presence or absence of some values in an object. I usually don't like
infering as it can only brings problem eventually.

So, I think that'll be perfect:

choices: [
"choice A",
new Inquirer.Separator("-----------------"),
"choice B"]

It feels like the Handlebars.SafeString constructor to notify the engine
we send escaped data. And I think some parts of how Inquirer handle some
objects internally could be rewritten in similar fashion.

What do you think?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/53#issuecomment-22922450
.

For contact info visit: www.danielchatfield.com

[sindresorhus]

👍