`String.prototype.trimStart`/`String.prototype.trimEnd` with a given string

Jacob Pratt jhprattdev at gmail.com
Mon Jun 24 23:14:56 UTC 2019


Just thinking about this, the argument that it could be done with regex
would also apply to spaces. It's by no means an argument _in favor_, but it
clearly wasn't a blocker.

On Mon, Jun 24, 2019 at 4:10 PM kai zhu <kaizhu256 at gmail.com> wrote:

> fyi, a search of the entire markedjs/marked repo shows 2 places where
> rtrim is used:
>
> ```js
> // https://github.com/markedjs/marked/blob/master/lib/marked.js
> 227
> <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L227>
> codeBlockStyle: 'indented',
> 228
> <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L228>
> text: !this.options.pedantic
> 229
> <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L229>
> ? rtrim(cap, '\n')
> 230
> <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L230>
> : cap
>> 1425
> <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L1425>
> baseUrls[' ' + base] = rtrim(base, '/', true);
> 1426
> <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L1426> }
>
> 1427
> <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L1427> }
>
> 1428
> <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L1428> base
> = baseUrls[' ' + base];
> 1429
> <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L1429>
> 1430
> <https://github.com/markedjs/marked/blob/5ba9ba5b93b95096445249c11b31c13f7514137a/lib/marked.js#L1430>
> if (href.slice(0, 2) === '//') {
> ```
>
> only the 1st use-case does what this thread proposes (the 1st trimRight's
> "\n", while the 2nd behaves differently and is more like nodejs'
> `require("path").dirname()`
>
> if i were writing the library, i wouldn't have bothered with a
> helper-function if its only going to show up in 2 [trivial] places.
> would've instead inlined two throwaway regexp-expressions, to keep code
> more-self-contained / less-fragmented:
>
> ```js
> 228          text: !this.options.pedantic
> 229            ? cap.replace((/\n+$/), "") // remove trailing "\n" or
> perhaps just use .trimRight()
> 230            : cap
>> 1425      baseUrls[' ' + base] = base.replace((/\/[^\/]*$/), "/"); // get
> "dirname" of base-url
> 1426    }
> ```
>
> On Mon, Jun 24, 2019 at 2:27 PM Jacob Pratt <jhprattdev at gmail.com> wrote:
>
>> 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.
>>
>> [rtrim method]:
>> https://github.com/markedjs/marked/blob/master/lib/marked.js#L1493-L1517
>>
>> 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'`.
>>>>
>>>> References:
>>>> - 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
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190624/78a3e917/attachment-0001.html>


More information about the es-discuss mailing list