[Request] Allow arbitraty text as part of the chain

[aerotoad]

Currently there is not (or I couldn't find) a way to append arbitraty entries as part of the current prompt chain.
You can add new prompts, notes or spinners, but not just a single line of text without breaking the left side bar.

I've hacked a way into it by creating a fake no-time spinner like so:

addText(text) {
  const sp = spinner();
  sp.start(text);
  sp.stop(text);
}

// Using it like:
intro('Welcome to this tool')
const res = await text({
  message: 'What's your name',
  placeholder: 'your name'
});

addText('My custom text as part of the prompt line')

It would be nice to have a straightforward way to just append a line of text, no prompt, no fancy stuff, just text that doesn't break the line with a function called something else like message or similar:

intro('Welcome to this tool')
const res = await text({
  message: 'What's your name',
  placeholder: 'your name'
});
message('my custom text')

[ulken]

I've hacked a way into it by creating a fake no-time spinner

😆 Creative! 👏

Just curious: where does note fall short for you? What's a typical use case for what your requesting?

[aerotoad]

Well, note is like a big block of text spanning multiple lines with borders, title and decoration, therefore used for important messages and similar purposes.
I was aiming at just displaying a single line of text whenever convenient to communicate something to the user, but console.log will break the "continuous line" approach of the library. Therefore the hack to allow a single text line to be inside the whole thing.

Example mixed use case of text nodes and a note:

All those messages are static, not loading spinners, they don't get replaced after loading is complete and are not intended to. They serve as a "history" line of what's been happening.

[ulken]

Well, note is like a big block of text spanning multiple lines with borders, title and decoration, therefore used for important messages and similar purposes.

Right.

All those messages are static, not loading spinners, they don't get replaced after loading is complete and are not intended to. They serve as a "history" line of what's been happening.

Now this is where you lose me. Looking at your example, the majority seem to be a perfect match for spinner. Why would you/the user want to see the intermediary states in hindsight? Isn't the important part to know if a step has resolved or not? The other feedback should only be relevant while waiting, no?

I'm not saying this ain't happening, I'll let @natemoo-re be the judge here. I just don't see the point.

[ulken]

Now this is where you lose me. Looking at your example, the majority seem to be a perfect match for spinner. Why would you/the user want to see the intermediary states? Isn't the important part to know if a step has resolved or not?

OK, giving it a second round of thought.

While still standing by the above: if each step is more less instant (thus no need for a spinner and getting rid of the intermediary states) in this case and all you want to do is log the completion of each step, now that I would buy.

Although not the best use case, hypothetically your example would be compressed to:

✅ Base project downloaded # (although this ought to take some time, so this should use a spinner for best UX)
✅ Template applied # (again, if there is a risk of not being instantaneous, taking more than a few hundred ms, use a spinner)
🎉 Project created!

[ulken]

Although, the last step should use outro(), IMO.

So still struggling to see a valid use case 🤷

[aerotoad]

Maybe that wasn't the best use case for this, it was just what I was working on at the moment 😅
I can think of some other situations for this to be useful, like providing some context to the user before showing prompts:

Maybe provide some short contextual information:

Or even show some errors/information that are non-blocking with more data:

Or any other case where you just want to do a simple console.log but want to keep it as part of the flow as well.

[ulken]

OK, I think I'm onboard. Thanks for clarifying with more reasonable examples.

So, let's flip things around a little and try to play devil's advocate for a second:

What if we took it to the next level and exposed a lightweight, but enhanced log instance?

I'm thinking, the base would be log.message(text: string, options?: MessageOptions = { symbol: '│' }) (this is basically what you're asking for). To not deviate from the existing UI guidelines, it would output a newline before and after the logged line and use the appropriate color.

Then we could provide convenience wrappers around that, like:

log.info(text) = log.message(text, { symbol: 'ℹ' }) // would be blue
log.success(text) = log.message(text, { symbol: '✔' }) // would be green
log.warn(text) = log.message(text, { symbol: '⚠' }) // would be yellow
log.error(text) = log.message(text, { symbol: '✘' }) // would be red

One could even take it even further and add log.group()/log.groupEnd() which would indent the bar, but that would be for another time.

Thoughts?

// cc @natemoo-re

[aerotoad]

That sounds great! Fits right in with what I'm building for my CLI 😄
Honestly I thought I was doing something wrong at the beginning, I just wanted to show a line of information to the user without breaking the flow 😅

[natemoo-re]

@ulken that sounds like the perfect API! Will try to get to this as soon as I can. ❤️

[ulken]

Cool, cool. I can kick things off tonight, if you'd like? Free for you to build upon. I'll open and reference a PR with progress.

[ulken]

@aerotoad feel free to try it out in #82.