String.prototype.trimRight/trimLeft

# Dmitry Soshnikov (3 years ago)

Just got a question why don't we polyfill trimLeft and trimRight for strings, and have only trim (and the answer is -- because it's not part of ES5/ES6).

Just thinking could it be a valid cases when a dev may want to trim only form right still keeping e.g. the precalculated padding on the left (seems legit)?

MDN mentions them [1], [2], though as non-standard. What stopping both methods to be included?

[1] developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/trimLeft [2] developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/TrimRight

Dmitry

# Leon Arnott (3 years ago)

I believe opinion hasn't shifted since it was discussed previously - in short, "show me the cowpath". (But, I've just learned that the IE Technical Preview now supports trimLeft/trimRight, so there'll soon be support for it in all the major engines. Maybe the cows are there after all.)

# Tab Atkins Jr. (3 years ago)

On Mon, Mar 16, 2015 at 11:07 PM, Leon Arnott <leonarnott at gmail.com> wrote:

I believe opinion hasn't shifted since it was discussed previously

  • in short, "show me the cowpath". (But, I've just learned that the IE Technical Preview now supports trimLeft/trimRight, so there'll soon be support for it in all the major engines. Maybe the cows are there after all.)

I use both lstrip() and rstrip() in Bikeshed (a Python project):

tabatkins/bikeshed/search?utf8=✓&q=lstrip&type=Code, tabatkins/bikeshed/search?utf8=✓&q=rstrip&type=Code

In particular, lstrip() is used when I'm separating a key and value; I don't want to mess with the value much at all, just pull off the whitespace at the start. rstrip() is used when I know I don't need to strip from the left side, because I'm just pulling off newlines or something, so might as well let the program avoid even trying.

# Dmitry Soshnikov (3 years ago)

Right, so from the several feedback I had so far, it seems it will make sense just to add to ES7? In this case we'll be able to polyfill now, the spec'ing it will be trivial (I'll add the spec).

I guess we just need to confirm it's good to go to ES7?

Dmitry

# Domenic Denicola (3 years ago)

Yeah, this seems like a shoe-in for ES7. It will probably be able to advance through the stages very quickly given that it already has three (four?) shipping implementations.

Someone just needs to write up a formal spec (using Ecmarkdown! ^_^) and test262 tests. The only snag would be if you find non-interoperable behavior between browsers in the course of writing those tests, and need to get some patches accepted before you can reach stage 4.

# Dmitry Soshnikov (3 years ago)

Sounds good. Yeah, I'll spec it, and add the test.

Dmitry

# Dmitry Soshnikov (3 years ago)

OK, the spec is here: gist.github.com/DmitrySoshnikov/65a2070477fffb465048 Will appreciate review and corrections if needed.

Dmitry

# Dmitry Soshnikov (2 years ago)

Will somebody be so kind to present this on the following meeting for me, I don't have an ability to attend, and the change is pretty small (July 28th, 2015)?

People were asking, and we'd like to polyfill it instead of doing regexp replaces. Again the spec is here: gist.github.com/DmitrySoshnikov/65a2070477fffb465048

# Norbert Lindenberg (2 years ago)

These methods should be called trimStart and trimEnd. Determining which parts of the string are left and right would require running the Unicode Bidirectional Algorithm, and that’s probably not intended here.

# Jordan Harband (2 years ago)

On the contrary -"left" always begins at index 0 - "start" is sometimes index 0, sometimes index (length - 1). I think "left" and "right" are the right names; "start" and "end" would require unicode bidirectional stuff.

# Domenic Denicola (2 years ago)

They're already shipping with the "wrong" names in every browser.

# Norbert Lindenberg (2 years ago)

In which coordinate system?

# Norbert Lindenberg (2 years ago)

On Jul 20, 2015, at 23:29 , Domenic Denicola <d at domenic.me> wrote:

They're already shipping with the "wrong" names in every browser.

That’s very sad, because they’re wrong, not “wrong”.

# Claude Pache (2 years ago)

Le 21 juil. 2015 à 08:28, Jordan Harband <ljharb at gmail.com> a écrit :

On the contrary -"left" always begins at index 0 - "start" is sometimes index 0, sometimes index (length - 1).

Counter-example: ES6 methods String#startsWith and String#endsWith are named correctly.

I think "left" and "right" are the right names; "start" and "end" would require unicode bidirectional stuff.

No, because characters in Unicode strings are ordered logically, not visually.

# Dmitry Soshnikov (2 years ago)

OK, it was added to the agenda for the next meeting (will be presented by Sebastian Markbage), so can be discussed in detail. I agree that "start", and "end" are now probably better fit (because of i18n, and a strong correlation with "startsWith" and "endsWith"). We can probably ignore the de-facto shipped in browsers, they will just implement in addition trimStart and trimEnd, and eventually deprecate the "right" and "left".

Dmitry

# John-David Dalton (2 years ago)

In the wild I've seen ltrim rtrim which are variations of trimLeft and trimRight and padLeft padRight or lpad, rpad for other forms. For stings I think of left and right as leading and trailing and think of start and end as more position indicators of like slice or a range.

# Behrang Saeedzadeh (2 years ago)

Another set of very handy functions that in Java are provided by libraries such as Guava or Apache Commons and in C# are built in, are String.isNullOrEmpty(aStr) and String.IsNullOrWhiteSpace(aStr).

Would be nice if they ES Strings had them too.

# Michał Wadas (2 years ago)

I can't remember last time when I would need isNullOrEmpty - Boolean('') and Boolean(null) evaluates to false. And if (str) handles any case with consistent types.

String.isNullOrEmpty = (a)=>(typeof a === 'string' || a === null) && !a;

Anyway - native isNullOrWhiteSpace would be probably be useful only to reduce GC pressure, because it's easily polyfilled.

String.isNullOrWhiteSpace = (a)=>a === null ? true : typeof a === 'string' && !a.trim();

2015-07-29 13:27 GMT+02:00 Behrang Saeedzadeh <behrangsa at gmail.com>:

# Behrang Saeedzadeh (2 years ago)

I think poly-filling is only a good idea when the spec says a given type should have a given function but one or more browsers haven't implemented it yet.

Otherwise it will become like the era of overtly monkey patching everything in Ruby that could end up with libraries clashing with each other and leading to lots of headaches for developers.

Unless something similar to C#'s extension methods are added to EcmaScript: msdn.microsoft.com/en-AU/library/bb383977.aspx that can turned on a polyfill on a per scope basis.

# Jordan Harband (a year ago)

Closing the loop on this: this feature is now stage 4, and will be included in ES 2017. tc39/ecma262#581

Polyfills: www.npmjs.com/package/string.prototype.padstart and www.npmjs.com/package/string.prototype.padend

# Jordan Harband (a year ago)
  • sorry, to clarify: This was discussing padding. trimLeft/trimRight / trimStart/trimEnd is still stage 2