beginner25 minby DevFox

Strings and Template Literals

Building text, template literals over concatenation, the string methods worth knowing, and why every string operation gives you a new string.

TypeScript

Nearly everything a program touches is text. What someone types into a form, what is in a file, what arrives from another service, what you show on a screen — all of it text, all of it needing to be joined, cut apart, cleaned up and reassembled into something a person can read.

By the end of this lesson you will build messages readably, know the operations that come up constantly, and understand why a string can never be changed once it exists — which is the source of one specific mistake that catches everybody exactly once.

Writing text down

A string is a piece of text, written in quotes:

typescript

const photographer = "Ana Duarte";
const city = 'Lisbon';

Single and double quotes behave identically. Having both is useful when the text contains one of them:

typescript

const caption = "Ana's first exhibition";
const quote = 'She said "yes" immediately';

If you need the same kind of quote inside, put a backslash before it — that means "treat the next character as text":

typescript

const awkward = "She said \"yes\" to Ana's request";

The same backslash gives you \n for a line break and \t for a tab.

Building a message

You can join strings with +:

typescript

const message = photographer + " uploaded " + count + " photos";

It works, and it is hard to read, easy to get wrong — one missing space gives Ana Duarteuploaded — and it gets worse with every value added.

The better tool is a template literal, written with backticks. Values go inside ${...}:

typescript

const message = `${photographer} uploaded ${count} photos`;
console.log(message);      // Ana Duarte uploaded 400 photos

Joining with +

You supply every space by hand.

One missing space gives Ana Duarteuploaded, and the mistake is invisible in the source.

It gets worse with every value you add.

A template literal

Write the sentence, drop the values in.

Spaces are where you typed them, because you typed the sentence. Numbers convert themselves.

Backticks also span lines, keeping the breaks exactly.

Same output. One of them you can proofread by reading it.

Anything can go in the braces, not only a name:

typescript

console.log(`${count} photos, ${(count / 24).toFixed(1)} per hour`);
// 400 photos, 16.7 per hour

And backticks span lines, keeping the breaks exactly:

typescript

const description = `Taken at dawn on the Praça do Comércio,
before the tram queues formed.`;

Note the backtick is not the same key as an apostrophe. It is usually top-left on the keyboard, and typing the wrong one gives a confusing error about an unterminated string.

Reaching into a string

A string is a sequence of characters, numbered from zero:

Starting at zero feels arbitrary for about a week and then becomes invisible. Note that length is a property with no parentheses, while most of what follows are methods with them — a distinction the editor will remind you of.

Taking a range of characters is slicing:

The "up to but not including" rule is worth internalising: slice(0, 3) gives three characters, numbered 0, 1 and 2. The payoff is that slice(0, 3) and slice(3) split the string cleanly, with the same number ending one and starting the other.

Asking for a position that does not exist gives undefined rather than an error, which is worth knowing because it means a mistake here does not announce itself.

The operations you will use

trim() earns its place immediately. Text from forms and files arrives with trailing spaces and invisible line-break characters constantly, and two strings that look identical on screen compare as different when one has a stray space.

Cutting apart and putting back together:

split cuts at every occurrence of what you give it and hands back a list. join is its reverse, called on the list with the separator as its argument.

Searching and replacing:

Two traps in that list, and both produce wrong answers rather than errors.

replace vs replaceAll

replace changes only the first one.

"a_b_c".replace("_", " ") gives "a b_c".

Almost never what you want. Reach for replaceAll by default.

indexOf vs includes

indexOf returns -1 when absent.

So if (title.indexOf("x")) is a bug — -1 counts as true, and the condition passes precisely when there is no match.

Use includes whenever you want a yes or no.

Each pair looks interchangeable and is not

Padding, for lining things up:

A string can never be changed

Strings are immutable: once one exists, nothing alters it. Every operation that looks like a change produces a new string.

This catches everyone once. toUpperCase() did its job perfectly and handed back "LISBON", and nobody kept it.

Bad — calling the method and discarding the answer.

Good — keeping what comes back.

Nothing errors in the first version. The methods run, produce correct results, and drop them — so the record is saved with its leading spaces and its line break, and it will never match the same name typed cleanly. You find out weeks later, from a duplicate customer that is not a duplicate.

The rule: a string method always returns; it never changes. Assign the result, or chain the calls and assign at the end.

Text is not bytes

One more thing, briefly, because it explains a family of surprises.

Strings hold characters, not letters of the English alphabet. "Praça", "日本" and "🇵🇹" are all ordinary strings.

length counts storage units rather than what a person would call characters, so an emoji or an accented character built from two parts can report a length of 2 or 4. For counting, comparing and slicing anything that might not be plain English, prefer working with whole words or use the tools designed for it:

You will not need this often. Knowing it exists means that when length reports something surprising, you recognise it as a known property of text rather than a bug in your code.

A cheat sheet to keep

Where to go next

You can now build readable messages, cut text apart and put it back together, clean up what forms and files hand you, and you know why a method call that looks like a change is not one. That immutability rule returns in the arrays lesson, where the opposite is true and the contrast is the point.

Next is Numbers and Floating Point, the other type you will handle constantly. It explains why one number type covers everything, why 0.1 + 0.2 does not equal 0.3, and what to reach for when you are counting money — which is the lesson the opening bug of this course was really about.

Before you move on, take a line of text with a real shape — a filename, a comma-separated row, a full name — and pull it apart into pieces, then rebuild it in a different format. Splitting, trimming and rejoining is the most common thing you will ever do to text, and ten minutes of it now makes the rest automatic.