`String.prototype.trimStart`/`String.prototype.trimEnd` with a given string
jhprattdev at gmail.com
Mon Jun 24 19:26:51 UTC 2019
No idea how common of a use case this is; I personally ran across it when
reviewing the source code for marked (specifically the [rtrim method]).
That example only does characters, not strings, but it's used in the wild
by a package with ~2m weekly downloads on npm.
Of course we wouldn't want `trimStart` to differ from `trimLeft`, they'd
all be modified in unison. I just think that symmetry between similar
methods is important, and (apparently) has use cases.
On Mon, Jun 24, 2019 at 12:46 AM Jordan Harband <ljharb at gmail.com> wrote:
> `trimStart` and `trimEnd` are better-named versions of the very very
> long-existing `trimLeft` and `trimRight`, which lack this ability, along
> with ES5's `trim`.
> It wouldn't make sense for these three to differ.
> It certainly seems like a potential language proposal to add a string
> argument to all three; however, at what point is that reimplementing
> `string.replace(/^(foo)+/, '')`, `string.replace(/(foo)+$/, '')`, and
> `string.replace(/^(foo)+|$(foo)+$/, '')`? How common is the use case to
> trim matching substrings off of the ends of a string? (the use cases for
> padding were quite common)
> On Sun, Jun 23, 2019 at 12:14 AM Jacob Pratt <jhprattdev at gmail.com> wrote:
>> `String.prototype.padStart` and `String.prototype.padEnd` accept the
>> string to pad with as their final parameter. Is there any particular reason
>> `String.prototype.trimStart` and `String.prototype.trimEnd` don't do the
>> same? It would be nice to have a parallel, such that `'foo'.padEnd(10,
>> 'bar').trimEnd('bar') === 'foo'`.
>> - https://github.com/tc39/proposal-string-pad-start-end
>> - https://github.com/tc39/proposal-string-left-right-trim
>> Jacob Pratt
>> es-discuss mailing list
>> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss