Hide prefixText when it's an empty string

[stroncium]

Fixes #122

[sindresorhus]

I think it would be better to fix the JS code to also accept an empty string, without adding the padding. I prefer to keep TS types as simple as possible.

[stroncium]

@sindresorhus But we will have inconsistency then.

'  ' => '   spinner'
' '  => '  spinner'
''   => 'spinner'

and no way to put just one space in.

[stroncium]

Also, as it can be undefined from beginning, it makes sense to me we should be able to assign undefined to it(I actually thought it was the case from the start, but weirdly enough, optional field can be undefined, but can't be assigned undefined).

[sindresorhus]

Good point. I missed your comment in the issue. Ignore my previous comment.

[sindresorhus]

Can you document in words that setting it to undefined will hide the prefix? In the readme too.

[sindresorhus]

Hmm, actually, thinking about this more, would anyone actually want an empty space before the spinner? Seems logical to me that the empty space is just a joiner, so when prefixText is empty, there's no space. prefixText is not meant to create indentation, we have the indent option for that.

[sindresorhus]

Hmm, actually, thinking about this more, would anyone actually want an empty space before the spinner? Seems logical to me that the empty space is just a joiner, so when prefixText is empty, there's no space. prefixText is not meant to create indentation, we have the indent option for that.

@stroncium ⬆️

[stroncium]

@sindresorhus Feels weird to introduce additional code so that instead of just setting something to empty string and getting predictable result he'd set it to empty string, get unpredictable result and need to set up another option in order for result to get to what was predicted, no?

[ngocdaothanh]

One way to fix the mess is to force users (by redesigning the APIs?) to create a new instance of ora every time, instead of allowing users to reuse an existing ora instance (immutable vs mutable).

[stroncium]

@sindresorhus I wait for your final word on this.
Allowing undefined vs special case for empty string.

Pros:

• no additional code/logic
• consistent results with any string supplied
• setting undefined mirrors behavior for not defining

Cons:

• setting empty string may be thought by some as equal to "removing" the value, in which case the behavior might seem weird to them

[sindresorhus]

@ngocdaothanh It's not a "mess". It's just a tiny API quirk. And I don't think immutability would solve any problems in this case (I'm saying that as someone that loves immutability in other languages).

[sindresorhus]

@stroncium I'm gonna go with "special case for empty string". Thinking about it more, it doesn't look like a special-case to me, but more like expected behavior. As long as we document it it, there should be no problems with this.

Can you also give the PR a descriptive title?

[stroncium]

@sindresorhus changed to handle empty string