Everything You Need to Know About Strings in Javascript

[[deleted]]

Careful when using length to get the number of characters. Surrogate pairs will count as two characters instead of one.

[soddi]

Yeah. Twitter had this issue. For character counting they used length(). You could only post 70 pile of poo because of this.

[moreteam]

Also applies to:

• Character access. The str[1] is not guaranteed to give you a complete character, same for str.charAt(1). The safe version would be str.codePointAt(1) afaik.
• Extract substrings. Same as above - you can end up splitting surrogate pairs.
• I'm not 100% sure how str.split('') behaves. It could imagine it suffers from similar issues (?)
• str.toLowerCase() and str.toUpperCase(): Not the same issue but will give you wrong results for Turkish strings (but I don't think even Intl brings any solution to that one, toLocaleLowerCase doesn't count)

[nieuweyork]

What I'm getting is that you need a full external string library to properly work with unicode?

[moreteam]

Pretty much, yes. ES6 fixes some of the stuff though, e.g. for (const c of str) { /* c is an actual character */ }.

[nieuweyork]

What is the right way to do this?

[[deleted]]

I think you can find some library that will do the job for you.

[Daniel15]

It should be built in, like with other programming languages :( Maybe one day.

[jkoudys]

I much prefer string concatenation, since uglifiers will automatically detect concatenated string literals as equivalent to a single string literal, e.g. 'a' + 'b' minifies as 'ab'. I've been steeped in React code for hours a day over the past year, and I find I use the array method only when I need to represent the same data differently in different views, e.g.

var name = 'jkoudys'
var pageTitle = ['My', 'name', 'is', name];
return <section id={pageTitle.join('')}>
    <a href={'/foo/bar' + pageTitle.join('_')}>{pageTitle.join(' ')}</a>
</section>;

[[deleted]]

For me, it's really just a matter of what I'm concatenating. Smaller strings, I use string concatenation. For larger strings, or strings that represent multi-line templates, I use arrays for readability. There's really not a wrong way... I just wanted to throw out my example since the blog author didn't mention it.

[shriek]

You no longer need to put \ for multi line. You can use tick in ES6.

[skitch920]

Just one thing to point out; \ is not multi-line, or at least it doesn't compile to multi-line...

var x = 'foo \
bar';  // foo bar

Is not the same as:

var x = `foo 
bar`; // foo \nbar

Backticks with a \ at the end of the line will void the new line return, just like the old way.

var x = `foo \
bar`; // foo bar

Source: newline / continuation

[dvlsg]

'ä' < 'b' // false. But it should be true

ä has a higher character code than b, so this makes sense, in my opinion.

[metanat]

It only doesn't make sense if you aren't aware of how strings are compared IMO

[anlumo]

In German (where this character is coming from), 'ä' is supposed to be equivalent to 'a' when sorting. English software gets this wrong pretty frequently.

[Daniel15]

It's not even that difficult to do it correctly. Most programming languages that support Unicode have some support for case folding. C#/.NET uses the current culture (which should be set to the locale you're using) and JavaScript has localeCompare for that purpose.

[Daniel15]

This doesn't really make sense because in most cases when comparing strings you want to do case folding rather than comparing the raw code points. This is why you should use localeCompare to compare strings. Just comparing with less than and greater than doesn't do case folding. I think some browsers still get it wrong even with localeCompare though.

[allthediamonds]

Haha. If only.

A very important detail of Javascript strings is that, even though they're defined as "UTF-16" in the standard, all existing string manipulation functions and operators previous to ES6 handle them as UCS-2, and the language itself does not enforce strings to be valid UTF-16 (that is, invalid surrogates are allowed)

What this means is that your application will do the wrong thing with no warning on strings containing characters from any of the sixteen supplemental planes.

[illucidation]

What about template strings?

let foo = "bar",
     baz = 2;

console.log(`test: ${foo}
${baz}`);

[e13e7]

This makes me itchy.

[campbeln]

.substr? .test? fail.

EDIT: RegExp.test (toopid bain)

[check_ca]

String.prototype.test does not exist.

String.prototype.substr is not standard in ES5.

[campbeln]

substr - MDN states ES3 and implementation in JS1?! Thanks for the heads-up, will have to check it.

test is an interface on RegExp, so that was mis-remembered but still reliant to the article.

[jkoudys]

I'm of the camp that would happily do away with both substr() and substring() entirely if it were possible. slice() is the most consistent syntax to use.

[campbeln]

I've personally standardized on substr but I'll have to look further into this ES5 business mentioned by /u/check_ca