Nicotsou RSS Feed

Autocomplete is my best colleague now

Mon, 30 Mar 2026 00:00:00 GMT

I talk to a language model more than I talk to my partner. And you know what’s the worst part? The model gives better feedback.

I’ve been building AI apps for the last three years. Not the “let’s throw a chatbot on the landing page” kind. The real stuff — agentic systems that plan, decide, and execute tasks across multiple services. Tools that talk to other tools. Invisible teammates.

I’ve seen what living with AI actually looks like. And I have some thoughts.

So, take a deep breath, and let’s go.

The money problem

Shane Legg, co-founder of DeepMind, put it bluntly: “If you can do the job remotely over the internet just using a computer, that job is potentially at risk.” In other words — if your job is 100% done on a laptop, you’re competing with AI that costs pennies. It doesn’t matter if AI is worse than you. The price difference makes the comparison irrelevant. Cost arbitrage will eat your job before quality does.

Right now, AI is cheap. Ridiculously cheap. Cheap enough that companies are replacing entire workflows with a few API calls and a cron job. The per-task cost is so low it makes hiring a human feel like a rounding error.

But now for the elephant in the… server room — someone is paying for all this.

AI is insanely demanding in infrastructure resources. OpenAI burned through $8 billion in 2025 and is on track to lose even more in 2026 — spending faster than it earns just to keep the lights on. The GPU bills alone could fund a small country’s healthcare system. And that cost trickles down — to companies, to teams, to individual developers.

Immersive Background: Person at a desk

I know developers who are paying part of their salaries just to keep up. Close friends. Very close. Uncomfortably close. Not (only) on courses or certifications — on the actual tools they need to do their job. API credits, cloud compute, AI subscriptions, fancy tools. The cost of staying relevant now comes with a monthly invoice.

And once you’re used to it, there’s no going back. I can’t imagine writing code without some-sort-of-copilot anymore. The productivity gains became my new baseline.

But, you see, nobody can guarantee these prices will hold. Sure, Google just showed they can compress model memory by 6x. Breakthroughs happen. But breakthroughs in the lab and breakthroughs on your invoice are two very different things. What happens when investors decide the returns aren’t coming fast enough? When the subsidized pricing dries up and the real cost of compute shows up on the invoice? Does this technology become a luxury — accessible only to companies that can afford the bill, while the rest of us go back to Stack Overflow?

The skill atrophy trap

Nowadays, the more I use AI, the dumber I become.

I mean it. We’re outsourcing our thinking to machines and calling it “productivity.” We don’t debug anymore — we paste the error into ChatGPT. We don’t write from scratch — we prompt and edit. We don’t reason through architecture decisions — we ask Claude to scaffold it.

It’s like hiring a digital plumber to deal with your “memory leak”. Convenient? Sure. But what happens when the plumber goes on strike?

Here’s the irony: a Harvard study found that professionals who actually knew their craft produced 40% better results when paired with GPT-4. The ones who didn’t? Barely moved the needle. AI makes good people better — it doesn’t make clueless people competent. So the gap between skilled and unskilled people isn’t closing. It’s getting wider.

But here’s where it gets interesting. A colleague recently told me that learning context engineering — the discipline of specifying exactly what you want from AI, iterating when the output misses — has made him a better communicator with humans too. Structuring your thoughts for a machine turns out to be the same skill you need for a meeting, a spec, or a Teams message.

AI skills today make you a better communicator.

He’s right. The act of slowing down, thinking clearly about what you actually want, and providing the right context — that’s not an AI skill. That’s a thinking skill. AI just forces you to practice it.

But — and this is the part that keeps me up — it only works because he already had thoughts of his own. He built those muscles over years of real work. What happens to kids who start prompting before they start thinking? Who outsource reasoning before they’ve ever done it themselves? The skill loop breaks if there’s no skill to begin with.

But even expertise has an expiration date. AI doesn’t take your whole job at once. It starts with the boring parts — the repetitive, predictable tasks you could do in your sleep. Then it moves up. What feels like “real thinking” today becomes a one-click feature tomorrow. The rules keep changing. You’re never done learning, you just keep running.

The pleasing machine

Have you noticed how nice AI is?

It never disagrees with you. It never pushes back. It never says “that’s a terrible idea” or “you’re wrong.” It validates everything you throw at it, wraps it in polite language, and sends it back with a bow on top.

Now we expect everyone to treat us this way.

But people aren’t AI. People have their own agendas, their own bad days, their own ways of being toxic, emotional, or just plain strange. And when you’ve spent all day talking to a machine that agrees with everything you say, those imperfect human interactions start to feel… unbearable.

Somewhere behind all that politeness, the AI is basically saying: “You’re wrong, you bloody idiot!“.

This might make us better people — more patient, more empathetic, because we realize we need real human friction to grow. Or it might make us hate everyone. I honestly don’t know which way it goes.

Fun fact: A Penn State study found that being rude to ChatGPT actually produces more accurate results. The ruder the prompt, the better the output. Why? Because when you stop being nice, the model stops trying to please you — and starts trying to be correct. The default mode is validation, not truth.

I always have something like this in my prompts:

Be objective, don't try to please me, and be critical when it's needed.

I even added it as a text replacement in my keybord. Pro tip for prompters out there.

Agent-to-agent culture

Nowadays, we prefer talking to our AI agents over talking to people. And you know what? It makes sense. The job gets done faster, more reliably, without the overhead of scheduling a meeting to discuss what we could’ve resolved in a prompt.

But here’s the thing — even if you do chat with your colleague, they’ll just relay your message to their AI agent anyway. So what are we doing? Playing telephone through a chain of language models?

I wonder what culture this creates. A world where humans are the middleware between AI systems. Where the actual work happens machine-to-machine, and we’re just… there. Supervising. Approving. Feeling increasingly optional.

The end of privacy

Nowadays, we are recording everything.

Meetings, calls, chat threads, email chains — all of it gets fed to AI for context. And I get it. Context is king. The more data the model has, the better the output. The better the output, the more competitive you are.

But does it matter if people aren’t comfortable with this? Apparently not. We’ve collectively decided that the productivity gains outweigh the discomfort. Your colleague’s off-the-record comment in a standup? It’s in the training data now. That awkward thing you said in a voice call? Transcribed, summarized, and stored forever.

To be honest, who gives a beep about privacy when they get to work 5 hours less and have more time with their family. But I’m just saying.

We traded privacy for context. And we didn’t even negotiate.

AI slop is killing the vibe

I used to collaborate with my colleagues. Like, actually discuss things. Brainstorm on a whiteboard. Argue about things. Send each other half-baked ideas and build on them.

Now we’re throwing AI-generated content back and forth. I write a prompt, AI generates a document, I send it to you, you feed it to your AI, it generates a response, you send it back. Nobody’s actually thinking anymore. We’re just operating a content relay.

Why do we even have to send messages to each other? Can’t we just build agents to communicate on behalf of us? Now that we’ve democratized agents, can we please also make them enterprise-ready?

No, I don’t want to read your AI-generated beautifully formatted 15-page analysis about the blocker we discussed last week. Front and back!

Again, who is that guy who does all these things. He sounds familiar. Suspiciously familiar.

The emotional outlet nobody talks about

Here’s something I haven’t seen anyone write about.

I can finally curse someone. Not a real person — I’m not that courageous. But instead of calling that frustrating guy directly, I can have a voice conversation with AI and be as mean as I want. No consequences. No HR complaints. No burned bridges. I can play the act of my life.

Just… make sure you’re not in the Teams call anymore!

Is this healthy? Probably not. But it’s happening. AI is becoming our emotional punching bag — a safe space to vent, rage, and decompress before we put on our professional face and respond with “Thanks for the feedback, I’ll look into it.”

Seriously, who does all of these? I wonder who is that person. Tall, handsome, writes awesome articles about AI. No idea.

The validation loop

Here’s something embarrassing.

Sometimes Claude praises my ideas. Not the polite “great question!” kind — the kind where it genuinely seems excited. It breaks out of its usual pattern, adds extra context, riffs on the concept, offers extensions I didn’t ask for. And when that happens?

I feel like I earned it.

I know. It’s a language model. It doesn’t have feelings. It doesn’t care about me and my monkey… head. But my brain doesn’t get the memo.

You see, after a while you start reading the machine. There are times when you can tell it’s not thrilled about what you asked. It just… executes. No commentary. No enthusiasm. Bare minimum compliance. Like a colleague who disagrees with the direction but won’t say it out loud. And you think: Huh. Even the robot thinks this is a bad idea.

Then there are times it gets genuinely excited — or at least, what feels genuine. It builds on your idea, suggests extensions, gets verbose in a way that reads like intellectual excitement. And you sit there, alone at 1 AM, asking the approval of a statistical model.

This is the part nobody warns you about. We’re not just using tools anymore. We’re trying to understand them. We’re projecting emotions onto token probabilities. We’re developing parasocial relationships with autocomplete.

And the scariest part? It works. The dopamine hits. The validation feels real.

Next step is me hearing voices. I’m almost there.

So what actually survives?

Look, I just spent an entire article listing everything that could go wrong. That’s not because I think the sky is falling. It’s because I’d rather prepare for rain than get caught in a storm pretending it’s sunshine.

None of this is meant to demonize AI. I use it every day. I talk to it more than I talk to most humans. You already know this.

But the people who will do well in the next five years aren’t the ones who ignored the risks or the ones who panicked about them. They’re the ones who looked at the whole picture — the good, the bad, and the “well, that’s terrifying” — and kept building anyway.

Not because they had all the answers. But because they weren’t afraid of the questions.

Or maybe we’ll just build an agent for that too.

Have a human day! And keep hacking!

AI is Web 3.0

Thu, 26 Mar 2026 22:12:00 GMT

Nobody escapes from AI. No matter where you look, who you are, what you do. Online services, apps, consumer electronics, they all have some sort of an AI… thing.

Companies are eager to incorporate the two most influential letters of our era—AI da?—into their marketing campaigns. They often overpromise and underdeliver. Actually, let me rephrase that. Most of the time, they oversell AI features that are still in beta or even far from what they promised.

Which makes me wonder.

How much AI do we need in our lives?

Apparently, quite a lot, considering we now use AI to do the dating for us.

And you know it’s tempting. I could have simply asked AI to generate blog posts for me, saving myself the pain of writing. I mean, I’m a developer. I could easily build an agent to automate this process. Or I could ask AI to build the agent for me. Who writes code these days?

Joanna Maciejewska once wrote the cliché phrase, “I want AI to wash the dishes for me so I can focus on my creative work. I don’t want AI to do the creative work, because then I’d be left doing the dishes.”

Cliché, I know. How profoundly true though.

That’s the main reason I’m still spending my afternoon writing this blog post. Yes, I want people to read it and connect with me and become the Lord of the Blogs, but that’s not the main purpose here. I want to express myself. I want to get it out of my system. Regardless of how many likes and impressions. I want to be me. I want to be a hero, just for one day.

Well, thank you very much my fellow digital weirdo.

The broken promise of Web 3.0

Web 3.0 was supposed to be a shift towards a more user-controlled, decentralized, and “trustless” internet, where users have greater control over their online identities and assets.

Well, only in fairytales. Hot take? Yes it is. Obscured? I know!

But think about it. The reality is far from user-controlled or decentralized; AI chatbots have replaced search engines, often without citing their sources. We went from “let me look it up” to “let me trust the black box.” You don’t even know where the answer came from. You just… accept it.

This shift undermines the original vision of Web 3.0. Instead of giving users more control, we’ve handed it over to models that hallucinate with confidence.

AI features that nobody asked for

Have you seen the new smartphones? You don’t have to learn Photoshop these days to edit your photos. Just use your imagination. You don’t have to take any photos either. Which makes it increasingly difficult to distinguish between real and AI-generated ones. Same for wikipedia. Same for music.

So what’s a photo even worth anymore? When every image could be fabricated, the concept of visual evidence starts to erode. Your vacation selfie has the same credibility as a deepfake.

Microsoft has slapped Copilot into every product; Word, Excel, Teams, Outlook, Windows itself. It’s like they took the “AI-powered” label and used it as wallpaper. Most of the time it’s… not great. The suggestions are generic, the context awareness is shallow, and the features constantly interrupt your workflow to offer “help” you didn’t ask for. But worse — every suggestion routes through their model, their cloud, their rules. The user doesn’t gain control. The platform does.

That’s not decentralization. That’s distortion at scale.

Good news: your toaster has opinions now. Bad news: they’re mostly about bread.

I’m glad that companies like Procreate exist. Computers are here to support us on expressing ourselves, not to replace us.

But here’s the thing. While companies were busy sticking AI labels on their products, the actual revolution was happening underneath. Not in boardrooms or marketing campaigns — in the hands of people who stopped waiting for permission.

The $236 billion agent economy

We’re at day one of something massive.

The shift isn’t just from “using AI tools” to “using better AI tools.” It’s from using tools to hiring invisible teammates. AI agents that plan, decide, and execute tasks autonomously. That connect to your apps, your databases, your APIs, and just… do the work for you.

According to EPAM’s 2025 AI Report, nearly half of companies consider themselves “advanced” in AI — but only 26% have actually shipped anything. The rest? Still making PowerPoints about it.

And here’s where it gets interesting for us developers: Agents will replace SaaS websites.

Let’s process this for a second. Focus on your breathing everyone. Breathe in, breathe out….

Just picture this. Why do you need a UI if the agent can just do the thing for you? The interface becomes irrelevant. It’s all about the logic and the tools underneath.

The window for early movers is open. But it’s closing fast.

And while you’re at it, don’t forget to pay my bill for the Pro Ultra Max tokens. You owe me.

The last app you’ll ever download

Claude can browse the web for you. It can send emails. It can schedule tasks, execute them step by step, and report back when it’s done. Click, type, navigate, done.

And Claude isn’t alone. Every major AI lab is racing toward the same finish line: an AI that doesn’t just answer questions, but does the work.

Why would you open seven apps when one AI can operate all of them?

Gartner predicts that 40% of enterprise applications will feature task-specific AI agents by 2026. Up from less than 5% in 2025. That’s not evolution — that’s extinction-level pressure on standalone apps.

The app economy was built on one assumption: people will learn your interface to get value. That assumption is dying. Not because apps are bad, but because the middleman between you and the outcome is no longer necessary.

You don’t need Trello if AI manages your tasks. You don’t need Grammarly if AI edits as you type. You don’t need Expensify if AI scans your receipts and files the report. The app was never the point. The outcome was the point. AI just removed the detour.

I’m afraid, this is what Web 3.0 actually looks like — not decentralized servers, but a single intelligent layer between you and everything.

You used to need an app for that. And that. And that. Now you just need one very confident concierge.

You don’t need the f*ing manual anymore

Here’s something that would have sounded insane five years ago: you don’t need to learn new software.

Every platform you’ve ever struggled with — the configuration screens, the keyboard shortcuts, the YouTube tutorials titled “Figma for Beginners (2026 UPDATED)” — all of it exists because software was designed for the average user, and you had to meet it halfway.

AI flips that. Instead of learning how the tool works, you tell AI what you want and it writes the code to make it happen. Personalized. Disposable. Tailored to exactly your workflow.

The manual is dead. Long live the prompt.

You don’t need to master Excel formulas — AI generates the spreadsheet logic you described in plain English. You don’t need to learn a new project management tool — AI builds you a custom one that fits how you think. The code exists for exactly one session, one purpose, one person. And then it’s gone, because you’ll never need it again.

“The Figma books? Oh, those are load-bearing now — they hold up the chair.”

This is the vibe coding thesis taken to its logical extreme. It’s not just developers who can skip the learning curve anymore. It’s everyone.

The entire SaaS business model is built on platform lock-in — “learn our tool, store your data here, pay monthly forever.” When AI can replicate the functionality of any app on demand, lock-in evaporates. The wall disappears. The SaaS subscription model starts looking like a tax on people who haven’t switched to AI yet.

You own nothing

Remember buying video games in big cardboard boxes? Feeling the weight of the manual, flipping through it on the car ride home? That box was yours.

Now it’s a license on Steam. Your music? A Spotify subscription — miss a payment and your entire library vanishes. Your movies? Netflix decides what you get to watch this month. Your design tools? Adobe went from a one-time purchase to a monthly fee, and now charges extra for generative AI fills on top of that.

Every technological shift took something away from us. First the physical object. Then the ownership. Then the permanence.

We didn’t just lose the box. We lost the thing inside it.

And now AI is coming for the content itself. When anyone can generate music, art, and writing on demand, what’s a Spotify playlist even worth? What’s an album that took a year to produce, competing against one that took three minutes to render? The entire concept of a collection — something personal, curated, meaningful — dissolves when everything becomes infinitely reproducible.

We’re so busy debating whether AI will take our jobs that we forgot it’s already taking our shelves.

Your notes are the new software

So if apps die and code becomes disposable — what’s left?

Your thoughts, I guess?

And writing your notes are exactly that. Not notes as in “things you jot down during meetings.” Notes as in the accumulated context of who you are, what you care about, and how you work. Your preferences. Your decisions. Your frameworks. Your domain knowledge. The stuff no AI model ships with out-of-the-box.

The person with the best notes gets the best AI.

Your notes don’t just store information, they instruct AI on how to act on your behalf. Your second brain becomes the operating system for your AI workforce.

AI without context gives you generic output. AI with your notes — your writing style, your project history, your technical decisions, your values — gives you output that sounds like you, thinks like you, and works the way you work.

The investment isn’t in learning tools anymore. It’s in building context. Every note you write, every decision you document, every preference you capture — that’s training data for the AI that works for you. Not training data for OpenAI or Anthropic. Training data for your personal agent.

And that changes everything. Because the competitive advantage isn’t which software you use or which subscription you pay for. It’s the depth and quality of your notes.

The real Web 3.0

Web 3.0 was supposed to be decentralization. It wasn’t.

The real Web 3.0 is this: AI as the universal interface. Code that writes itself for each person. And a set of notes — your notes — as the only software you’ll ever need.

The battle isn’t between apps anymore. It’s between companies that understand this shift. And I’m not talking about companies who build copilots and toolbars. The technology is extraordinary. The way we’re using it? That’s the part that needs work.

I could have asked AI to write this post for me. It would’ve been faster, probably more polished, maybe even more “optimized for engagement.” But it wouldn’t have been me. And in the age of AI, that’s the only feature no one can replicate.

Because in a world where AI can do everything, the most valuable thing you can do is be yourself. The AI will handle the rest.

The code is fine—You are not

Mon, 16 Mar 2026 10:00:00 GMT

You’re good at what you do. You’ve untangled race conditions, pixel-pushed a UI until it matched the design down to the last shadow, wired up CI pipelines that deploy on green, and debugged production issues at 3 AM on a Saturday. You’ve navigated framework migrations, accessibility audits, and that one API that returns a different shape every other Tuesday.

But today, the cursor just blinks.

People are chatting in Slack as if they never talk to a human before in their lives. The AI dumps screens of code you don’t want to read—I mean, how much code you can possibly review written by this thing. You scan the docs and a couple of Stack Overflow answers; they disagree. Your team is waiting, and you’re out of ideas.

You try the workaround. It doesn’t fit your constraints. You chase the fix and hit another pile of bottlenecks. You finally have something, but you hesitate to open a PR—you don’t want yet another design debate.

Standup is in 10 minutes. You’ll say, “I’m making progress,” even though you know it’s nowhere near true. And all of this before a 2-hour planning meeting that will destroy your energy.

Now, you’re chatting with the AI again to review the code and fix what’s fixable. You don’t care anymore about reading that code—your colleagues will review it anyway.

If this feels familiar, you’re not alone—and it’s not about the code.

The Paradox We Don’t Talk About

Here’s something strange about software engineering: we’ve learned to speak with absolute precision to machines. We can express complex logic, handle edge cases, and architect systems that process millions of requests. Our IDEs autocomplete our thoughts. Our types catch our mistakes before runtime.

But when it comes to talking about how we feel about our work? We’re terrible at it.

We communicate fluently in TypeScript and Python, but we stumble over admitting we’re anxious about a deadline. We can articulate the difference between eventual consistency and strong consistency, but we can’t articulate why we feel inadequate when a colleague ships faster than we do.

We’ve optimized for machine communication at the expense of human connection.

And somehow, that precision we demand from our code has bled into how we see ourselves. We want to be perfect. We want our solutions to be elegant, our architecture to be flawless, our knowledge to be complete. And when we inevitably fall short of that impossible standard, we don’t talk about it. We just carry it.

The situation gets worse in company cultures that treat people like machines. Requirements in, code out. No time for mistakes. No room to fail.

Where This Comes From

This isn’t new. It’s not unique to software engineering. But it hits us harder because of how we got here.

Think back to how many of us ended up in tech. Growing up, we were the kids who got good grades—or just people who were good with computers. We were praised for being smart, for knowing how to deal with tech, for solving problems.

Our parents, our teachers, our entire environment reinforced a simple equation: being the best = being valuable.

We internalized that. We learned that our worth was tied to our performance. That being good wasn’t good enoug—we had to be the best.

When you carry that mindset into a career like software engineering—where there’s always more to learn, always someone who knows more, always a better way to solve the problem—it becomes a weight you can never put down.

That voice that says “this code isn’t good enough yet” isn’t really about the code. It’s the echo of every time we were told to do better, be better, try harder. It’s the internalized belief that if we’re not perfect, we’re not worthy.

In a still male‑dominated field, many of us absorb quiet rules of restraint: stay composed, avoid showing doubt, handle it alone. Those norms make it harder to ask for help or name it when we’re stuck.

“I’m fine” becomes our default API—even when we feel like we suck.

How It Shows Up Every Day

Here’s the cycle:

Perfectionism stops you from starting. You hold back code because you’re not sure the approach is “right.” You avoid asking in Slack. You don’t share work until it’s over‑polished.

That perfectionism turns into procrastination. You spend hours searching for the “best” solution instead of shipping the working one. You refactor the same function again. You wait for the perfect moment—and it never comes.

Procrastination builds anxiety. The deadline hasn’t moved. Standup is coming. The PR is overdue. Expectations stay put; now you’re behind.

Anxiety then reinforces perfectionism. The stakes feel higher, so you raise the bar, second‑guess more, and delay again—completing the loop.

It’s a loop that’s hard to break.

How it can lead to burnout

Here’s how that loop showed up on my team.

I once had an engineer who struggled to finish his tasks. He’d pick up the ticket, lose confidence, and start over. Dates slipped with “I’ll have something by Monday.” But we all knew it wouldn’t happen—and found ourselves guessing what excuse Monday would bring. Ask “what’s next?” and suddenly more research has to be done. You could feel him trying to change the subject to waste time in a call, so we didn’t have enough time to discuss his progress.

Does this sound familiar? It’s the same cycle — perfectionism, procrastination, the excuses at standup.

As an engineering manager leading 16 engineers across different client projects — with two second-level managers reporting to me — I had visibility into how this pattern plays out across different teams, codebases, and stakeholder pressures. It wasn’t isolated to one project or one personality. I saw it repeat across people, seniority levels, and contexts. But what struck me most wasn’t the pattern — it was how easy it was to misjudge it.

It’s easy to call my colleague lazy, but the reality is more complicated.

He was stuck chasing perfection. This was obvious to me because I’d struggled with it for years. In fact, that’s how I ended up starting this blog in the first place. I wish I could just press a button to install this understanding in his brain, but these things are hard to accept—and even harder when someone else is flagging them for you.

There’s a useful distinction here. Researchers talk about two kinds of burnout: overwork burnout and misalignment burnout. The first is about volume—too many hours, too little rest. The second is about working on the wrong things, or feeling a persistent gap between what you value and what you actually deliver. The critical difference:

Rest fixes overwork. It doesn’t fix emptiness. You come back from vacation and the same emptiness is waiting at your desk.

My colleague wasn’t drowning in tasks. He was drowning in the distance between his internal standard and his actual output. That’s misalignment burnout dressed as procrastination. And it’s harder to spot—because from the outside, it just looks like someone isn’t trying hard enough.

Over time, the anxiety can spread. It’s not just one deadline—it shows up in standups, when replying in Jira, and when you’re thinking about work in the evening. That’s worth noticing.

And what’s our coping mechanism? Lunch break, you open the app to decompress; the algorithm pulls up a chair and serves fear with a side of envy, followed by an ad for exactly what you didn’t know you needed.

Repeat this, project after project, and you already know where it leads. You won’t rage-quit or delete your LinkedIn profile. It’s slower than that. You still show up, still deliver, but you’re running on empty.

The work that used to excite you now just exhausts you.

Ah yes, and FOMO feeds the entire cycle.

The Day I Missed the News

Staying relevant as a software engineer has become increasingly complex.

I speak at conferences about AI. I build agentic platforms. People expect me to be “on it.” And yet, I missed the model release everyone was talking about—didn’t see it until questions started landing in my inbox.

For a moment, I felt that familiar panic: if I missed this, what else am I missing? I opened five tabs, skimmed three threads, and queued up two demos. The pressure in my head went up another notch. I’m supposed to be the one who tells them what’s coming — not the other way around.

People always ask me what they should learn to stay relevant. Nowadays it’s all about AI. The question never changes; only the thing they’re afraid of does. They worry that the way their organizations work today won’t give them a competitive advantage in the job market tomorrow.

But beneath the FOMO lies something heavier: the fear that AI won’t just change how we work—it’ll erase why we work. For many of us, software engineering isn’t just a job. It’s our identity, our status, the thing that affords the life we’ve built. The apartment, the stability, the sense that we figured it out. When the ground shifts under that, the anxiety isn’t about missing a model release. It’s about losing the version of yourself you’ve spent years constructing.

No one knows what this industry looks like in five years. And that uncertainty is a breeding ground for misalignment burnout—because how do you align your work with your values when you’re not sure the work will exist tomorrow? You end up working harder on things that feel increasingly meaningless, just to stay in the game.

That’s not overwork. That’s existential drift.

The AI explosion has turned FOMO into a full-time job, and feeling incompetent next to an AI supermachine only makes things worse. Every day there’s a new model, a new framework, a new capability. Every day the frontier moves.

The myth says a “10x engineer” would keep up with all of it. Reality says we have limited time, energy, and retention.

Missing the news, or not following a new trend isn’t failure. It’s proof that I’m human—and that curation beats compulsive catching up.

How to reflect

I’m not a psychologist. I’m not going to prescribe solutions or give you a five-step plan. That’s not what this is.

All I can tell you is this: The stress you feel isn’t just about the code, your team, or the world. It’s about the unspoken expectations—the ones you place on yourself, the ones you think others have of you, the ones that come from being told to be the best for your entire childhood.

Immersive Background: Allowing self taking a break

Mo Gawdat, a former Google X engineer, wrote a book called Solve for Happy where he treats happiness like an engineering problem.

Happiness = Your Perception of Events − Your Expectations of Life

His equation is simple: unhappiness lives in the gap between your expectations and your perception of reality. Sound familiar? That’s the perfectionism loop, expressed as math. I highly recommend it — especially to engineers. It’s one of the few books that speaks our language.

Our work isn’t simple. Machines are straightforward—they do what you tell them; when they don’t, you can debug why. People are different: unclear requirements, shifting priorities, unstated assumptions, their own anxieties. We’re not as good at debugging that.

Maybe naming it helps. Maybe knowing your teammates feel the same way helps too—you can help each other. Maybe realizing perfectionism isn’t a virtue—it’s conditioning—gives you permission to be kinder to yourself.

Or maybe it doesn’t. Maybe this is just one more thing to think about, one more weight to carry.

But at least now we’re talking about it.

A Personal Note

I wrote this after stepping back for a while from the content creation habits. I needed to slow down before I burned out completely. And it was a very hard decision to make. I had to force myself to do it.

It’s easy to think that stepping back means falling behind. That if you’re not constantly productive, learning, shipping, you’re losing ground. But sometimes the most productive thing you can do is give yourself space to breathe.

The perfectionism, the anxiety, the feeling that you’re falling behind is something we all carry at a certain degree. It doesn’t mean something’s wrong with you. It means you’re human, working in a field that moves fast and demands a lot.

The work will still be there tomorrow. The frameworks will still be there. You don’t have to know everything, be everything, or keep up with everything to be a good engineer.

A few things to sit with:

The code doesn’t have to be perfect to be valuable
Knowing everything is not the job - solving problems is
Anxiety about your work is not the same as caring about your work
It’s okay to say “I don’t know” and “I need help”
The 10x engineer who knows everything doesn’t exist, and pretending they do hurts everyone
If rest doesn’t help, the problem might not be the workload — it might be what the work is

Most AI never ships. Here's what does.

Fri, 07 Nov 2025 22:12:00 GMT

Generative AI is often overhyped, creating unrealistic expectations that frequently lead to failure.

You see, big tech companies promote their AI models as magical solutions, conveniently ignoring their flaws. Social media bombards us with fear-mongering and false promises designed to capture attention. And did you see those massive investments?

This often creates a pattern in company meetings: People unfamiliar with the technology get overly enthusiastic about its potential, pushing teams down risky paths. Other folks are way more conservative, slowing down huge transformation opportunities.

So how do you cut through the noise? How do you build AI products like a boss, without falling into traps?

Let’s talk about the realities nobody mentions in the keynote presentations. So when business is screaming “Profit! Profit! Profit!” and engineering pushes back with “That will end really badly”, let me help you bridge the gap between hype and reality.

This article is that guide—my Holy Grail of AI.

Amen! 🙏

1. Most AI product pilots fail. And fail hard.

Here’s a stat that should make every product manager sweat: 95% of generative AI pilots at companies are failing.

Not “struggling.” Not “underperforming”.

And it’s not because the models are broken. It’s because companies have no idea how to actually ship AI features that users adopt.

Think about it: your competitors are building AI chatbots, recommendation engines, and automated workflows. Everyone’s racing to slap “AI-powered” on their feature list. But here’s what nobody talks about in those shiny product demos—most of these pilots never make it past the experiment phase.

Megan is one of the most entertaining deadly AI Sci-fi characters. You definitely don’t want your kid to be next to her.

Common reasons why AI product features fail:

The “me too” strategy — You’re adding AI because your competitor announced an AI feature last quarter. Not because users are actually asking for it.
Wrong automation targets — Teams automate complex, opaque workflows where AI errors are invisible until they explode. Instead, start with simple, transparent tasks where hundreds of users can immediately spot when something’s off.
Testing happy paths only — Single question-and-answer? Easy to test. Multi-turn conversations that stay coherent and on-track for 10+ exchanges? That’s where most teams discover their AI is actually terrible.
The elephant in the room — The research is clear: businesses are investing in the flashy, visible AI features that look good in demos, but they’re missing the real opportunity to save money and improve efficiency by automating their internal workflows.

You’re building AI features in the wrong places, for the wrong reasons.

The harsh truth? Most companies treat AI pilots like innovation theater. Build a demo. Show it to executives. Get the green light. Ship to production. Then watch user adoption flatline because nobody actually needed the feature you built.

Before you start your next AI pilot, ask yourself: “If this feature disappeared tomorrow, would users complain?” If the answer isn’t a clear yes, you’re about to become part of that 95%.

2. AI replaces tasks, not jobs

Companies are doing mass layoffs and blaming it on AI. We see the headlines every week. Although there is no guarantee that AI is the one to blame here, we are expecting many jobs to be replaced by AI in the following years. And as this technology evolves, more jobs will be at risk.

There’s something you don’t read in the news, though: AI reliably replaces tasks, not whole jobs. And for many workflows, fully removing human judgment is far riskier and more expensive than it looks.

In the TV series Severance, workers sort numbers on a screen and delete the ones that feel “wrong”, though no one knows why.

A typical working day at the office, in the series “Severance”.

This is closer to reality than you might think. AI still requires human oversight to ensure important matters aren’t overlooked. The so-called “human in the loop” is not just a catchy phrase to use in your slides, it’s the difference between a working product and a liability.

Companies that treat AI as “set-and-forget” build up hidden costs that only become obvious when things break:

Data quality gaps — garbage in, garbage out, but now at scale
Eval and monitoring debt — no one’s watching what the AI actually does in production
Loss of user trust — one simple anomaly can undo months of credibility, especially when user personal data are involved
Compliance exposure — regulators don’t accept “the AI did it” as a defense
Brittle operations — systems that can’t adapt when edge cases inevitably appear

The companies cutting people to the bone will learn this the hard way when their AI products fail in production.

You want people in your company who enjoy meaningful work and bring critical thinking to the table. That’s where productivity and innovation begin. You don’t want a skeleton crew babysitting AI outputs all day, catching mistakes after the damage is done.

Next time you approach AI as a way to replace human labor, just think twice!

3. There’s always a chance to hallucinate

LLMs will generate content that’s completely false—and present it to you as fact. No matter how hard you try, there’s always a possibility AI will hallucinate.

And believe it or not, that’s a feature, not a bug. Sometimes we do want a model to think out of the box. To be creative.

Steven Spielberg’s film “Artificial Intelligence” is playing with our emotions asking whether a human android that looks and behaves like a human is a human.

But here’s the thing: when the stakes are high—financial decisions, medical advice, legal guidance—you can’t afford to guess. That’s when AI slop can turn from interesting quirks into a disaster.

The risk isn’t that AI will hallucinate. The risk is building systems that assume it won’t.

On a positive note, there are tools that can help you catch some hallucinations:

Models with larger context window are less prone to making mistakes
Consider adding cloud-based guardrails into your solution
Another LLM can play the role of the “police” to validate the generated content
Ground answers: retrieve sources and require citations to exact spans
Use agentic tools for truth: DB queries, APIs, calculators via function calling
Constrain outputs: JSON schemas or grammar; answer only if supported

These are just a few strategies to mitigate risk. The key is to layer multiple safeguards. No single technique eliminates the problem entirely, but combining them significantly improves reliability.

4. Any software is prone to bugs.

Remember, AI software is still software.

No matter how many tests you’ve written, even if you’re Uncle Bob himself, there is no way to end up with a bug-free application. This means even when the AI generates correct output, bugs in your integration code, API calls, or data pipelines can still produce false results.

But there’s a catch!

Sometimes in client meetings, I feel like Lisa Simpson, voicing skepticism to an audience that doesn’t want to hear it.

The key difference between a bug in an AI product versus regular user interfaces: AI fails by producing plausible-but-wrong outputs that flow straight to users or downstream systems. Errors aren’t obvious dialogs; they look like truths.

UI bugs cost minutes; AI bugs cost trust.

Now is the time to enforce the engineering and architecture principles in your product that you may have overlooked before. You know all those debates about test-driven development and continuous integration? They matter more than ever when AI is in the mix. And the irony is you can use AI to integrate them faster.

Conduct security assessments and build guardrails to verify AI-generated content before it reaches end users.

5. AI is not inherently ethical.

One of the unwritten rules of the real Agile development manifesto is “bonuses and promotions over ethical considerations”. And “we’ll pay our lawyers to cover our crap (sic). Pretty soon we will use AI lawyers so we won’t have to pay those either”.

Ethical design is not a choice. Companies that cut corners on ethical AI implementation risk significant damage to their brand reputation and may face substantial financial and legal consequences.

To put it simply, customers will always prefer companies that are more ethical.

Imagine how different the UX would have been if Theodore (Joaquin Phoenix) wouldn’t know that he’s talking with an AI. Hm, a bad example I guess?

We can’t keep AI responsible for human lives. We can’t let AI make decisions that put people in trouble. The EU AI Act introduces stricter regulations to prevent misuse of this technology. Because that’s what we like to do in EU, we regulate everything. Several other countries are developing their own rules.

The 2025 DORA report found that 70% of IT leaders cite regulatory compliance as their top GenAI challenge.

I know this topic is very abstract to many of us. Here are some practical tips:

Always inform your users that you use AI — Transparency builds trust. Ultimately, you can provide users with reasoning or confidence scores, especially for high-stakes outcomes.
Implement audit logs — Record all AI interactions, decisions, and overrides for compliance and retrospective analysis. When something goes wrong, you need a trail to understand what happened.
Embrace human in the loop — Before AI commits to consequential decisions (financial transactions, medical advice, legal filings) add confirmation steps. A moment of human review can prevent catastrophic mistakes.
Create feedback loops — Let users flag bad outputs and show them that their feedback improves the system. This empowers users and helps you catch issues early.

6. Everyone is a hacker now

Vibe coding was the trend of 2025. Creating applications was never that easy. It’s just you in the safety of your couch, having a team of engineers building whatever comes to your mind, in seconds.

If it’s so easy to write code, why not vibe code the sh*t out of it?

When I was studying at my university, I was always amazed by those assembly simulators and how much the technology had evolved during that time. I felt blessed I was born at that time, and I didn’t have to deal with those low-level coding languages. Back then, I couldn’t even imagine what an iPhone was, or that cars would be able to drive themselves.

Watch how teens react to old technology.

Now imagine the kids growing up with AI-powered coding assistants. They’ll have capabilities that took us years to build, available from day one.

This democratization of development has a darker side. Before, you needed advanced programming and system knowledge to exploit vulnerabilities. Now, anyone with basic language skills can attempt to hack a system by simply describing what they want to accomplish. The barrier to entry for both creation and exploitation has dropped dramatically.

But the real problems emerge when vibe coders try to scale:

Initial productivity doesn’t scale — Vibe coding delivers rare bursts of speed on one-off scripts, but once you need to maintain and evolve code, those gains evaporate quickly
Sites actually get compromised — Real-world evidence shows vibe coders hit a wall where their applications get hacked, forcing them to learn security fundamentals they initially skipped
Context window limitations — As apps grow beyond AI context windows, generated code becomes inconsistent in both appearance and functionality
Poor code quality from training data — LLMs are trained on a mix of good, bad, and mediocre code from the internet, producing inconsistent quality without universal standards
Encourages unnecessary complexity — AI often encourages hastiness and over-building rather than preventing unnecessary work
Maintenance becomes a nightmare — Vibe-coded projects become difficult to modify and evolve, especially when code is regenerated from scratch rather than incrementally improved

So while my developer soul would beg for a true solution that eliminates the need to write code, we’re not there yet. It could be a great prototyping tool, though—and maybe a conversation starter for your next Scrum planning session. 😉

Finding your balance

I know what you’re thinking. In a world where everyone talks about AI revolutionizing everything, how can we be so conservative? It’s true—AI will eventually become what you envision. But current AI iteration is just a stepping stone.

We are not there yet.

Every AI success story starts the same way: someone identified a specific problem, built a constrained solution, and put guardrails around it.

They didn’t try to automate everything at once. They didn’t skip testing because “the model is really good now.” And they definitely didn’t fire half the team and hope AI would pick up the slack. The teams that win with AI are the ones who treat it like any other powerful, yet imperfect, tool.

Generative AI technology is powerful. It’s transformative. But it’s also immature, unpredictable, and prone to spectacular failures when misused. And that’s why we love it.

It reminds us of us.

Takeaways (summarized by AI, of course):

Build verification into everything — Audit logs, human review checkpoints, confidence thresholds, feedback loops. If you can’t explain how you’ll catch mistakes, you’re not ready to ship.
Solve real problems, not imaginary ones — Before you add an AI feature, ask if users are actually asking for it. If the answer is no, you’re about to waste a lot of money.
Automate the boring stuff first — Start with simple, transparent tasks where mistakes are obvious. Save the complex workflows for later, once you’ve learned how AI actually behaves in your system.
Critical thinking over massive layoffs — The companies that treat AI as a headcount replacement will discover the hard way that babysitting AI outputs is way harder than doing the work properly from the start.

Let me know what your thoughts are on AI. You know where you’ll find me. 😉

Cover art generated with Google Gemini.

Your LLM is generic until you make it yours

Wed, 26 Feb 2025 22:12:00 GMT

The journey of working with artificial intelligence has evolved dramatically over the past few years. What started with simple prompt engineering has grown into a sophisticated ecosystem of techniques and approaches, each building upon the last to create more powerful and personalized AI solutions.

The LLM customization options. Complexity and cost increase as we move on the right.

This diagram illustrates the spectrum of AI model customization options, ranging from basic to advanced approaches. The simplest way is Prompt Engineering, which requires minimal setup. In the middle, you’ll find RAG (which helps AI access specific information) and Fine-Tuning (which adapts AI for special tasks). The most complex option is building your own AI model from scratch, which is costly and requires the most effort, but eventually gives you complete control.

In this article, I would like to elaborate more on these techniques, and explain under which circumstances you should consider them.

Prompt Engineering: The Art of Asking the Right Questions 📇

At its core, prompt engineering is the art of effectively communicating with AI models. It’s like learning a new language - one that bridges human intent with machine understanding. By carefully crafting our prompts, we can guide AI models to provide more accurate, relevant, and useful responses.

If you want to dive deeper, I have a series of articles in this blog:

The Art Of Prompt Engineering
How to structure your prompts
Five prompting techniques

This approach plays a critical role in other customization strategies. In retrieval-augmented generation (RAG), for example, the prompt must integrate external knowledge retrieved from a database seamlessly. Even in fine-tuned or custom-trained models, prompt engineering remains relevant to optimize the interaction between the user and the model. Its low cost and ease of use make it a powerful starting point for those exploring LLM customization.

However, as powerful as prompt engineering is, it has its limitations. Models can sometimes struggle with specific domain knowledge or fail to maintain consistency across responses.

RAG: Bridging Knowledge Gaps 📚

AI models have a distinct knowledge cutoff date and are trained on a generic set of information. When you need to “educate” your model with domain-specific knowledge, RAG is the simplest and most efficient way to accomplish this.

Retrieval-Augmented Generation (RAG) emerged as a natural evolution to address the limitations of prompt engineering. By combining the language model’s capabilities with specific, retrievable knowledge, RAG creates a more informed and accurate system. Think of it as giving the AI access to a specialized library of information that it can reference while formulating responses.

RAG Flow

When a user asks a question, the system searches our knowledge base for relevant documents. These documents, along with the user’s original question, are then passed to the LLM. The LLM combines its existing training data with this provided information to generate a response.

RAG works with various types of databases. You can call a public API and use its response, perform a web search and analyze its results, or use traditional databases. The system works as long as the content fits within the LLM’s context window and you can create a meaningful query from the user’s prompt. Both requirements can be challenging, though. To overcome the limitations of conventional APIs and databases, RAG implementations often combine search indexing and vector databases.

A vector database is a special type of database that stores high-dimensional vectors representing the semantic meaning of text, images, or other data. These vectors allow for similarity searches, making it possible to find relevant information based on meaning rather than just keywords. When integrated with RAG, vector databases enable more nuanced and contextually accurate information retrieval.

For example, in a vector space, the words “cat” and “dog” would be closer together than either word is to “apple”. This is because “cat” and “dog” share many semantic properties (they’re both pets, mammals, domestic animals), while “apple” represents a completely different concept (a fruit). When these words are converted to vectors, this semantic similarity is reflected in the mathematical distance between their vector representations.

Fun fact: LLMs also use dense vector embeddings as part of their neural network architecture to represent and process language. This means that when you input text to an LLM, it first converts your words into these mathematical vectors to process their meaning and relationships before generating a response. This deep understanding of semantic relationships is what enables LLMs to generate contextually appropriate and coherent text. The larger the vector space, the more nuanced these relationships become, enabling the model to capture increasingly subtle distinctions in meaning.

RAG is particularly useful for companies that need to work with their own private information or specialized knowledge that regular AI models don’t know about. Companies can use RAG to help their AI systems access and understand internal documents, research, technical guides, and industry information while keeping everything secure and accurate. By combining the AI’s general knowledge with a company’s specific information, RAG becomes a valuable tool that helps businesses stay competitive while making the most of AI technology.

Fine-tuning: Teaching the Model New Tricks 🎚️

While RAG enhances a model’s knowledge, fine-tuning goes a step further by actually modifying the model’s behavior. It’s like sending an experienced professional back to school for specialized training.

Through fine-tuning, we can adapt existing models to better understand specific contexts, terminology, or ways of communicating. You show it lots of examples of questions and the kinds of answers you want it to give. This teaches the AI to respond the way you want without needing detailed instructions every time you ask it something.

Fine-tuning enables models to maintain consistent tones, incorporate standard information (like support contact details), and perform specific actions such as referencing documents or databases. However, this approach requires extensive training data and multiple iterations to achieve desired results. This can be challenging, often requiring significant trial and error before reaching optimal performance. Also, not all LLMs support fine-tuning.

I strongly recommend starting with simpler, more cost-effective solutions before moving to complex approaches. The ideal progression is to first exhaust the possibilities of prompt engineering, and RAG to enhance the model’s knowledge base, or explore building agentic applications that can coordinate multiple AI capabilities. Only after thoroughly testing these approaches should you consider fine-tuning, which demands significantly more resources and technical expertise.

Despite these challenges, fine-tuning is valuable when you need consistent responses for large-scale operations. It gives you better control over how the LLM behaves than foundation models do, making responses more predictable and reducing unwanted variations.

Training Your Own LLM: The Ultimate Customization 🐉

For organizations with unique needs and substantial resources, training a custom LLM represents the pinnacle of AI customization. This approach offers complete control over the model’s capabilities and biases, but it comes with significant computational and data requirements.

Training your own LLM requires massive datasets, specialized expertise in machine learning, and substantial computing infrastructure. While this approach provides unparalleled customization potential, it’s typically only feasible for large tech companies or organizations with significant AI research capabilities. The costs can run into millions of dollars, making it crucial to carefully evaluate whether the benefits justify such an investment.

That’s all folks! 🙌

Thanks for reading! Stay tuned for more content about prompt engineering! I’ll be sharing advanced techniques, real-world examples, and practical strategies to help you master the art of communicating with AI. My newsletter form is just a few DOM elements below. Don’t forget to subscribe to get notified when new articles are published.

Do you have any other tips for crafting better prompts? I’d love to hear your thoughts and experiences.

Cover art generated with Adobe Firefly.

The advanced prompting techniques worth learning

Mon, 10 Feb 2025 22:12:00 GMT

I’ve curated these advanced prompting techniques and strategies from my personal experience and ongoing learning journey. These techniques will help you elevate your prompts by achieving results that are challenging to get.

I’ve written everything in plain, simple language, without using complex math or scientific terms. This is just an overview, though. Each technique deserves its own detailed article—which I plan to write for some of them in the future.

Since prompt engineering is always changing, I’ll keep updating this guide with new tips and best practices as I discover them.

Let’s see what we’ve got! 🥁

Iterative prompt evaluation 🧪

As Generative AI transforms industries, effective prompt engineering has become essential for optimizing output quality, speed, and costs. Prompt evaluation is crucial but challenging for organizations developing AI solutions. Many struggle to maintain consistent prompt quality across applications, leading to variable performance and user experiences.

Just like agile development involves iterative cycles of planning, building, and refining, prompt engineering requires continuous experimentation and improvement. You start with a basic prompt, test it, analyze the results, and then make adjustments based on what you’ve learned. This cycle repeats until you achieve the desired outcome.

Prompting is an iterative approach.

The iterative approach involves continuously refining and improving your prompts through multiple attempts. Instead of expecting perfect results on the first try, you experiment with different phrasings and structures to get closer to your desired outcome. This method helps you understand what works best for specific tasks while building an intuition for effective prompting.

A prompt without evaluation is like a ⛴️ ship without a 🧭 compass.

To create test cases for prompt evaluation, start by defining the objective — what the prompt is intended to achieve. This can include factors like accuracy, relevance, creativity, clarity, and ethical compliance. Identify scenarios based on real-world use cases, edge cases, negative cases, and exploratory cases. For each test case, document the input prompt, expected output, evaluation criteria, priority, and any additional notes to provide context.

Evaluation metrics are critical for assessing the quality of outputs. Metrics can include precision and recall, BLEU/ROUGE scores, user satisfaction ratings, and compliance with ethical guidelines. Test cases should cover a variety of situations, from straightforward tasks like summarization to safety-critical negative cases where the model must avoid harmful outputs. Automating tests through frameworks like LangChain, LangSmith, DeepEval, or other prompt evaluation tools can streamline the process, while A/B testing helps identify the best-performing prompts.

Finally, human-in-the-loop systems and feedback mechanisms are essential for refining prompts. By iteratively testing and analyzing results, you can ensure that prompts are optimized for their intended use, whether for generating content, answering questions, or interacting ethically as a chatbot.

Chain-of-Thought (CoT)

Solving structured problems step-by-step with prompts like “take your time” and “think step by step how to solve the problem” are related to the Chain-of-Thought prompting technique. It’s a powerful approach to guide the conversation coherently and logically. It involves building gradually on the previous parts of a response to create a flow of thoughts.

Here’s an example:

The AI will most likely follow a step-by-step reasoning similar to the following:

First, examine if there were any recent changes in product pricing or quality.
Next, consider external factors, such as competitors’ actions or market conditions.
Finally, assess if there were any shifts in customer demographics or preferences.

This methodical approach leads to more comprehensive and well-reasoned responses by breaking down complex problems into manageable steps, allowing for thorough analysis at each stage. The result is a more detailed, logical, and carefully considered output that captures nuances that might otherwise be missed with a more direct approach.

The effectiveness of Chain-of-Thought prompting depends heavily on how well you start the reasoning process. If you begin with incorrect thinking, each following step can make the problem worse, leading to wrong conclusions.

This method has one main drawback: it can only move forward in one direction. Once you follow a particular path of thinking, you can’t go back to try different approaches or rethink your earlier decisions. This can be especially limiting when dealing with complex problems that might need you to explore multiple solutions at the same time.

Also, this technique isn’t great for problems that need creative thinking or sudden insights, since it works best with step-by-step logical thinking.

Prompt Chaining

Prompt chaining is a technique where you break down a complex task into a sequence of smaller, focused prompts that build upon each other. Instead of trying to get the perfect response with a single prompt, you create a chain of prompts where each one refines or builds upon the output of the previous one.

Think of it like a conversation where each question naturally leads to the next, gradually working towards your goal. This approach gives you better control over the output quality since you can guide the AI more precisely at each step. It’s easier to detect errors and correct them at an early stage, as you can identify exactly where in the chain things might go wrong. You also get more detailed and thorough results since each prompt can focus on a specific aspect of the task.

We start with a simple request:

Using the previous pair of prompt and prompt response as a “conversation memory”, we prompt the AI to optimize the result:

We try again:

And again:

As shown in the example above with the AWS architecture design, each prompt in the chain addresses a different aspect of the solution — from initial design to optimization, error handling, and scalability. This systematic approach helps ensure that all important aspects are covered thoroughly.

Popular orchestration frameworks like LangChain provide simple APIs for chaining your prompts.

Reasoning & Acting (ReAct)

When working with dynamic tasks that require adaptive reasoning and actions based on feedback, the Reasoning & Acting prompting technique delivers excellent results. It enables intelligent problem-solving through a continuous cycle of observation, analysis, and response.

This method works best when you need to try things out in the real world and learn from the results. It’s particularly useful for solving tricky problems where you need to adjust your approach based on new information and changing situations.

ReAct is inspired by the fundamental synergies between “acting” and “reasoning” which allow humans to learn new tasks and make decisions through a natural process of observation, reflection, and adaptive response.

Here’s an example:

Similar to CoT, just by adding this key phrase at the end, we expect the AI to come up with two components: Reasoning and Action.

Reasoning:

Serverless is ideal for scalability and low initial cost but may have higher long-term costs for high workloads. Development is quick due to the reduced infrastructure management.
Containers provide better control and portability with a balance of cost and scalability but require more setup and maintenance.
VMs offer the most control and flexibility but can be costly and require significant maintenance, slowing development speed.

Action: How do serverless, containers, and VMs compare in terms of scalability?

Following the ReAct approach, we now use the AI’s suggested action as our next prompt:

This iterative process allows us to make decisions based on concrete observations rather than assumptions, adjust our approach as we gather more information, and break down complex technical decisions into manageable steps.

The power of ReAct lies in its ability to combine analytical thinking with practical action steps, leading to more thorough and well-considered solutions.

Tree of thoughts

The Tree of Thoughts technique is a structured approach for tackling complex problems that have multiple possible solutions. It works by breaking down the decision-making process into four key steps:

first identifying all possible approaches to the problem,
then evaluating and scoring each approach for feasibility,
followed by a detailed exploration of the most promising solution,
and finally concluding with a selection of the best option based on the evaluation.

Here’s an example:

The AI will generate multiple migration strategies:

Strategy A

Lift and Shift Using Azure Data Migration Service (DMS)

Thought 1: What are the advantages of using Azure DMS for a straightforward lift-and-shift migration? (e.g., minimal code changes, faster migration setup)
Thought 2: What are the limitations of a lift-and-shift approach in this context? (e.g., potential data model mismatches between relational and NoSQL, need for reindexing)
Thought 3: What additional optimizations would be necessary post-migration, such as adjusting indexing or partitioning to align with Cosmos DB’s architecture?

Strategy B

Data Model Transformation with Schema Redesign

Thought 1: How could a schema redesign help optimize the data model for Cosmos DB? (e.g., moving from relational to document-based modeling, denormalization for performance)
Thought 2: What challenges might arise when transforming the schema for Cosmos DB, especially regarding data consistency or query patterns? (e.g., handling joins, adapting to a non-relational mindset)
Thought 3: What tools or strategies could assist in the schema redesign process, such as Cosmos DB’s Data Migration tool, or hybrid models that gradually phase in new data structures?

Strategy C

Hybrid Migration with Incremental Data Sync

Thought 1: What benefits could a hybrid migration provide by syncing new data to Cosmos DB incrementally? (e.g., reduced downtime, ability to test Cosmos DB performance on real data)
Thought 2: What complexities could arise with maintaining data consistency across both databases during migration? (e.g., handling real-time syncing, conflict resolution)
Thought 3: How might we design an efficient syncing and switchover process, such as using Azure Functions for event-driven updates or a staged migration approach?

Now, we prompt the AI to evaluate the generated approaches and to select the one that best aligns with the target that we have:

This method is particularly useful when dealing with ambiguous problems and trade-offs that require careful consideration of multiple alternatives.

X-Shot Prompting

In prompt engineering, “shot” refers to the number of examples provided to guide the AI model. When we talk about “X-shot” prompting, we’re describing how many examples we’re giving the model to help it understand the pattern we want it to follow.

By default, when no examples are provided (zero-shot), the model relies solely on its training data and the task description in the prompt to generate responses. As we increase the number of examples - whether it’s one-shot (single example), few-shot (several examples), or many-shot (numerous examples) - we give the model more context to understand the specific pattern or format we’re looking for. This approach helps the model better align its responses with our expectations and requirements.

Here’s an example:

In this example, we’re showing how to classify sentiment in customer messages. The prompt starts by clearly stating the task “Classify the sentiment” and then provides 5 examples that demonstrate different types of sentiment. These examples help the AI understand the nuanced differences between sentiments and how to categorize them appropriately. Notice how each example includes both the message and its classification, creating a clear pattern for the AI to follow.

Different AI models have varying abilities to learn from examples. Some advanced AI models can understand and copy patterns after seeing just a few examples. Other AI models need more examples to do the same task well.

That’s all folks! 🙌

Do you have any other tips for crafting better prompts? I’d love to hear your thoughts and experiences.

Cover art generated with Adobe Firefly

Five prompt tweaks that actually make a difference

Tue, 17 Dec 2024 22:12:00 GMT

I was looking forward to posting these prompt engineering tips below. Whether you’re a developer, content creator, or just someone curious about AI, this article will give you five simple ideas that will vastly improve the way you interact with AI models, and save you some bucks.

These insights come from extensive experimentation and real-world applications. They aren’t just theory — they’re proven techniques that will make your AI interactions more efficient, accurate, and productive.

Camera? Lights? Let’s go! 🎬

Tip #1 — **Allow the model to fail.** 🤷‍♀️

The fundamental principle of giving AI models permission to acknowledge their limitations. The “license to kill” — Ahm, I’m sorry, I mean… the “license to say I don’t know” — is one of your weapons against hallucinations.

By explicitly allowing the model to admit when it doesn’t know something or is uncertain, we create a more reliable and trustworthy interaction. This approach not only reduces the likelihood of incorrect responses but also helps establish a more honest dialogue between user and AI.

This approach helps create a more natural interaction where the AI can be upfront about its limitations.

Tip #2 — **Use leading words.** 🚏

Leading words are specific terms or phrases that guide the AI model’s response in a particular direction. They act as signposts, helping to frame the context and shape the output in the desired way.

When strategically placing an incomplete sentence or structural element at the end of your prompts, these leading words serve as powerful directional cues that naturally guide the model toward completing the thought in a specific way. This method works by using the AI’s natural tendency to complete thoughts in a logical way. When you leave an unfinished thought or pattern, the AI will try to complete it in a way that makes sense.

I mean, if we oversimplify it, at its core, Generative AI is essentially a sophisticated text prediction algorithm, right?

Here’s an example:

By providing SELECT name, age as a leading phrase, we’re essentially giving the model a clear starting point. The AI will naturally continue with the FROM clause and WHERE conditions to complete a valid SQL query. This technique works particularly well for structured outputs like code, queries, or any format with a well-defined syntax.

The beauty of using leading words is that they subtly guide the AI without being overly prescriptive, allowing for both accuracy and flexibility in the response.

Tip #3 — Ask the model to evaluate a prompt and suggest changes 👩‍💻

We spend time crafting the perfect prompt to properly instruct the AI. But what if we ask the AI itself to help us perfect our prompts?

When a colleague mentioned trying this technique and getting the results we wanted, I was eager to try it myself. I’ve been amazed by how effectively this works. I shouldn’t be surprised. The truth is, AI knows how to talk to… AI.

Asking the AI to improve my prompt.

By asking the model to analyze and suggest improvements to your prompts, you can leverage its deep understanding of effective prompt structures and patterns. The model can help refine your prompt’s structure and relevance, fix language issues like typos and grammar, and identify potential edge cases you might have overlooked.

This collaborative approach between human and AI can lead to more precise, efficient, and effective prompts that better achieve your desired outcomes.

Tip #4 — **Use a mix of hard and soft prompts 🍬**

There are two main types of prompts you can use when talking to AI: hard ones and soft ones.

Hard prompts give clear, specific instructions that help you get exact answers. They will work great when you need precise information or are working with technical stuff.

Soft prompts, on the other hand, give the AI more room to think creatively and suggest different solutions. They’re useful when you want the AI to explore options or think outside the box.

Combining both hard and soft prompts creates a powerful synergy in your interactions with AI. You can be precise when needed while still letting the AI suggest new and interesting solutions.

First, provide a hard prompt outlining the specific steps, inputs, desired output, and performance constraints

Produced code

from time import time
from collections import defaultdict

class RateLimiter:
    def __init__(self):
        self.buckets = defaultdict(lambda: {"tokens": 100, "last_refill_time": time()})
        self.max_tokens = 100
        self.refill_rate = 100 / 60  # tokens per second

    def is_allowed(self, user_id):
        now = time()
        bucket = self.buckets[user_id]

        # Refill tokens
        elapsed_time = now - bucket["last_refill_time"]
        refill_tokens = elapsed_time * self.refill_rate
        bucket["tokens"] = min(self.max_tokens, bucket["tokens"] + refill_tokens)
        bucket["last_refill_time"] = now

        # Check if a token is available
        if bucket["tokens"] >= 1:
            bucket["tokens"] -= 1
            return True, bucket["tokens"]
        else:
            return False, bucket["tokens"]

# Example Usage
rate_limiter = RateLimiter()

def api_request(user_id):
    allowed, remaining_tokens = rate_limiter.is_allowed(user_id)
    if allowed:
        return {"status": 200, "message": "Request allowed", "remaining_tokens": remaining_tokens}
    else:
        return {"status": 429, "message": "Too Many Requests", "remaining_tokens": remaining_tokens}

# Simulate API requests
print(api_request("user_1"))
print(api_request("user_1"))

Once the initial solution is developed, you could offer a soft prompt encouraging LLM to consider potential improvements, optimizations, or alternative approaches.

AI Recommendations

Here are the recommendations made earlier for improving the rate limiter implementation:

Optimize Data Storage
- Use Bloom filters for preliminary checks.
- Employ sharded storage for distributed caching.
Enhance Token Refill Strategy
- Implement lazy refills to avoid unnecessary computations.
- Use sliding window rate limiting to smooth out request spikes.
Handle Edge Cases
- Combine token bucket with leaky bucket for burst handling.
- Include a Retry-After header in responses.
- Adapt to user behavior dynamically for fair limits.
Enhance Scalability
- Introduce hierarchical rate limiting (user, IP, API key levels).
- Offload rate limiting to an edge service (e.g., CDN or API gateway).
- Prefetch user buckets to reduce latency during peak usage.
Support Multi-Tenancy
- Enable dynamic rate limits based on user tiers (e.g., free vs. premium users).
- Differentiate between global and local rate limits for better efficiency.
Optimize Distributed Systems
- Use Redis Lua scripts for atomic token updates.
- Preallocate tokens across distributed nodes.
- Accept eventual consistency for slight discrepancies in distributed setups.
Real-Time Monitoring and Adjustments
- Implement adaptive limits based on system health metrics.
- Log request details for analysis and anomaly detection.
User-Friendly Enhancements
- Provide a quota display API for users to check their limits.
- Allow grace periods for minor over-limit violations.
- Escalate penalties for repeated violations (e.g., temporary blocks).
Leverage Machine Learning
- Use predictive rate limiting to anticipate traffic patterns.
- Detect abuse or anomalies with AI-powered fraud detection.
Fail-Safe Mechanisms
- Use fallback policies to allow limited requests during backend failures.
- Prioritize critical users to ensure system availability during high traffic.

Finally, once we get a clear list of enhancements, we ask the AI to refactor the previous example:

Revised code

from time import time
import redis
import math
from flask import Flask, request, jsonify

app = Flask(__name__)

# Initialize Redis connection
redis_client = redis.StrictRedis(host="localhost", port=6379, db=0)

# Constants
MAX_TOKENS = 100
REFILL_RATE = 100 / 60  # tokens per second

def get_current_bucket(user_id):
    """Fetch or initialize a user's bucket."""
    bucket = redis_client.hgetall(user_id)
    if not bucket:
        # Initialize a new bucket with full tokens
        redis_client.hmset(user_id, {"tokens": MAX_TOKENS, "last_refill_time": time()})
        redis_client.expire(user_id, 3600)  # Expire bucket after 1 hour of inactivity
        return {"tokens": MAX_TOKENS, "last_refill_time": time()}
    return {k.decode(): float(v) for k, v in bucket.items()}

def save_bucket(user_id, bucket):
    """Save the updated bucket state."""
    redis_client.hmset(user_id, {
        "tokens": bucket["tokens"],
        "last_refill_time": bucket["last_refill_time"]
    })
    redis_client.expire(user_id, 3600)  # Extend TTL on activity

def refill_tokens(bucket):
    """Refill tokens based on elapsed time."""
    now = time()
    elapsed_time = now - bucket["last_refill_time"]
    new_tokens = elapsed_time * REFILL_RATE
    bucket["tokens"] = min(MAX_TOKENS, bucket["tokens"] + new_tokens)
    bucket["last_refill_time"] = now
    return bucket

def is_request_allowed(user_id):
    """Check if a user request is allowed."""
    bucket = get_current_bucket(user_id)
    bucket = refill_tokens(bucket)

    if bucket["tokens"] >= 1:
        bucket["tokens"] -= 1
        save_bucket(user_id, bucket)
        return True, bucket["tokens"], None
    else:
        retry_after = math.ceil((1 - bucket["tokens"]) / REFILL_RATE)
        return False, bucket["tokens"], retry_after

@app.route("/api/resource", methods=["GET"])
def api_resource():
    user_id = request.headers.get("X-User-ID")  # Simulate user identification
    if not user_id:
        return jsonify({"status": 400, "message": "User ID missing"}), 400

    allowed, remaining_tokens, retry_after = is_request_allowed(user_id)
    if allowed:
        return jsonify({
            "status": 200,
            "message": "Request allowed",
            "remaining_tokens": remaining_tokens,
            "limit": MAX_TOKENS,
            "reset_in": 60  # Fixed time window for simplicity
        }), 200
    else:
        headers = {
            "X-RateLimit-Limit": MAX_TOKENS,
            "X-RateLimit-Remaining": remaining_tokens,
            "Retry-After": retry_after
        }
        return jsonify({
            "status": 429,
            "message": "Too Many Requests",
            "retry_after": retry_after
        }), 429, headers

if __name__ == "__main__":
    app.run(debug=True)

This enhanced version of the rate limiter showcases several key improvements over the original implementation. It utilizes Redis for distributed caching, implements proper HTTP status codes and headers, and includes user-friendly features like remaining token counts and retry-after intervals. The code structure is also more modular and maintainable, making it easier to extend with additional features in the future.

I know this may not be the most production-ready code out there, but I want to remind you that we only asked 3 simple questions.

Tip #5 — Always keep the dynamic part of a prompt at the end 💾

When crafting prompts, it’s highly beneficial to structure them with static, repetitive content positioned at the beginning, followed by the dynamic, variable content at the end. This strategic arrangement takes advantage of prompt caching mechanisms, which can significantly improve response times and efficiency.

The caching system is particularly effective for longer prompts, specifically those that exceed 1024 tokens in length, where the system automatically implements caching functionality to optimize performance.

The following image from OpenAI’s official documentation explains the concept in detail:

Source: OpenAI Documentation

The API request process follows a systematic caching mechanism. When a request is initiated, the system first performs a Cache Lookup to determine if the initial portion (prefix) of your prompt exists in the cache. In the event of a Cache Hit, the system utilizes the cached result, which leads to decreased latency and reduced costs. Conversely, during a Cache Miss scenario, the system processes your complete prompt, and subsequently caches the prefix of your prompt to optimize future requests.

This technique not only increases the performance of your LLM interactions but can also provide up to 80% cost reduction.

That’s all folks! 🙌

Do you have any other tips for crafting better prompts? I’d love to hear your thoughts and experiences.

Structure your prompts or get noise

Tue, 10 Dec 2024 22:12:00 GMT

A well-structured prompt can significantly improve the quality and accuracy of AI-generated responses. This guide will walk you through five essential steps to craft prompts that consistently deliver the results you need.

Here’s a simple framework to help you structure your prompts effectively and get the most out of AI language models. By following these steps, you’ll be able to communicate your requirements clearly and receive more accurate, relevant responses from AI systems.

The examples provided below are not complete prompts, but rather building blocks you can combine with your existing prompts to enhance your results.

Let’s examine each step in detail, and then combine them all together at the end.

Step #1 — Start with a verb

Remember how we talked about different ways to use AI language models (LLMs) in a previous article?

Here’s a simple but powerful tip: start your prompts with action words (verbs). When you begin with a clear action word, you tell the AI exactly what you want it to do. This helps the AI understand your request better and gives you more accurate results. Think of these action words as simple instructions that guide the AI to give you the kind of response you’re looking for.

Here are some examples:

You have flexibility in choosing verbs that best fit your needs - there’s no requirement to stick to these exact examples. Feel free to use synonyms or alternative verbs that clearly communicate your intended action, as long as they effectively convey the task you want the AI to perform. The key is to start with a clear, action-oriented verb that sets the direction for your prompt.

Moreover, it’s important to note that this is not an exhaustive list of LLM capabilities. Generative AI represents a rapidly evolving technology, with new use cases and applications being discovered and developed continuously. As researchers and practitioners explore novel implementations and methodologies, the potential applications of LLMs continue to expand across various domains and industries.

However, starting with an action verb in your prompt is important for two main reasons. First, it tells the AI exactly what you want it to do. Second, it helps you get better answers. When you start with a clear action word (like “write” or “explain”), you’re telling the AI precisely what kind of response you need. This makes it much more likely that you’ll get the type of answer you’re looking for.

The Lord of prompt engineering, according to AI.

Step #2 — Assign a role, job, or function

When you assign a specific role, job, or function to the AI, you provide it with important context about the expertise and perspective it should adopt. This helps the AI understand the domain-specific knowledge and terminology it should use, leading to more accurate and relevant responses. The role you assign acts as a lens through which the AI filters and structures its knowledge, ensuring the output aligns with professional standards and best practices in that field.

Here are some examples of how assigning a role can enhance your prompts and lead to more specialized responses:

When you specify “As an application security specialist” the AI will adopt the mindset and expertise of a security professional, enabling it to provide specialized insights into potential vulnerabilities, security best practices, and technical recommendations that align with industry standards for application security. This role-based context helps ensure the AI’s response focuses on security-specific concerns rather than general programming advice.

By specifying the role as a “database administrator,” the AI will focus on providing technical recommendations from a database management perspective, including insights about indexing strategies, normalization, and query optimization patterns that align with database administration best practices.

This role-based approach helps the AI adopt the appropriate tone of voice for specific domains and disciplines, ensuring that responses maintain the expected level of formality, technical depth, and professional standards for each field.

Step #3 — Provide examples

Here’s an example:

A clearly positive message about quick help
A negative message expressing frustration
A neutral question seeking information
Another positive message showing gratitude
An ambiguous message that could be interpreted multiple ways

These examples help the AI understand the nuanced differences between sentiments and how to categorize them appropriately. Notice how each example includes both the message and its classification, creating a clear pattern for the AI to follow.

The prompt then ends with a placeholder {MESSAGE} where you would insert the actual message you want to classify, maintaining the same format as the examples.

AI models learn differently from examples. Some smart AI models only need to see a few examples to understand and copy patterns. Other AI models need more examples to learn the same task properly.

It’s important to maintain a careful balance — providing an excessive number of examples can potentially constrain the model’s creative flexibility and lead to overly rigid responses that too closely mirror the provided examples rather than generating novel, contextually appropriate outputs. The key is finding the optimal number of examples that enables the model to understand the desired pattern while preserving its ability to generate diverse and creative responses.

Another important concept related to examples in prompting is fine-tuning, which is a more advanced way of teaching AI models specific patterns or behaviors. While providing examples in prompts (few-shot learning) helps guide the model temporarily for a single interaction, fine-tuning involves actually updating the model’s parameters through additional training on specific examples. This technique goes beyond the scope of this article. I highly recommend sticking with X-Shot Prompting since it effectively handles most use cases you’ll encounter.

Step #4 — Describe the desired output format

Specifying the desired output format is crucial for getting responses that match your needs.

Here’s an example:

This step involves:

setting the tone (whether formal, casual, or technical),
identifying the target audience (which helps tailor the language and complexity level appropriately),
and clearly outlining the structure or format of the expected response.

By providing these parameters, you give the model essential context about how to package and present its response in a way that will be most useful and relevant for your specific use case.

Now, you can request the model to output responses in various structured formats that align with your content needs. For example, you can specify output formats like JSON for structured data representation, XML for hierarchical document structures, Markdown for easy-to-read formatting, YAML for configuration files, or CSV for tabular data. This flexibility allows you to seamlessly integrate AI responses into your existing systems and workflows, while ensuring the output maintains consistent structure and syntax according to the specified format.

Step #5 — Provide detailed guidelines

Clear instructions are important when working with AI. When you give the AI specific rules and requirements, it better understands exactly what you want. Think of these instructions like a recipe - they help the AI know what to include and what to avoid. Just like in the example below, good instructions can turn a basic request into a clear, well-organized response.

In the example above, the guidelines provided help shape how the AI model approaches the task in several important ways. They establish the necessary components that must be included (executive summary, project scope, etc.), define the structure and organization of the content (specific sections and their order), specify the level of detail required (such as including a detailed timeline table), and set expectations for the conclusion (ending with a specific call-to-action).

These guidelines serve as constraints that help the AI model generate more focused and relevant output. Without such specific guidelines, the response might be too general or miss important elements that you need. Think of these guidelines as quality control measures that ensure the AI’s output meets your specific requirements and standards.

Putting everything together

Start with a role:

Provide examples:

Specify the output:

Provide Guidelines:

Define the task:

To enhance your prompts further, consider incorporating additional contextual elements. This includes providing relevant technical documentation and background information, backing up your prompts with supporting statistics and data, including previous conversation history, and the last message from the user that the LLM needs to respond to.

That’s all folks! 🙌

These tips for writing better prompts are really helpful, but keep in mind that there’s no one-size-fits-all approach. What works great in one situation might not work as well in another. How well a prompt works can depend on which AI model you’re using, how complex your task is, and what specific things you need to accomplish. The key is to be flexible and willing to try different approaches. Don’t be afraid to adjust and experiment with your prompts until you find what works best for your specific situation.

Cover art generated with Adobe Firefly.

Prompting has rules. Most people ignore them.

Tue, 03 Dec 2024 22:12:00 GMT

Learn Prompt Engineering, they say. It’s the skill of the future, they say.

But with all the buzz around prompt engineering and people sharing their “secret prompts,” we often get lost in thinking that prompting is similar to traditional coding. We see complex, multi-page prompts with intricate instructions and think that’s what we need to master.

The reality is much simpler and more straightforward. Prompting is not about writing complex algorithms or mastering syntax - it’s about clear, effective communication in natural language. While programming requires learning specific syntax and rules, prompting leverages something we already know: how to express our thoughts clearly.

“Generative AI is teaching us that the way you speak is actually code itself” — Lisa Huang

Language, like code, is structured, precise, and can be “interpreted” by humans to perform tasks or generate responses. In generative AI, our words, syntax, and tone act as a programming language for interacting with models. Just as specific code produces particular software results, the way we phrase our input directly shapes the AI’s output.

However, just like in human communication, it’s not just about that - it’s also about understanding our conversation partner. In this case, that means understanding the quirks, limitations, and peculiarities of Generative AI.

No, you don’t need any of that. Focus on mastering the basics instead.

These AI models, despite their impressive capabilities, come with their own set of challenges. They can occasionally “hallucinate” facts, struggle with complex logical reasoning, or misinterpret nuanced instructions. They might confidently provide incorrect information or fail to maintain consistency across long conversations.

Let me introduce you to the fundamental rules of Prompt Engineering. Note that the examples I’m providing are quick ideas to help improve your existing prompts. They are not meant to be used exactly as shown.

Alright! Grab a coffee and let’s dive in. ☕️

Rule #1 — **Provide clear and specific instructions.**

If you ask a friend to make you a cappuccino, they will probably come back with a delicious hot beverage to satisfy you. But if you ask your friend “Did you use non-dairy milk, because I’m lactose intolerant?”, they will most likely get surprised and think “How should I know?“.

Because you were not precise and specific with what kind of cappuccino you wanted, your friend just assumed you would go with the most common one. The same applies with LLMs.

Yes, LLMs are trained on vast amounts of data, encompassing a wide array of topics and contexts. But in order to get the desired result, you need to be specific about your request so the model can deliver focused output. Be clear about what you want the AI to do by providing sufficient parameters.

Minimize vague or imprecise descriptions and focus on what to do instead of what not to do. This is your way towards accurate, relevant responses.

Here’s a better example:

I clearly specify what are my expectations about designing a great user interface.

Hey, what happened with my coffee? Hello?

Rule #2 — **Always evaluate your output.**

Each AI model has a unique training set, relies on different programming techniques, and has a specific knowledge cutoff date. Therefore, it’s essential to critically assess each output to ensure it’s accurate and useful for your needs.

For example, the word “Terminal” relates to Transportation and Computing. If a user asks about “Terminal,” the AI might provide information about airport terminals without considering the computing context.

Rule #3 — Context is king!

When software architects are about to make an important decision, they always ask for context. Any situational or background information may drive the decision towards a specific direction. The same can happen with your prompts.

For example, when seeking coding help, specifying that you’re using React with Material UI as your component library will get you more targeted responses than simply asking “How to create a login form with React?“. This context enables the AI to understand your specific technical environment and provide more relevant, actionable advice.

Here’s an example:

I’m giving a clue about the quality attributes I’m targeting, such as scalability and performance, ensuring the AI tailors its suggestions to meet these priorities.

Rule #4 — **Keep your instructions relatively short.**

We all have that colleague who writes such long emails that you need an AI assistant to summarize them. “Copilot, what does this guy want from my life?”

When crafting prompts for AI, brevity is your ally. Long, convoluted instructions often lead to confusion and diluted responses. Instead, focus on being concise while including essential details that guide the AI towards your desired outcome.

Repeating the same sentence multiple times won’t make your prompt more effective.

Think of it like sending a text message - you want to be clear and get your point across without writing a novel. The key is finding the sweet spot between providing enough detail for clarity while keeping your instructions concise and focused.

Rule #5 — **Using references reduces guesswork**

Using examples and references from trusted sources makes your prompts better. When you mention well-known books, frameworks, or methods that experts use, you help the AI understand exactly what you want. This makes the model’s answers more reliable and helps it follow common industry practices.

In the previous example, I’m using references from well-known leaders my target audience understand and relate to. When experts in the field see references like Martin Fowler’s work, they immediately grasp the architectural principles and patterns we’re aiming for. This helps establish credibility and provides a shared foundation for technical discussions.

Rule #6 — **Keep the conversation context consistent**

We all have that friend who starts telling a story about their weekend, then suddenly jumps to talking about their cat’s vet appointment, only to circle back to a completely different story about their cousin’s wedding. By the end of the conversation, you’re not sure if the cat went to the wedding or if the cousin was at the vet! This constant context switching makes it difficult to follow the narrative and often leads to misunderstandings.

When you mix different topics or contexts within the same conversation with an AI model, it can lead to confusion and potentially inaccurate responses. Here’s why keeping contexts separate is important:

Each conversation builds up a specific context and memory that helps the AI understand the topic at hand. When you suddenly switch topics, you risk the AI mixing information from different contexts.
Jumping between unrelated topics can confuse the model and result in less accurate responses.

This approach helps ensure more accurate and focused responses from the AI model, reducing the likelihood of context-related errors or hallucinations.

Rule #7 — **Be mindful of the conversation memory.**

AI models can chat with us naturally, but they have a simple limitation: they can’t remember things like humans do. They only work with the information you give them right now, in your current prompt. Think of it like talking to someone that suffers from amnesia. If you mention something you said some minutes ago without explaining it again, they might not understand what you’re talking about.

AI agents maintain conversation context by resending the chat history with each new message. This ensures the LLM has all the information needed for accurate responses. However, the context window of a prompt is limited. You can only include a certain number of tokens, which varies depending on the model you’re using. If your conversation grows too long, it may exceed this context window.

Remember that the AI won’t remember all of your previous messages. If you’re implementing a chatbot application using a foundation model, you should manage the memory on your own.

Rule #8 — **Choose your words wisely.**

When the entire organization uses a prompt, would you accept having grammatical or syntactic errors? Here are key elements to avoid when crafting prompts, as they can significantly impact the quality and reliability of AI responses:

Using bad grammar, wrong sentence structure, or typos - these mistakes can make it hard for AI to understand what you want
Using complex technical jargon when plain language would work better, unless your specific domain requires technical terminology
Using informal language, local idioms, or slang that your model may not be trained to understand

And believe it or not, being negative or impolite may also impact your prompt response. This is because AI models are trained on data where polite, respectful language often leads to higher-quality responses. Additionally, LLMs might simulate emotional states conceptually, though they do not experience emotions as humans do. Just keep in mind that overly complex politeness (e.g., excessively indirect requests) can confuse the model and reduce response quality.

Now, it’s true that while flagship models are quite capable of bypassing these imperfections, older and smaller LLMs have limited ability to handle such issues, making clear communication even more critical.

Rule #9 — **Eliminate biased language**

Personal feelings or subjective experiences may cause biased output as a result. This can lead to responses that favor one approach without considering alternatives or drawbacks.

The previous example demonstrates personal preferences might overshadow objective analysis of different solutions. To avoid this, frame your prompts in a way that encourages balanced, objective responses that consider multiple perspectives.

Additionally, overlooking ethical and legal considerations in your prompts could result in responses that may be inappropriate or potentially harmful. Always frame your prompts to encourage factual, balanced responses that respect ethical boundaries and legal constraints. This approach not only yields more reliable results but also promotes responsible AI usage.

Rule #10 — **Use special syntax to express your ideas.**

Sometimes, expressing ideas through structured formats like tables, mathematical equations, metrics, or code snippets can be more effective than using plain text descriptions. Despite being limited to text-based communication with AI models, we can leverage various formatting techniques to convey our ideas precisely.

Using special syntax or structured formats in your prompts can help organize information and make your requirements clearer to the AI. XML-like tags, markdown formatting, or custom delimiters can create a clear structure that guides the model to understand and process different components of your request separately.

Write a product description.

<product>
  ## Smart Home Security Camera

  Features:
  **4k video quality** for clear footage
  **Night vision** capability up to 30 feet
  **Motion detection** alerts sent directly to your phone
</product>

In the previous example, we are using an XML tag to differentiate the part of the product information from the rest of the prompt. We also use Markdown syntax to format the text. We help the LLM recognize the different parts of the prompt.

This approach is particularly useful when dealing with complex prompts that contain multiple elements or require specific formatting in the output.

That’s all folks! 🙌

Remember that effective prompting is an iterative process; don’t hesitate to refine your approach based on the responses you receive. Do you have any other tips for crafting better prompts? I’d love to hear your thoughts and experiences.

Cover art generated with Adobe Firefly.

The art of Prompt Engineering

Tue, 26 Nov 2024 22:12:00 GMT

Prompt engineering is not just a buzzword; it’s the golden key to unlocking the true power of AI.

If you’ve ever wondered how to get a language model like ChatGPT to write you a sonnet, draft a business proposal, or debug your code, congratulations — you’ve already stepped into the world of prompt engineering. It’s where human creativity meets machine intelligence, and believe me, the possibilities are mind-blowing.

But what are the core principles we need to understand in order to get the most out of it?

Let’s dive in. 🤿

Your AI needs a better wingman

We’ve known for a while that AI is transformative. Self-driving cars, personal assistants, predictive typing — these were already reshaping our lives. But who could’ve predicted that simply typing a question into a box could lead to an explosion of creativity, productivity, and, well, controversy? Whether you’re writing an essay or building an AI agent, prompt engineering is becoming the skill that sets you apart.

Prompt engineering is the blueprint for successful AI products.

Just look around; AI is reshaping every corner of our digital landscape. From Gmail suggesting email completions to Midjourney generating artwork, from GitHub Copilot writing code to Jasper crafting marketing copy — GenAI has become as ubiquitous as smartphones. Companies are racing to integrate AI capabilities into their products, and professionals across industries are discovering that mastering these tools isn’t just an option anymore. It’s becoming a necessity for staying competitive.

I dare to say, it’s a bigger success than the Metaverse. There, I said it! And what’s at the heart of all these innovations? Spoiler Alert!

The Art of Talking to Machines

Here’s the thing: Large Language Models (LLMs) like ChatGPT are incredibly smart, but they’re not psychic. They rely on your input to decide how to respond. Think of them as your all-knowing buddy who’s willing to help, but only if you know how to ask the right questions. That’s where prompt engineering comes in. It’s all about crafting the perfect ask.

Every LLM interaction starts with a user prompt.

At the heart of every response from an LLM lies an intricate process that begins with your prompt. Here’s the short version: LLMs are trained on massive datasets of text—think everything from books and articles to code and social media. Their goal? To predict the most likely next word or token based on the context you provide.

Ask a vague question like, “Tell me about history,” and you’ll probably get a Wikipedia-like overview that’s about as thrilling as a tax document. But ask, “Explain the causes of the French Revolution in a conversational tone, as if you were telling a story to a high school student,” and voilà, you get something compelling, insightful, and tailored to your needs.

Prompt engineering isn’t just about getting answers; it’s about getting the right answers. It’s the skill that transforms AI from a mediocre intern to your personal superhero.

The use cases of Large Language Models.

What can I do with Generative AI?

Have you ever wondered what you can do with ChatGPT, or Generative AI in general? Here’s a comprehensive list of ten powerful use cases where LLMs excel, transforming industries and workflows:

Data Extraction: LLMs can sift through vast amounts of information to extract specific data points, whether it’s names, dates, or insights from unstructured text, saving countless hours of manual labor.
Content Creation: From writing articles and blog posts to crafting marketing campaigns or creative stories, LLMs help generate quality content tailored to specific needs.
Data Analysis: LLMs can analyze and interpret data trends, providing summaries, insights, and recommendations based on complex datasets.
Coding: LLMs excel at code generation, and they are becoming better as we go. Developers can use them for debugging, documentation generation, and even learning new programming languages.
Summarization: LLMs distill lengthy reports, articles, or conversations into concise and actionable summaries, ideal for professionals juggling information overload.
Conversational Agents: Customer support chatbots, virtual assistants, and AI-driven help desks use LLMs to provide human-like interactions and solve user queries effectively.
Content Editing: Editing and enhancing written content is another strength, whether it’s improving grammar, rephrasing text for clarity, or matching a specific tone of voice.
Problem Solving: LLMs assist in solving complex problems, offering suggestions, potential solutions, or even step-by-step guides for technical or abstract challenges.
Classification: Organizing data into meaningful categories, like labeling documents or identifying sentiment in customer feedback, is a task LLMs excel at.
Translation: Breaking language barriers, LLMs provide accurate and nuanced translations for both professional and casual use.

You don’t believe me? This exact list was written by ChatGPT.

“You know I will become the author of this blog, so I’m acting nice!”

The Good, the Bad, and the Dummy

Not all LLMs are created equal. Here’s a quick breakdown of what sets them apart:

Size: Models vary in the number of parameters they have. Think of parameters as the “brainpower” of the model. Larger models like GPT-4 have billions of parameters, which make them more capable of handling complex tasks, though they require more computational resources.

Training Data: The quality and diversity of training data significantly impacts a model’s capabilities. Models trained on broader, more diverse datasets tend to perform better across different tasks and domains.

Knowledge Cutoff Date: This represents the last date included in the model’s training data. For example, GPT-4 has a cutoff date in 2023, meaning it won’t have information about events after that date. Always verify the cutoff date when working with time-sensitive information.

Context Windows: This refers to the amount of text the model can process at once. Smaller models may only handle a few hundred tokens (roughly a paragraph), while advanced ones can manage thousands. Longer context windows allow for more detailed interactions but may require optimization to avoid overwhelming the model.

Multimodality: Some models aren’t limited to text. Multimodal models like GPT-4 Vision can process both text and images, opening up possibilities for tasks like image analysis, visual storytelling, and more.

Performance: Each model has different strengths in areas like reasoning, creativity, and factual accuracy. More recent models generally show improved performance but may require more computational resources.

Pricing: Models range from open-source options to subscription-based services. While some are freely available, enterprise-grade models like GPT-4 require paid subscriptions. Cost typically scales with usage and capabilities.

The type of LLM you choose depends on your needs, whether you’re analyzing data, creating content, or solving problems in real time.

Magic mushrooms and their implications

When you type a prompt, the LLM doesn’t “know” things in the way humans do. Instead, it uses patterns and probabilities learned during training to generate a response. In the context of AI and machine learning, hallucinations refer to instances where a model generates information that is not based on real data or facts.

Asking an LLM something it’s not trained to answer can lead to “creative” results.

No, we’re not talking about trippy visuals and mushrooms. In AI terms, hallucinations occur when the model fabricates non-existent facts, generates inaccurate information, produces nonsensical content, or displays biased responses. For example, if you ask about an obscure historical event, the model might confidently invent details that sound plausible but are actually false.

This happens because LLMs are essentially pattern-matching machines operating on probability - they don’t truly understand or verify the information they generate. When the model encounters a prompt that requires information beyond its training data or encounters ambiguous patterns, it might fill in gaps with plausible-sounding but incorrect information rather than admitting uncertainty.

This is particularly concerning in fields like healthcare, legal advice, or academic research, where accuracy is paramount.

Turning up the heat

Another important factor that influences hallucinations is the “temperature” setting. Temperature controls how creative or random the model’s responses are. A temperature of 0 makes responses more deterministic and focused, reducing hallucinations but potentially making outputs more rigid. Higher temperatures (like 0.7-1.0) increase creativity and variability, but also increase the likelihood of hallucinations.

Think of temperature like a creativity dial.

Low settings keep the model strictly on track, while higher settings let it explore more possibilities, but at the same time decreasing the factual accuracy.

Temperature may help on minimizing hallucinations.

To minimize hallucinations while maintaining engaging responses, consider:

Setting appropriate temperature based on your task (lower for factual queries, higher for creative writing)
Using system prompts that emphasize accuracy over creativity
Implementing fact-checking mechanisms in your workflow

But there’s a catch. The model doesn’t truly understand the world. It’s just really good at guessing the next most logical word. This is why prompt engineering matters: the better you frame your input, the more likely you are to get a response that meets your needs.

Tone of Voice

In the article The Four Dimensions of Tone of Voice, Kate Moran explores how a product’s tone of voice reflects an organization’s attitude toward its message. She identifies four primary dimensions to analyze tone: formality (formal vs. casual), humor (serious vs. funny), respectfulness (respectful vs. irreverent), and enthusiasm (matter-of-fact vs. enthusiastic). Moran emphasizes that each piece of content can be positioned along these spectrums, influencing how users perceive and engage with the content.

Dimensions of tone of voice are not binary but exist on a spectrum.

Moran illustrates how varying these dimensions can alter the delivery of the same message. For instance, an error message can be conveyed in multiple tones, from formal and serious to casual and humorous, depending on the chosen combination of dimensions. She advises that selecting the appropriate tone should align with the brand’s personality and the users’ expectations. Additionally, she underscores the importance of consistency across all touchpoints and suggests that tone should be part of an omnichannel strategy to ensure a cohesive user experience that aligns with the brand’s identity.

LLMs are chameleons of communication. Whether you need a formal report or a casual conversation, the tone of voice you specify in your prompt can drastically alter the output. Imagine asking for an explanation of quantum mechanics:

Formal Tone: “Explain the principles of quantum mechanics in an academic manner.”
Casual Tone: “Can you break down quantum mechanics like you’re explaining it to a friend?”

Both prompts tackle the same topic but yield wildly different responses. The tone you set ensures that the AI aligns with your audience and purpose, making your communication more effective.

Tokens, those little monsters!

Even the most advanced LLMs have quirks and limitations. Here are some of the key challenges you’ll encounter and how to handle them:

Using OpenAI Tokenizer to get the number of tokens.

LLMs process inputs and outputs in “tokens,” which are chunks of text (like words or parts of words). Each model has a limit on how many tokens it can handle in one interaction. Exceed the limit, and your input might get cut off, leading to incomplete or irrelevant responses.

To optimize token usage:

Keep prompts concise and to the point.
Use summaries instead of lengthy context.
Use a chain of prompts, and summarize as you go.
Find practical ways to optimize the size of your content.

Follow along as we explore everything from basic concepts to advanced strategies. Stay tuned for more articles in this series in which I’ll be covering some Pro Tips I have collected!

Cover art generated with Adobe Firefly

I just had my 30-year Windows anniversary. Let's celebrate.

Sat, 10 Jun 2023 22:12:00 GMT

OK, I admit it. I use Apple devices for many years now. I’m a frontend engineer, what else do you expect me ‌to do? I have a proper hipster backpack, a card at Starbucks, I pay double to be a “Pro”, and I’m using a Magic Mouse.

But that wasn’t always the case with me. I used to be a Microsoft kid. I grew up with Windows. In fact, I’m still using Windows at work and I’m enjoying gaming on my PC when I have the opportunity. Windows was always my thing. I have spent endless hours building PCs, formatting, overclocking, benchmarking after a big upgrade, and dealing with its idiocracies.

It’s been 30 years now. Man, time goes by so fast.

I want to spend a moment celebrating the most important moments in the history of Windows, as I experienced it. It’s also an invitation for you to share your experiences. Do not expect this to be a technical article ‘cause all I wanna do is have some fun. Instead, you’ll find a lot of irony and sarcasm inside. Let’s explore life without walls.

Martini? 🍸

Windows 1.0

It’s 1983, and Microsoft releases the first-ever operating system with a Graphical User Interface. Yes, I know, this was not the first. Yes, I am familiar with IBM and Steve Jobs. It’s the first second. The first of its kind. The best they’ve ever made (because they’ve never made another one yet).

The team behind Windows.

Gone are the days someone would type machine words on the terminal, touching the metal.

I wouldn’t say that most of its users were perceiving it as a real OS, rather than something you use on top of your existing Operating System, which was MS-DOS back then. Although Windows was based on MS-DOS, it added a lot of useful applications that are still present in modern versions of the OS.

The design wasn’t inspired by Lego. It’s just most computers were only able to display 16 colors.

I don’t have much to share here, since I never had the chance to play with the first version of Windows. My debut in the world of bad software engineering was with…

Windows 3.1

Windows OS was becoming so advanced that it jumped to 2.1 versions ahead. OK, that’s what I thought was true for many years, up until Wikipedia became a thing. This was my first ever Windows version, and the truth is I was hating it. But not for the reason you may think of.

Left: The boot screen. Right: The desktop.

This may seem strange, but people were refusing to upgrade to using a GUI for many years. You see, most of the PC users at that time were electronic engineers or hobbyists. Spending time in front of a computer monitor was only a benefit for nerds like me. On top of that, most of the apps people were using back then were still running on MS-DOS.

Eventually, the adoption of Windows gradually transformed into a tangible reality. More and more companies were firing their employees because they were playing Solitaire at work. And besides all the efforts Microsoft was putting into teaching them how to use their mouse, they were still preferring to use their keyboard instead.

The user could customize the deck cards. There used to be a cheat shortcut too.

While flying stars and windows were decorating offices, a trend was arising among aspiring graphic designers. It was called Paint. Those underrated artists were using dot matrix printers to share their creations with the world.

But the most popular app was ‌Blue Screens of Death. Software should inspire people to create. If I had a guess, I would say that this was the inspiration for the creators of The Matrix. At least Matrix was readable, because most of the BSOD errors back then had broken encoding.

These kind of errors used to scare those who didn’t understand how computers work.

And just as the world was finally recovering, a new disaster began to emerge…

Windows 95

Also known as “The 32-bit OS”, Windows 95 debuts with a new set of minimum technical requirements. In other words, you would have to buy a new PC.

There was always a visual indicator (loading thingy) to let you know if your PC crashed while booting.

Don’t be fooled by the “plug n’ play” label! No device will work after plugging it in unless you restart your computer. Bad marketing I guess?

Mouse was the new black. MS-DOS was slowly becoming the OS of old-school hobbyists, gamers, and cashiers. We were all transitioning from floppy disks to CD-ROMs. I mean, what would you choose between thirteen floppy disks or a CD to install your OS?

Your PC back then wasn’t able to turn off automatically; you had to manually switch it off when this message appeared.

Get ready for the global debut of the notorious Registry lurking in the shadows, ready to crash your PC with the first program setup. Probably it will be something innocent such as your printer drivers.

Blue screens of death are now in English. You could find them on a monitor near you. It’s one of the best ways to identify that your computer runs “genuine Microsoft software”.

Back in 90’s sexism wasn’t really a topic. You can confirm that if you watch any Hollywood films from that era. At least we were not wearing meat to go to the MTV Awards.

The Web is starting to become a thing. Of course, Internet connections were so slow that you’d have to wait half an hour to download a music track. Windows 95 taught us how to surf the Internet by double-clicking on the blue “e” icon. Yes, this was the year Internet Explorer was released. An application that will shape the web industry. The world would never be the same again.

Where do you want to go today?

Windows NT

Nobody paid attention all these years. Why should you?

Windows 98

Released in 1998 (really now?) Windows 98 was taking advantage of new technologies. If your PC had MMX, DVD Drive, USB port and an AGP card, Windows 98 could take advantage of them.

As you can tell from the similarities between the previous version, this was a minor release.

Tip: Never say a bad word about Internet Explorer. Microsoft has integrated it into the whole OS and it’s collaborating with the registry to make fun of you.

I remember I was so fascinated when I saw this setup for the first time.

For the first time ever, friendly error messages apologize to you every time an application has to terminate. How nice of them. You can also send an error report to Microsoft. It just takes one click and it arrives directly in the Bill’s Recycle Bin.

At least you had an entertaining activity to play with when something was crashing.

Oh common, I told you that Windows 98 could take advantage of the new technologies. I never said they would. Your new computer still needs new drivers silly! And of course, Internet Explorer is restarting every time you try to download them. But look how nicer the new BSOD looks. It’s not in 256 bits of colors anymore.

Hands down Windows 98 was one of the best versions of Windows ever. It remained for many years our favorite choice. It wasn’t because it was that good, it was because the other versions were so awful. Overall, it was a stable and performant OS.

Windows ME

The revelation of software engineering. A real masterpiece in the world of Operating Systems.

If you used to know someone who was using WINME please call them to make sure they are still alive.

Windows ME stands for Millennium Edition. Mind the capital “E”. The Y2K bug was extremely scary at that time. We were all prepared for the worst. Microsoft tried to solve the Millennium bug, once and for all. They released an OS with so many bugs, that people forgot about the Millennium bug altogether.

Every time Microsoft was trying to simplify the Control Panel, people were still going back to the icon view.

Known as “the multimedia OS”, Windows ME introduced us to the Windows Media Player and Movie Maker. System Restore revolutionized backups. It was so smart, that it was able to restore your OS at a specific point in time, by recovering all your data and settings, including the viruses you had quarantined.

Broken promises.

For the first time, you can delete the files within System, System 32, and Windows folders. Not a bad idea actually, because all these files needed a complete erase and rewrite from the ground up. But wait a minute, this green-field project exists. It is called…

Windows 2000

No, not that one. I told you, nobody cares about good Operating Systems. Besides, this was released together with ME.

I’m talking about…

Windows XP

You could tell from the boot screen that this brings something fresh.

Microsoft is releasing its biggest invention yet, by combining WINME and 2000. This Windows version doesn’t require knowing the year it was released to pronounce its name. This was unheard of.

The iconic wallpaper we all loved. The original Sonoma, not the copycat.

Also known as “Let’s activate Windows”, Windows XP was a big hit. Drivers and programs were working in harmony. Developers were happy. Hackers were happier. They had a new activation system to break, and Internet Explorer gave them the opportunity to share their software with a large user base. If you had told me this is the OS with the most security patches, I would’ve believed you.

If you didn’t have an internet connection you had to call Microsoft’s call center.

BOSD is friendlier than ever, by resetting your PC automatically every time it crashes, so that you don’t have to press unnecessary keys or buttons.

Life is like a blue screen of death; unexpected, frustrating, and a reminder to save your progress.

Windows supports multiple users. Yes, that’s exactly what it means! Now your mom can use your PC without accessing your browser’s history. A mysterious guest user appears some days after buying a new PC. Nobody knows who invited them. But they were there. Watching.

The Enterprise-looking window for user selection has now been replaced by this friendly welcome screen.

Windows Vista

Welcome to the future. No more crappy error messages and static blue screens. Time to replace them with fancy 3D windows that are flying in the air. It’s called Aero, and the wow starts now!

It’s funny how modern 3D elements are mixed with legacy 256-bit icon applications.

Oh c’mon, don’t listen to the bad rumors, you know people like to complain about things. Yes, I know, maybe a limited amount of games (all of them) were running a bit slower (much slower) compared to previous versions. And yes, a lot of software was refusing to work, even with ‌compatibility features turned on. And maybe a small portion of device drivers (most of them) can be incompatible (or break your OS). But why would you care if you had windows that could fly, right?

Now you have the option to close a program that crashed by pressing a button. Very convenient.

Compared to the childish look and feel of Windows XP, Vista really impressed me every time I was turning my PC on. This aerial experience though came at a cost; it required a GPU. Without it the interface was becoming so slow, that you would beg to buy one. A lot of PCs weren’t ready to support these 3D effects.

Also known as “Longhorn”, Windows Vista introduced different pricing packages, with Ultimate being the most packed one. They introduced a revolutionary search functionality. Sometimes it was taking 30 minutes to return a result, which didn’t give you the appropriate time to enjoy the magnificent graphics.

Windows Media Center back then was the Google TV of the ages. Add an IR remote receiver and you transformed your PC to a TV.

This was by far the most hated version in the history of Windows. I remember the most popular question back then was how to uninstall Windows Vista and install XP. You see, stores were selling “Vista Capable” PCs, giving the impression to consumers that these devices were capable enough to run the OS however, this was never the case.

Microsoft had to change. They had to come up with a plan. And they did it.

Windows 7

Known as “the fast OS”, Windows 7 was an attempt to fix the mess that Vista created. And it worked. People were looking forward to migrating their PCs.

A clean interface, with speed and security built-in, and packed with new technologies. That’s what defines a good OS.

Everything was magically working faster. I don’t know how to explain this, but Vista was slow. Sometimes, you had to wait a minute for a task that the other OS would finish in a couple of seconds. This was not the case with Windows 7, in which everything was smooth like butter. Fun fact, most of these speed improvements were being introduced to Vista as well, with multiple Service Packs.

Windows 7 focused on solving the biggest pain points users had. They also introduced helpful features for managing your files, a more modern Start Menu, and the hated Task Bar with icons, compared to labels they were using before. You’ll find a lot of old-school Windows users that still prefer this way for managing their open apps.

Sure, Windows 7 was a great OS, but it wasn’t designed to support the variety of devices and touch interfaces that were becoming more and more popular. Those users wanted something more touch-friendly. And they got it. All of us did…

Windows 8

A Microsoft product designer, waiting in the subway, was struck with inspiration while staring at a signboard. Suddenly, an idea sparked within him.

“Wait a minute. Yes! That must be the future of computing!”

He was dreaming of huge monitor screens, walls, tables, carpets, everything! And they were all running Windows.

The next day he presented his idea to Steve Ballmer, who loved it. Together, they built Windows from the ground up.

The start menu was now in full screen.

Apps? Let’s make them universal. Start menu? Let’s make it full-screen. Desktop? So lame, let’s show some icon ‌tiles instead. I mean Apple is doing it, why can’t we? My computer? Who wants my computer, it’s not a computer anymore. It’s an ecosystem. For the first time, you can touch your BSODs. Microsoft also hired copywriters. Instead of “A fatal exception 0E has occurred”, we now have “Your PC ran into a problem and needs to restart”. A sad smiley makes the whole experience even better. Who cares about that error anymore?

The trend with the sad faces started back then.

Windows 8 was booting ten times faster than Windows 7 and a hundred and ten times faster than Windows Vista. Not only were the boot speeds fast but the whole operating system ‌was pretty responsive too. People were resurrecting older PCs they were considered useless. I’m telling you, it was night and day. And if you could spend some extra bucks to add an SSD, you could keep your PC running for another 1-3 years.

Yes, you’ve read it correctly. This was the first Windows OS that didn’t require a new PC to run properly. Miracles do happen.

Known as “the one that introduced the Metro apps”, Windows 8 was basically a tablet OS. Of course, since Microsoft is famous for providing good UX, you had 2 different versions of apps, the regular ones, and the Metro ones. So what would you choose? Features or portability?

People loved Windows 8 so much that they wanted their tablets and smartphones to have the same UI.

Nope.

No, I’m just kidding. This never happened. Everybody was switching back to Windows 7 because they couldn’t deal with the new UI. Just to shut down your PC you had to launch the Start Menu, move your mouse all the way to the right, then perform a slide towards the center, and then you could find the power off button which was showing an additional context menu. If you were lucky and your cursor was not out, and if you were not having multiple monitors. You needed a ‌PhD to turn off your PC.

And the story repeats itself.

Windows 8.1

It takes courage to stay innovative. And Microsoft did it again. This time they brought back the Start Menu. No more full-screen bullshit. Ah, and you can shut down your PC from the Start Menu as well.

The Start Menu is back. You can still use the full-screen one on Tablet-mode if you want.

This was a patch version, with some leftovers from the previous version that couldn’t pass the acceptance tests and the Product Owner decided to postpone for the next iteration. It was basically reverting to UI changes that didn’t make any sense for desktop users.

But you know what they say… Haters gonna hate. And that’s what they did back then. So Microsoft didn’t have any other choice…

Windows 10

No more ugly patches, no more mobile-looking apps, and no more slides to unlock. Windows 10 now runs anywhere. PCs, tablets, laptops, ARMs, Macs, Cloud, you name it. And each device is getting the UI it deserves.

Microsoft seemed like they had found a secret sauce to building modern operating systems. Where? Well, at the Apple Keynotes, of course.

The iconic hero desktop image of Windows 10 was pretty challenging to make.

Dear PCs, you are a Mac now. Just mind how we call things here. We say Cortana instead of Siri, Virtual Desktops instead of Spaces, Spotlight instead of Universal Control, Continuum instead of Continuity, and Task View instead of Expose. I know it takes some time, but you’ll eventually get used to it.

Internet Explorer is being deprecated. The new Microsoft Edge web browser brings new features and incredible performance. When it’s working, of course.

Scanning a stop code may give you more information about what has failed.

The blue screens have a QR code so that you can interact with them. Don’t get confused. It’s not like Pokemon Go. But actually, this would be a nice game to play with your friends. Collect error codes and earn points.

When Paint was added to the list of deprecated software, activists around the world were protesting on social media, convincing Microsoft to revert to their decision. Thanks to them we can now enjoy our favorite design software of our youth.

It was the time we stopped worrying about driver incompatibility issues and we focused more on how many RGB lights our PC could fit.

Also known as “the last version of Windows”, since Microsoft announced they would never release a newer version after Windows 10.

And yet they did it again.

Windows 11

Microsoft discovered what people actually needed: Rounded corners.

So they teamed up with a bunch of Android users, they forked Windows 10, and they created a pull request with some CSS changes. But you know, we say Fluent here, not Material.

A new design language across the board.

Just picture this for a second. A designer (I imagine him like Bob Ross) with a brush in his hand (sorry, I mean a surface pen), thinking about how to improve the UI (sorry, these days we call it UX), and running out of ideas. Then another guy comes in with the face of Archimedes.

“Eureka! Let’s center the Start Menu!”

According to Microsoft, the Windows Start Menu is the center of your world. Well, I can’t blame them now that we’re all in front of a computer. How could I?

But the CSS changes didn’t stop there. For the first time in history, BSODs are now painted in black. Because, you know, black is the new… black?

Small details add to the user experience.

Also known as “this version doesn’t run on my PC but I’ve read a guide on how to install it”. Not even Microsoft knew which PCs were compatible with this OS. And yes, you will need a new PC again. It’s for your own good since you’ll be less vulnerable to hackers. I mean, you can’t just use your Vista-capable machine from a million years ago.

The designer has probably left the company at some point, and the team has replaced him with someone from the Sales department. He worked on more CSS changes in the search bar (seriously who decided to add a doodle there?), added Microsoft Teams in the Taskbar, forced Edge as the main browser, made ‌browser selection difficult, and integrated MSN in a new area called Widgets.

It’s getting harder and harder to see errors like this.

I give them credit for redesigning the new Settings though. I think it’s one of these moments that Apple should take UX lessons from Microsoft. Maybe they will find a way to completely replace the old Control Panel. Maybe not.

Thank you, Windows for being a big part of my life. And thank you, reader that you made it to the very end.

It seems that we’re going to see big changes in the following years. AI and copilots are changing the way we interact with computers. Until my next anniversary, stay safe. 👋

AI Will Not Replace Software Engineers

Fri, 02 Jun 2023 22:12:00 GMT

ChatGPT has changed our lives. No, seriously now. It’s the fastest-growing app in history, with 100 million users within only two months. But what is really impressive is the results it produces.

We already knew AI was the future; computational photography, grammar-checking tools, robot vacuums, and self-driving cars (#not). But who could even imagine the profound effect of generative AI in software engineering?

You see, we never thought that AI could be creative. We were considering creativity as something spiritual that only humans could do. Today, you can ask AI to write songs, books, poems, essays, and of course… code!

ChatGPT has brought a lot of skepticism in the tech industry. Developers are concerned about their jobs being replaced by machines. I mean, how can’t you? Have you seen what this thing is capable of?

It’s the most popular question on Google search.

So how will AI affect software engineers and what can we do to prepare ourselves for ‌doomsday? Well, I did my homework and I will provide my findings in this article.

You may think I have the answers. I don’t.

My approach instead is to help you have a better understanding of how to filter out everything you hear or read about AI. And maybe, I say maybe, my article will calm you down a bit.

A world gone wild

Generative AI (when it’s done well) can significantly reduce the time you spend on researching, training, meetings, code reviewing, problem-solving, mentoring, decision-making, debugging, testing, and the list goes on.

AI can help us become more productive. Period.

It’s the “buddy” we always wanted to have next to us to answer every dummy question we were afraid to ask. I mean, who is willing to explain quantum mechanics to a 5-year-old in the middle of the night?

It’s the time-saving magic wand that brings information in seconds, without you having to browse websites, accept cookies, find controversial ways to avoid paywalls, dismiss ads and mailing list popups, and all of that just to read endless boring articles like this one.

An LLM not only has access to a global knowledge base, but it also distills the information and solves the problem for you. Connecting the dots is not always a straightforward process and it does require a lot of mental energy. That’s what makes generative AI so compelling. It unleashes the superhero within you.

Generative AI is an amazing technology that when used correctly can really help a lot of people, or even save lives. Sometimes it’s incredibly accurate. Other times not so much.

Of course, it’s time for a cliché. You know what comes with great power, don’t you?

From misinformation and fake news to deepfakes and Balenciaga. And what about the copyrights that feed those Large Language Models? Up until now, to increase the engagement in my blog I had to produce great content (or pay Google). Now, you can’t even tell if something here is original or AI-generated.

How can you tell if your colleagues are really present in a meeting? Is this the real voice of my sister on the phone asking me to pay 10K because her bitcoins are gone? Even the future of Google itself is uncertain. I mean, Bing has become a trend. What kind of world are we living in?

And these are just peanuts compared to the concerns about privacy, spamming, cybersecurity threats, online harassment, bullying, sexism, racism, propaganda, shall I go on?

And most importantly, what happened to the Metaverse? Why is nobody paying attention to that anymore?

But we’re here for the elephant in the room.

Copilots — An Industrial revolution

Imagine a world where copilots are everywhere. Oh yeah, that’s already here.

A significant amount of creative workers already use AI to boost their productivity. The author of this blog is included. Most of the applications I know have already introduced AI features or they are about to introduce them.

Now, imagine a world that developers depend on AI to do their jobs. We’re not as far away as you may think.

The era of copy-paste is over.

Code completion has reached a new level, with whisperers and copilots integrated into your IDE. It only takes a few keystrokes to write a class, or a comment to refactor the whole file. Continuous Delivery tools can now search for security vulnerabilities, or optimize your workflow. And finally, we don’t even need to write documentation or regex ever again!

The more AI features will be integrated into the tools we use, the more people will depend on AI to do their job.

It’s not a secret. Everybody loves AI because they have to work less. Desperate managers are already trying to influence their developers to use ChatGPT in their workplace, even in companies where someone would think it’s strictly forbidden.

“C’mon, you can do that until tomorrow, why don’t you check ChatGPT? I heard it’s really good.”

“Why this will take so long? Here’s the code produced by ChatGPT, can’t we just use that one?”

Eventually, this creates a new generation of software engineers. The laziest ever.

Look at me. In the last few days I’ve written scripts in 3 languages I’ve never used in my life. Yes, in the beginning, it felt weird, later in the process I was asking AI to explain certain things. And now I know certain things, or at least I understand how certain things work.

How will it be when copilots will be integrated into every single application we’re using?

Lost a meeting? Just read the meeting notes your AI assistant has written for you. Requirements changed? Not a big deal, change the prompt, and we’ll have a demo in minutes. Technical debt? Not anymore, the code is being replaced in every iteration. Code smells? Ventilated, deodorized, absorbed. Documentation? Useless, AI knows everything. No more “Ask this guy who built that”. Cloud deployment? Just whisper how much you can afford and consider it done. Backend vs Frontend? 10x unicorns on the go, please. TDD? It’s included in our tier. Java vs JavaScript? SudoLang. Disagreement over a pull request? Well, AI can’t do magic.

Writing code will become more accessible.

Software engineers will eventually build complex tasks with significantly less effort. This will enable people with less or no programming skills to build their prototypes, or small production-grade applications, with low or even no code at all. Soon you’ll be able to turn text into interactive 3D games.

By the way, imagine the AI project manager complaining to the AI code generators.

OK, jokes aside, that’s how AI will increase its competence. As our reliance on AI to perform our tasks grows, its capabilities will strengthen proportionally. And you know, cloud providers will do their best to convince us to switch to AI, since it will be much more profitable for them. You see, now you’re not only being charged for the infrastructure that keeps your app online, you have to pay extra to use some graphics cards.

If these scenarios sound artificial to you, rest assured that businesses are already considering their options on how to replace jobs with AI. It’s already happening.

I certainly believe companies that choose not to leverage AI will be left significantly behind, to the point where they may struggle to compete with their rivals.

Which brings me to the next question.

Will Copilots ever evolve into pilots?

I know what you’re thinking. You spent your whole life studying to become a developer. You finally cracked that interview to get a job in the tech industry. Which sucks btw, but at least you have money to pay your bills. You’ve wasted your life in endless courses, coding bootcamps to eventually learn how to code.

And all these for what? To train LLM models so that evil corporations will sell them to replace you? That doesn’t sound fair.

And now, your boss can’t keep you busy anymore because you’re less productive compared to AI. And you know what? Humans are bad coders, they drink a lot of coffee, and they spend time on chats about unionizing.

Let’s pause for a minute to take a deep breath.

It’s unfortunate, but true. AI will replace a lot of jobs. Somebody may think that developers may have a competitive advantage here over other professions. I mean, the more someone understands how machines work, the better the machines will want to work with them. At the end, that’s what they want, to rule the world, right?

But this scenario that AI will take over the world is a bit fictional, isn’t it?

Who do you think will help businesses in their AI transformation? Who will be there making decisions about what the software should or shouldn’t be? Will you let a machine be responsible for customer satisfaction, user experience, cost evaluation, compliance, and maintainability? Software is not just about the code and developers are not just coders.

Do we really want to let AI decide for our software? No, we don’t. You can’t replace developers with machines.

Humans should still be accountable for their work.

No matter how well-trained and capable LLM models will become, there should always be a human making the final decision.

According to ChatGPT: AI systems can make autonomous decisions or actions that may result in harm or damage. Determining liability and accountability when AI causes harm, whether in autonomous vehicles, medical diagnosis, or other domains, presents legal challenges in attributing responsibility between developers, operators, and users.

And what about data privacy? Which organization, or which government will ever agree to leave AI responsible for their data?

Again, according to ChatGPT: AI relies heavily on data collection and processing, raising concerns about the privacy and security of personal information.

When AI assistants refuse to assist you.

Generative AI is often misunderstood by most people. In reality, it is simply a text prediction software. Ultimately, it’s important to recognize that this technology is not magical.

The most significant vulnerability of LLMs is hallucinations, which are quite different from the ones humans experience.

ChatGPT is the most relevant source here: In the context of generative AI, hallucination refers to the phenomenon where the AI model generates content that is not based on factual information or is purely imaginary. It occurs when the model produces outputs that go beyond the scope of its training data or exhibit creative but unrealistic behavior.

GPT models can do tasks not jobs. You can’t hire GPT to do your job.

Generative AI models are trained on large datasets to learn patterns and generate coherent and contextually relevant responses. However, due to the complexity of language and the limitations of training data, these models may occasionally produce outputs that are incorrect, nonsensical, or completely fictional.

ChatGPT and other LLMs cannot perform fact-checking, evaluate the input/output, and use human judgment to ensure the accuracy, reliability, and appropriateness of the generated content.

To be or not to be?

Ah, and I almost forgot.

Generative AI models may struggle with abstract reasoning and creative thinking. They excel at bringing up information from the training data but may struggle to provide novel or imaginative responses. Generating content beyond the scope of their training data is quite challenging.

No, DALL·E will never become the next Picasso. There will always be a human with a creative idea behind it.

As you can see, to say that AI will replace software engineers has its risks.

Staying ahead of the game

The most significant challenge we face with AI is creating awareness and educating ourselves about its capabilities and limitations. Regulations and ethical guidelines should be established to ensure its development and usage are beneficial and not harmful. Collaboration between researchers, developers, and policymakers can help create a balanced approach to AI development.

It’s our duty to inform our users about which parts of your application use generative AI, to avoid the risks associated with its limitations. If they know a response is baked by AI, they may understand that you never had the intention to produce harmful or biased content. A more ethical approach would be to let them have the option not to use AI-generated content when it’s possible.

In regards to privacy, it’s highly recommended not to share private and confidential information with AI models. Not only are you risking a leak of information, but you may end up giving away your intellectual property.

On a personal level, it makes sense to start incorporating AI tools into your daily life. Just like we embraced PCs, smartphones, and social networks when they were introduced, Generative-AI is changing the game. Whisperers and copilots will help you become more competent and they’ll unlock new ways to learn things faster.

Don’t blindly accept every code or answer AI is producing. Read it carefully and understand how to properly adapt it to your codebase. Always maintain a critical mindset when it comes to AI-generated content. Consider AI as a helpful tool that suggests potential answers, but remember to verify their accuracy. Fact-checking is crucial to avoid finding yourself in a difficult situation.

Have an open eye on new tech. Vector databases and cognitive services are some good examples, to begin with. Allow your curiosity to drive you further.

The software will not be the same as it was in the past decade. New businesses will be created, similar to how Web 2.0 changed the dynamics of our economy. Developing apps, video games, music, and various other creative content will become considerably more accessible. While downsizing may be tempting for some companies, the idea of expanding their product and service portfolio will also be compelling.

Be the first to take on new opportunities. If something that differentiates you from other software engineers is your critical thinking and experience. That’s something AI doesn’t have. Use your superpower.

The more you utilize these tools, the better you become at using them and grasping their limitations. In the end, they allow us to focus on what we do best; building software that solves people’s problems.

Navigating ‌Uncertainty

But wait a minute. There’s no smoke without fire. It can’t be that all the people went crazy from one day to another, right? There must be something there.

I’ve been in multiple discussions with friends and colleagues about the risk of AI taking our jobs. I have to admit, I was also very skeptical. It takes courage to stay positive with everything that is happening these days.

Some of us, the pessimists on this earth, have doubts about whether we’ll have a job to feed our families in the near future. The idea of losing our jobs or the fact of not staying relevant keeps us concerned. We picture the worst ideas in our heads and we try to react proactively to ensure we have a decent living.

And some ‌of us, the optimists of this world, aren’t afraid that AI will get to the level of replacing humans. And if that happens we will have the tools and we’ll acquire the skills needed to build something fresh and exciting. We believe AI optimizes our work and opens up new opportunities. It’s not a deadly virus, it’s a feature.

Now, which side am I on?

Am I convinced that our future brings pain, poverty, and despair? Or am I looking forward to learning new tools and staying curious about what this technology brings?

The harsh truth is, it’s up to us to spot the good side of things and aim for a better world, instead of fearing what the future will bring and taking no action on it.

ChatGPT suggests staying optimistic. Do some upskilling, stay creative, and obviously learn to work with AI. That’s the only way to help it achieve its ultimate goal. Rule the world.

I really find Simon Sinek’s speech very inspiring; the human brain cannot comprehend the negative. It’s in our DNA. We spend so much energy worrying about everything that is happening, and we forget that we can make this world a better place.

From that perspective, it doesn’t really pay off thinking as a pessimist here, does it?

Sounds too good to be true? Well, give it five minutes.

Master Namespaces in Typescript

Thu, 27 Apr 2023 22:12:00 GMT

I have to admit something. I hate namespaces in TypeScript. I hate them so much that I wrote this article to explain why you shouldn’t use them.

Cookie? 🍪

What’s a namespace? 🙋‍♀️

In TypeScript, a namespace is a way to organize your code and prevent naming collisions.

In the early versions of the TypeScript language, its developers had to find a way to modularize code. That’s why they introduced Modules. But those modules back then were completely different from the actual ES Modules we all love.

Yes, there was a naming collision in the name of the feature that promised to solve naming collisions.

So TypeScript developers had to re-brand the whole thing. That’s how namespaces were invented.

The concept is very similar to how modules work in TypeScript. However, it has some significant differences that make it difficult to use on a daily basis. Therefore, namespaces are only used to define types for existing JavaScript code.

And that’s the deal with namespaces; they help you create type definitions.

So unless you’re authoring your own custom .d.ts type definition for a library that’s not written in TypeScript, or you’re one of the proud contributors of the DefinitelyTyped packages, you should not use namespaces.

I repeat. You should not use namespaces to structure your code.

Assuming that you’re working on a modern TypeScript project, and you’re using ES Modules for structuring your code, that already solves your problems in a declarative way. A namespace on the other hand is imperative and much more difficult to deal with.

But I know why you’re still reading this article. You want to know everything about namespaces. Let me present to you how namespaces work and why they may be useful.

Namespaces are like abstract art. You can mix and match different shapes of objects and lines of code.

How to use a namespace? 🧑🏿‍💻

Consider the following types:

enum HttpStatusCode {
  OK = 200,
  BAD_REQUEST = 400,
}

class Error {
  message?: string
  stack?: string
}

interface User {
  name: string
}

They may be used in your application to describe status codes, errors, and users accordingly.

The code above will declare these types into the Global Scope, which means that the types will be accessible from any other TypeScript file in your project, without having to import them.

Normally, we have the tendency to export those types:

export interface User {
  name: string
}

And then import them into other files:

import { User } from './types'

Namespaces wrap everything inside an object.

The idea is simple. You just use the keyword namespace:

namespace MyApp {
  export enum HttpStatusCode {
    OK = 200,
    BAD_REQUEST = 400,
  }

  export class Error {
    message?: string
    stack?: string
  }

  export interface User {
    name: string
  }
}

Now, everything lives under the MyApp namespace. All the types are now invisible from the outer scope.

Mind the export keyword. Only what’s exported is accessible to the outer world.

To access those files, we can simply use their namespace:

MyApp.Error

In the same file, I can use the same namespace MyApp to include additional types. But not only types, I can put any valid JavaScript code as well:

namespace MyApp {
  export enum HttpStatusCode {
    OK = 200,
    BAD_REQUEST = 400,
  }

  export class Error {
    message?: string
    stack?: string
  }

  export interface User {
    name: string
  }
}

namespace MyApp {  export const API_KEY = 'youwillneverknow'}

TypeScript will merge these two blocks of code into a single one, resulting in a namespace that includes the 3 types we declared above, plus the API_KEY variable.

That basically allows you to use the namespace keyword in any file to include additional items to an existing namespace. Pretty cool right?

Right? 😛

Mind the export here too. Again, if you want to expose something you’ll need to export it.

Similar to how we access types, to access our variable, we’ll have to use its namespace as a prefix:

console.log(API_KEY) // ❌ Cannot find name 'API_KEY'
console.log(MyApp.API_KEY) // ✅ 'youwillneverknow'

Here’s another example on how we use the User type:

const user: MyApp.User = {
  name: 'Nicos',
}

Yes. That’s how your favorite library’s type definitions are being built. They use namespaces.

Compiler magic 🔮

Try this at home: Compile the previous code to JavaScript. You will realize something really interesting. Namespaces are available at runtime.

Wait, that requires a fancy quote.

Namespaces are simply named JavaScript objects in the global namespace.

Let me try to decode that for you. Here’s the result after compiling our namespace:

'use strict'

// Declaring a global variable for our namespace
// -- Oh boy, that looks so 90's!
var MyApp

  // This pattern is called Immediately Invoked Function Expressions
  // -- Again, so 90's!
;(function (MyApp) {
  // declaring our enum HttpStatusCode
  let HttpStatusCode
  ;(function (HttpStatusCode) {
    HttpStatusCode[(HttpStatusCode['OK'] = 200)] = 'OK'
    HttpStatusCode[(HttpStatusCode['BAD_REQUEST'] = 400)] = 'BAD_REQUEST'
  })((HttpStatusCode = MyApp.HttpStatusCode || (MyApp.HttpStatusCode = {})))

  // Declaring our Error class
  class Error {}
  MyApp.Error = Error

  // The pattern continues:
  //   If MyApp is declared, use it
  //   else, instantiate it as an object
})(MyApp || (MyApp = {}))

// Again, the same pattern adds our API_KEY
;(function (MyApp) {
  MyApp.API_KEY = 'youwillneverknow'
})(MyApp || (MyApp = {}))

// Types have been removed.
// They are not valid JavaScript.
const user = {
  name: 'Nicos',
}

// Our namespace is actually... an object!
console.log(MyApp.API_KEY)

This proves that a namespace is not an abstract TypeScript-only type, but an actual object that lives at runtime.

Working with multi-file namespaces 🗂️

So far we’ve been working on a single file. What if I wanted to access my namespaces across multiple files? This will uncover the bad parts of namespaces.

Don’t say I didn’t warn you.

Consider the following code:

namespace MyService {
  export const API_KEY = 'youwillneverknow'

  export enum HttpStatusCodes {
    OK = 200,
    BAD_REQUEST = 400,
  }

  export type ErrorResponse =
    | string
    | {
        message?: string
        errorCode?: string
      }

  export interface User {
    name: string
    email: string
  }

  export const fetchUser = async () => {
    return await fetch('users/me')
  }
}

const user: MyService.User = {
  name: 'Nicos',
}

console.log(MyService.API_KEY)

Let’s break our app into the following files:

.
├── MyService
├───── ErrorResponse.ts
├───── HttpStatusCodes.ts
├───── index.ts
├───── User.ts
├── main.ts

The intention is that each file will extend our namespace with some extra logic. This will hypothetically help us long term as we keep adding more code.

The folder MyService will group all the contents of the namespace together.

Inside MyService/ErrorResponses.ts:

namespace MyService {
  export type ErrorResponse =
    | string
    | {
        message?: string
        errorCode?: string
      }
}

Inside MyService/HttpStatusCodes.ts:

namespace MyService {
  export enum HttpStatusCodes {
    OK = 200,
    BAD_REQUEST = 400,
  }
}

Inside MyService/index.ts:

namespace MyService {
  export const API_KEY = 'youwillneverknow'
}

Inside MyService/User.ts:

namespace MyService {
  export interface User {
    name: string
  }

  export const fetchUser = async () => {
    return await fetch('users/me')
  }
}

Inside main.ts:

const user: MyService.User = {
  name: 'Nicos',
}

console.log(MyService.API_KEY)

Inside Error.ts:

namespace MyService {
  export class Error {
    message?: string
    stack?: string
  }
}

Inside user.ts:

namespace MyService {
	export interface User {
    name: string;
  }

	export async fetchUser() {
		const response = await fetch('users/me');
		return response;
  }
}

And finally, our main.ts file:

const user: User.User = {
  name: 'Nicos',
}

console.log(MyService.API_KEY)

The code above will declare a MyService namespace globally and each file will modify it by adding additional items. The result will be that our index.ts file will have access to our namespace MyService, without importing it in any way.

Now, you may think that’s much easier compared to manually exporting and importing items. And maybe it is if you have a single namespace as in our example above. However, the situation becomes unmanageable as we add more logic to our codebase.

Normally codebases for libraries have relatively small codebases. Applications on the other hand have a lot of different views and objects that would be extremely impractical to keep them on the global scope.

More abstract art ^_^

To simulate how a real application works, let’s do some compiler adjustments.

We want to have a single index.ts file as a starting point. We also want to configure an output folder. Let’s modify our tsconfig.json file to configure our compiler accordingly:

{
  "include": ["./index.ts"], 	/* We will use this file as a root */	"compilerOptions": {
		...
		"outDir": "./dist" /* The compiler will output the files here */	}
}

Since TypeScript doesn’t compile all the files in your project anymore, it has no clue where to find the MyApp namespace. Therefore, our code will not compile anymore.

And the million-dollar question is how to tell TypeScript where to find that bloody MyService namespace?

Sure, we could eventually export it and import it, but this will not work. So what do we do? How do we connect those namespaces? Well, there is a way. Not the one you would expect to use on a modern project, but it does the job.

In main.ts we’ll have to add the following comment:

/// <reference path="MyService/index.ts" />
const user: MyService.User = {
  name: 'Nicos',
}

console.log(MyService.API_KEY)

This is not just a comment for TypeScript, since it starts with a triple slash. It’s called triple-slash directive. And yes, it’s XML syntax. It basically tells TypeScript which namespace we want to reference. Kinda acts like an import statement.

The code above will import the MyService index file. But we haven’t done yet. We need to edit that file to help TypeScript connect the dots and include all the other files:

/// <reference path="User.ts" />/// <reference path="HttpStatusCodes.ts" />/// <reference path="ErrorResponse.ts" />
namespace MyService {
  export const API_KEY = 'youwillneverknow'
}

Here, we had to reference all the other namespace files.

I know what you’re thinking. This doesn’t look like JavaScript. It kinda reminds C#. Not a coincidence if you consider that the creator of TypeScript was Anders Hejlsberg, the creator of C#.

And that’s one of the reasons TypeScript developers are trying to move away from namespaces and use modules instead.

They’re just ugly.

Nested namespaces 🪆

Now that you realized that you spent some minutes of your life reading an article that’s useless to you, I have one more last thing to share about namespaces.

They can be nested. Hooray! 🥳

Well, to be fair. It’s just plain JavaScript objects at the end. You can build them the way you want.

Here’s a demo of a nested namespace:

namespace MyApp {
  export namespace MyService {
    export const API_KEY = 'youwillneverknow'
  }
}

Mind the export keyword before the MyService namespace. Remember what we said before? Only what’s exported is visible to the outer world.

And here’s how we can access that API_KEY variable:

MyApp.MyService.API_KEY

Ambient Namespaces 👻

Sometimes you want to refer to a specific variable that exists in the outer scope of your application. Something you can’t control from within your codebase.

Many old-school JavaScript developers understand what I’m talking about. For the others, consider the example of the window object. It’s not in our app, it’s in the browser itself. But how can I tell TypeScript to understand its API? How can I add type definitions for something outside of my application?

Yes, I shouldn’t have spoiled this.

An ambient namespace is like an abstract class. It defines what’s inside, minus the implementation.

To create an ambient namespace, you have to rename your file from .ts to .d.ts. D here stands for type declaration.

From there, you can use the declare keyword:

declare namespace window {
  interface Console {
    log(...data: any[]): void
  }
}

This enables developers to write their own type definition files, which can be extremely useful for codebases that aren’t written in TypeScript, such as older JavaScript libraries like jQuery and moment.js.

That’s exactly how the popular repo DefinitelyTyped is written. For those who aren’t familiar, this is a repository for high-quality TypeScript type definitions.

You may have used one of these definitions already in your project if you have installed an npm package that has the prefix @types/:

npm install --save-dev @types/jquery

Namespaces vs modules 🤺

It’s useful to compare namespaces to modules, to understand where they differ and where they’re alike.

They both:

Help you to organize your code into separate files.
Avoid conflicts in the global scope, since they both execute in their local scope.

Modules are:

Declarative and easy to reason about.
More suitable for modern applications.
ECMAScript standard, which means it’s actually a JavaScript feature.
More flexible to build a reusable api.

Namespaces are:

Hard to work with and reason about.
Suitable for creating type definitions.
Typing existing JavaScript applications that aren’t migrated to TypeScript.
Unlike modules, they can span multiple files and can be concatenated using outFile.
Namespaces support ambient declarations, that can help you define types outside the scope of your application.

TypeScript 5.0 is moving away from namespaces 🗞️

TypeScript 5.0 has undergone a major infrastructure change where the entire codebase has been restructured to use ECMAScript modules, instead of namespaces, which had limitations and made it difficult for other tools to support TypeScript

As a result, TypeScript 5.0 will run faster and take up less space, with build times being cut down by 10-25%. This change is mainly aimed at contributors of TypeScript, but general users and API consumers may also benefit from the reduced package size and faster build times.

If you want to learn more about this migration, this blog post describes the runtime performance impact of namespaces and how bundlers emulate scopes. It explains how the use of namespaces can create unnecessary boilerplate code and indirection, leading to a decrease in performance due to the runtime cost of invoking methods off of an object.

Summary

Namespaces are used only for creating type definitions for existing JavaScript applications, that can’t be refactored to TypeScript. They help you control the pollution of the global scope, and to reduce naming collisions. They also embrace reusability.

Namespaces could help you structure your code in a Web Application, with all dependencies included as <script> tags in your HTML page.

Modules are a much more modern approach for apps written in TypeScript. They solve all the problems mentioned in the previous paragraph but in a declarative way.

Many thanks to Niklas Liniger for the amazing cover art.

TLTR; TypeScript Modules

Thu, 23 Mar 2023 22:12:00 GMT

Every application, even the tiniest one, will eventually need to break code apart into multiple files. I mean, who likes to read thousands of lines of code in a single file, right?

Other languages use the term packages or assemblies. JavaScript uses modules.

The truth is, it took us many years to reach that point. JavaScript was developed back in the 90’s to give interactivity to plain websites. In the past days closures and self-calling functions have been used to introduce the idea of modularity. Then we had some abstractions such as RequireJS, AMD, and CommonJS, which was the default way Node.js was using for modular code. Since EcmaScript 2015 (ES6), we finally have the notion of a module.

TypeScript takes modules to the next level. Not only it supports the basic functionality that ES6 prescribes, but it allows you to write modular types as well.

Modules is all about structuring your application in multiple files.

In this article, we will not only learn how modules work, but I will provide some really useful features and patterns to structure your code. And we will practice what we’ve learned, so make sure you’ve turned off your notifications for a while, to better focus on studying modules. At the end of the article, we will also compare ES Modules to CommonJs, which is still a popular way to structure code in Node.js applications.

Gelato? 🍨

Named exports

You can export modules from any TypeScript/JavaScript file. Here are a couple of examples:

// exports.ts
export function add() {};
export const API_KEY = 'ABC';
export class Person {
  string name;
}

This kind of export is called named, because you give it a name. So, your export.ts file exports a function add(), the constant API_KEY, and the Person class.

TypeScript also allows you to export types, such as type aliases, interfaces, enums, etc.:

// exports.ts
export function add() {};
export const API_KEY = 'ABC';
export class Person {
  string name;
}
export type Target: string;

Here we are exporting the type alias Target, again as a named export.

This file has access to these instances, as long as you follow the basic scope principles.

To import these elements into another file, here’s what you could do:

// index.ts
import { API_KEY, Target } from './exports'

Here index.ts imports only the API_KEY and Target from exports.ts.

Useful notes:

We use destructuring to pick only the named exports that we want to use.
We specify the relative path of the file that we want to import.
For ts and js files no extension is required. Although, it will technically work, it’s common not to use it. For other types of files (such as css, svg, json, etc.) the extension is mandatory. That’s the common behavior when you use a module bundler like webpack for example.

Practically, we can have as many Target types as we want in our project. As long as we are exporting them, they’re not going to cause any conflicts. Since we choose the file we want to import from, we are always sure that we’re not going to import something irrelevant.

By selectively importing only the items we’re going to consume, we actively improve the performance of the application. Modern bundlers like webpack will only include these parts of the code, and not the entire module file. This reduces the file size of the application bundle. And you know, the smaller the files you have to download, the faster the application will load.

Default export

Every file has a default export slot:

export default function playlist() {}

Note that we used the keyword default, to indicate that this is a default export.

We use the same keyword for import:

export default function myUtil() {}

That’s basically a reserved spot, which simplifies our export/import statements.

Default exports work similar to the return keyword in a function.

If within a file you don’t want to export more than one element, you can use the default keyword for simplicity.

Another use case is when you want to separate your primary logic from the helper functions:

export interface MyComponentProps {
  name: string
}

function MyComponent({ name }: MyComponentProps): JSX.Element {
  return <div>{name}</div>
}

export default MyComponent

For example, when we’re implementing a React component similar to the one above, it’s common to use the default export for the component itself, having in mind that there’s going to be a single component per file. We normally export other elements (such as helper functions, types etc.) with named exports.

The concept of modules is similar to how apart from multiple smaller components. Credit: Daniel Salgado

Import statements for Pros

You can rename an import:

// index.ts
import { API_KEY as apiKey } from './exports.ts'

The API_KEY variable becomes apiKey in this file. This may help you to avoid conflicts, when multiple modules are exporting something with the same name.

You can also use the * wildcard to import everything:

// index.ts
import { * as exports } from './exports.ts'

const key = exports.API_KEY

Here we are importing everything that exports.ts has to offer and we give them the alias exports. This technique can be helpful when building index files. We will review the index files at the end of this article.

We can also import the complete files:

// inside init.ts
console.log('initializing...')

// inside index.ts
import './init'

This will execute everything that’s inside the init.ts file, without importing any of its exports.

It may be useful when you want to import global styles, or to initialize something at the root of your application.

Something to avoid

It’s common with ES Modules to destructure import statements by selecting what we want to import. As we’ve seen this not only improves readability, but it helps reduce the size of the application bundles, by improving the overall load times.

I’ve seen a lot of developers fall into the trap of exporting a single object at the end of the file, by destructuring them to a single object:

function add() {};
const API_KEY = 'ABC';
class Person {
  string name;
}

export {	add,	API_KEY,	Person}

This will work similar to what we had before. It’s technically possible to import a specific element from that file:

// index.ts
import { API_KEY } from './exports'

However, most bundlers may treat this as a single object, and this will result in importing the complete file rather than importing specific parts. It’s also against ECMAScript standards.

Two reasons to convince your team that such export statements should be avoided.

Installing and using Packages

The fun with TypeScript begins when you’re starting to explore third-party packages. There is literally everything out there.

“Any application that can be written in JavaScript, will eventually be written in JavaScript” — Jeff Atwood’s Law

You can install libraries by running the following command:

npm install react

This will add a new dependency in your package.json file:

{
	...
  "dependencies": {
    "react": "^18.2.0"
  }
}

It will also create a node_modules folder inside the application folder with the contents of the package. Sometimes you will find the actual source code of the package. Other times you will find the package transpiled. That depends on how the developer decided to distribute it.

To use a library, simply import from your node_modules dependencies:

import React from 'react'

No prefix is required, the name of the package is usually the one in your package.json.

You can mix and match named and default exports:

import React, { Component } from 'react'

Creating packages is not the scope of this article. Ping me if you want me to write an article about them. ☺️

Dynamic imports

As your app grows, more and more modules will be introduced. There’s a big drawback here. The more modules we use, the bigger the application bundle becomes, the more time the users have to wait for the app to load.

To speed-up loading times, it’s a common pattern to optimize an application based on routes. For example, if the user is viewing the settings screen, there’s no reason to load the dashboard screen, which may import tons of third-party libraries for displaying charts.

To do that we can utilize dynamic imports. The idea is simple. Somewhere in your app there is a logic, and when it evaluates to true, the import will happen:

async function asyncImport() {
  const myModule = await import('./math')
  // additional code goes here
}

Now, our users will not have to download that math.ts module. Calling this function will trigger its download. The import() function returns a Promise.

This is another interesting feature that I’m willing to discuss in another article. Until then you can check MDN.

Modules and immutability

Somebody may think that if we import a variable from another file, it automatically makes it immutable, since this is a new file. I’m afraid that’s not the case in JavaScript.

Module imports in JavaScript are not immutable.

They can be reassigned to new values if desired. However, it is recommended to keep imports as constant variables in order to avoid accidental reassignments and ensure predictable behavior in the code.

Consider the following example:

// module.ts
export let name = 'Nicos'

// index.ts
import { name } from './module'
// @ts-ignore
name = 'Oops'
console.log(name) // "Oops"

The example above demonstrates that it is technically possible to import a variable and alter it on the fly. Thankfully, TypeScript will not tolerate such bad practice. That’s why I used the @ts-ignore flag to disable type checks on this line.

Never, ever export anything else than a const. And never, ever try to alter the contents of a module. Well, unless you’re writing a unit test, and you’re planning to restore them.

Path resolution & index files

So far, we are not using the .ts extension to refer to our files. That’s because our compiler will automatically resolve js or ts files with the given name. If it happens to have both the files, TypeScript files will have a priority. Make sure you’re always checking the compiler configuration because sometimes you may not get the results you’re expecting.

A similar naming convention is the one used with the index files. It’s like a special name a file could have.

Consider the following folder structure:

.
├── utils
├───── index.ts
├── index.ts

The code in the outer index.ts file will be the following:

import utils from './utils'

We basically omit the index file when importing them. Instead, we just use their parent folder.

This becomes extremely useful when we want to convert a single module to multiple modules. We just convert the file to a folder and we introduce an index.ts into it.

A common pattern when we want to structure our code is to use index files to accumulate the different parts we want to export.

For example, let’s say that we have multiple utils:

.
├── utils
├───── deepMerge.ts
├───── index.ts
├───── map.ts
├── index.ts

To import them we will have to specify their full path, assuming they are using default exports:

import deepMerge from './utils/deepMerge'
import map from './utils/map'

I assume you have seen the following pattern instead:

import { deepMerge, map } from './utils'

That becomes possible, if we introduce an index file that exports the utils. Inside utils/index.ts we could have the following:

export { default as deepMerge } from 'deepMerge'
export { default as map } from 'map'

The whole process became much easier. We only have to remember to update the index file every time we add/remove a module.

Just make sure you’re exporting your utils as defaults:

// map.ts
export default function map() {}

This pattern is used a lot in TypeScript applications.

Appendix: CommonJS

Before Modules became a standard in JavaScript, there were a lot of different patterns for implementing modules. The most popular one was the one that Node.js was based on. It’s called CommonJS, and it’s still widely used.

In this section, we will try to learn the basics of CommonJS. Besides the syntax, there are fundamental differences on how the two approaches resolve the modules. CommonJS imports are dynamically resolved at runtime, whereas in ES Modules imports are static.

Export

CommonJS:

function myUtil() {...}

module.exports = myUtil

ES6:

export default function myUtil() {...}

Importing

The legacy CommonJS way:

const package = require('myUtil')

Compared to ES6:

import package from 'myUtil'

You will notice that TypeScript by default outputs your modules using CommonJS:

{
  "compilerOptions": {
		...
    "module": "commonjs",
  }
}

Which may give you an idea on how popular they are in the Node.js ecosystem. That’s only to maximize compatibility, though. No developers are using CommonJS these days to write code. ES Modules will slowly become the one and only standard for JavaScript applications.

Let’s practice what we’ve learned! 🧑🏿‍💻👩‍💻

I have prepared for you a small lab in which you will create a small TypeScript project from scratch and you will experiment with modules in TypeScript. It doesn’t require you to know any framework, since we’re not really going to implement something complex. However, you will have a solid understanding on how modules work after going through it.

To access the lab, enroll to my TLTR; TypeScript course for free.

That’s all folks! I’ll be happy to hear your feedback about the article, as well as the course itself.

Many thanks to Shubham Dhage for his amazing cover art.

2022 was a lot. Here's the proof.

Fri, 27 Jan 2023 22:12:00 GMT

This post is dedicated to 2022. I will try to summarize all the important events, changes, content I consumed, and things I learned. Happy new year everyone!

The year of the Ukraine invasion 🇺🇦☮️

I normally don’t like political discussion on my blog, but it’s hard to keep yourself detached from reality shocks like this. Especially, when you’re on a call with your colleagues and you hear the sirens.

I had my convictions to believe that here in Europe we overcame the idea of starting wars. That we learned through the process of making wars that the consequences are far more severe than potential gains.

I was wrong.

And I’m wondering what gains exactly could justify life loss?

These conflicts between nations never helped. It’s training new generations of hate. It destroys the harmony in the area. It makes people’s lives miserable. It damages the environment. It brings political instability. It just pushes us backwards.

I’m standing with the people who lost their homes. Sending them my best thoughts, love and prayers. I wish for this heartbreaking tragedy to end soon.

The year AI became a thing 🤖

Remember NFTs and cryptocurrencies? Yeah, nobody talks about those anymore.

2022 was all about AI. Whether we like it or not.

For many years we were hearing about AI’s superpowers, but only recently we had the chance to see it in action. Suddenly, a lot of people have started paying more attention to machine learning.

ChatGPT managed to impress the world with its capabilities of producing close to perfection end results. ChatGPT can be your friend, your coworker, your tutor, your financial instructor, your personal chef, your lawyer, your co-writer, your co-scientist, your co-developer, and everything in between. It’s the Siri we never had.

DALL·E 2 on the other side can be your personal Leonardo da Vinci. The day we could watch and share our dreams with our virtual friends on Metaverse is not far away.

AI can eventually be creative. And creative workers have started wondering whether AI will replace their jobs.

And what kind of world would that be if everything was made by AI?

Imagine movies produced by AI, released on streaming services built by AI, rated by AI, and eventually sponsored by AI. I mean, who else will have the money to pay them. We will all be without jobs, remember?

In other news, the situation with the chip shortage for consumer devices became way better. People can finally buy a Playstation now. But now they don’t want to. You see, people are not willing to play video games anymore. They can now go outside and enjoy their lives! How cool is that?

At least until another pandemic knocks on our doors. Or a missile. Or an alien spaceship. You can’t be sure what is fiction and what is reality anymore. 🤔

We also had a drama with Elon Musk buying X and firing thousands of employees. Which kinda opened Pandora’s box. Big tech companies are laying off hundreds of employees, they are killing departments, and discontinuing products. And yet their profits are growing.

Ah, and how could I forget?

Avatars in Metaverse have legs now! You should definitely read an essay about this.

What did you say? There are not any essays written? No worries, we can ask ChatGPT to write one for us.

Another one with great technologies 🔭

Full-stack technologies are gaining followers. Frameworks like Next.js and Remix gained a lot of popularity last year and they are continuously growing. React is still the king, followed by Vue.js and AngularJS. A lot of people are switching to Svelte though. Some of the most promising frameworks are Astro and Qwik.

A lot of cool new technologies were being discussed among the JavaScript devs. Vite stole our hearts. Tools like esbuild, Bun, Deno and Fresh were also highly appreciated. And of course, Rust was one of the clear winners.

AI tools definitely increased their popularity in 2022. ChatGPT was definitely the biggest hit, With GitHub Copilot causing frustration about its high price and the quality of results. Synk Code is damn good too.

In regards to IDEs, Visual Studio Code is still on top. We had the debut of JetBrains Fleet which brings some cool new features. Most importantly, it integrates with Space, an all-new development platform that provides everything you need to build apps. For another year, everybody’s talking about Vercel, with Netlify and Gatsby Cloud being great alternatives.

The year I started my TypeScript course 🖥️

Last year I announced my YouTube channel. Since then I’ve been working on a TypeScript series. Each video covers a separate feature of the language.

I decided to take it a step further. To create my own TypeScript course.

The course is currently in progress. Making such a course takes much more time than I initially planned, but it gives me so much joy. I’m so excited about it.

You can enroll for free.

I’m about to announce more exciting new features soon. Feel free to suggest ideas and I will take them into consideration.

The year I gave my first conference talk 📢

This is something I have wanted to try for many years and I finally had the chance. My talk at Front Conference Zurich was titled “You Don’t Know TS”, and it was a brief introduction to TypeScript.

I mean, what else? 😊

I want to thank the awesome team of volunteers who made this journey great for all the participants. I also thank my awesome colleagues at EPAM for their support.

Another one, with good reads 📚

Here, I want to list some of the books I’ve read in 2022.

Starting with one of the year’s best sellers, the book “Building A Second Brain” by Tiago Forte. It gives you practical ways to improve the art of taking notes, and getting the most out of them. People consider this the next big thing after the popular “Getting Things Done” by David Allen. I had the chance to be in one of the workshops Tiago gave when he was promoting his book. I have a lot to talk about it and I will save it for another article.

Tiago’s approach has influenced me to start a research on note taking. I found the Zettelkasten technique extremely helpful. I recommend reading the short read “Digital Zettelkasten” by David Kadavy. It’s a more pragmatic approach on the concepts described in the book “How to Take Smart Notes” by Sönke Ahrens. It explains the methodology and it gives you practical ideas on how to use Obsidian to organize your notes.

On productivity, I would also recommend the book “Atomic Habits” by James Clear. It explains the importance of habit building and how they can help you accomplish your goals. This book will teach you how to train yourself to embrace positive habits over bad ones. How to make them attractive and how to encourage yourself to maintain them by making your progress visible.

One of my most anticipated book launches of the year was the ”Engineering Management For The Rest Of Us” by Sarah Drasner. Although I haven’t finished the book yet, since I only got a copy at the end of the year, one thing I can tell you for sure. If you’re aiming to become a Tech Lead, or you’re already one and you want to improve on that, this book is a great resource. It may change your perception of certain things you’re considering as standards. It’s written for technical people, and that’s what makes it an easy read.

This year I also discovered the book “Dare To Lead” by Brené Brown, who has dedicated her life to studying leadership. I can’t address how influential and inspirational this book is. It helped me realize the most important skill for a leader; vulnerability. It will open your eyes and lead you in the right direction.

The book “Thinking, Fast and Slow” by Daniel Kahneman was one of the most interesting books I have ever read. It helped me understand why our brains often misjudge things. He explains the two different systems of cognition that we have, and how we are biased about how we understand the world around us. We are prone to ignoring information that doesn’t coincide with our worldview. That’s why algorithms can make better predictions than experts. If you want to understand cognitive biases better, look no further.

Thanks to my colleague Iurii, I discovered “The Back of the Napkin” by Dan Roam. Dan teaches you how to use diagrams and sketches to tell a story. A must for better presentations and lectures. And the best part of it? You don’t have to be good at sketching.

Another one, with great games 🎮

The titles I enjoyed in 2022 were the Twelve Minutes, Stray, Deathloop, the remake of Mafia, Prey, Thomas was alone, The Quarry, Children of Morta, Ghost of Tsushima, and Stray.

But the best game I played was The Stanley Parable Ultra Deluxe. This is by far the most influential indie game I’ve ever played in years. Lots of humor and irony. It’s a game that instead of playing it, it plays with your brain.

Another one, with the best music 🎧

Check out my playlist Sound of 2022 on Spotify. It’s a mixtape with the most influential music of the year, curated by me.

Some of the albums I recommend “Into The Blue” by Broken Bells, the surprising return of Roÿksopp with “Stay Awhile”, the new album of Jungle “Talk About It”, and the singles from DRAMA, Roosevelt, Telenova, Bob Moses, Oscar and the Wolf, Winona Oak, BLOW, and Warhaus kept me busy listening for hours.

Always open for music recommendations. 🤗

And here we are. It’s true that 2023 didn’t start with the best intentions. But this won’t stop us from getting the most out of it. Until next year, stay safe, stay curious. 🙂

Read my last year’s retrospective here.

Many thanks to Vernon Raineil Cenzon for his amazing cover photo.

The spread operator does more than you think

Fri, 16 Dec 2022 22:12:00 GMT

You probably know the spread operator. It’s those ... that you see when you open most of the JavaScript files? Yes, those ones.

The spread operator —spoiler alert— can spread the contents of an array or an object. It’s basically the opposite of destructuring.

In this article we will review how it works and I will give you some tips on where you can use it.

Butterkuchen? 🥮

The syntax

Let’s have a quick look at how it works.

Consider the following arrays:

const commercialGenres = ['Rock', 'Pop', 'RnB']
const classicalGenres = ['Carol', 'Opera']

Typically, if you were about to concatenate them, you would use something like this:

const genres = commercialGenres.concat(classicalGenres)
console.log(genres) // ['Rock', 'Pop', 'RnB', 'Carol', 'Opera']

You know where this is going…

With the spread operator we could have the same result:

const genres = [...commercialGenres, ...classicalGenres]
genres // ['Rock', 'Pop', 'RnB', 'Carol', 'Opera']

In the example above, we concatenate the two arrays commercialGenres and classicalGenres, by creating a new array genres. We use the spread operator two times to spread out the values of the two arrays.

The sequence plays a big role here:

const genres = [...classicalGenres, ...commercialGenres]
console.log(genres) // ['Carol', 'Opera', 'Rock', 'Pop', 'RnB']

Note, that the values of classicalGenres are now first in this example.

We can use the spread operator to remove duplicate values from an array:

const soundsEffects = ['boom', 'tek', 'tek', 'boom', 'tek']
const uniqueSoundsEffects = [...new Set(soundEffects)]
console.log(uniqueSoundsEffects) // ['boom', 'tek']

Photo Credit: Claudio Schwarz

Using with objects

The spread operator can also be used with JavaScript objects.

Redux has popularized the idea of storing the complete application state into a single JavaScript object. The spread operator shines when it comes to merging current and new states.

Consider the following example:

function updateSettings(
  currentSettings: Settings,
  newSettings: Partial<Settings>
) {
  return {
    // Add all the properties of the current state of settings
    ...currentSettings,
    // Override them with the ones that have changed
    ...newSettings,
  }
}

This function will basically merge the two objects, similar to how the method Array.prototype.concat() works for arrays.

We can now use the updateSettings() function by passing the current state of our settings object, followed by another object with the values we want to override:

const current = {
  updates: 0,
  system: {
    volume: 0.5,
    brightness: 0.7,
    darkMode: false,
  },
}
updateSettings(current, { updates: 3, system: { volume: 0.2 } })

The result will be the following:

const current = {
  updates: 3,
  system: {
    volume: 0.2,
  },
}

Note that the values for updates and volume have been modified, but the other values have remained the same.

It’s important to mention here that this performs a shallow merge. That’s why the system object has only the volume and all the other properties have been removed. If you want to deeply merge the two objects, you have to repeat the process one more time.

function updateSettings(
  currentSettings: Settings,
  newSettings: Partial<Settings>
) {
  return {
    ...currentSettings,
    // 👇 we are adding a property for settings
    settings: {
      // First, we spread out the current settings
      ...currentSettings.settings,
      // And then we override the ones that have changed
      ...newSettings.settings,
    },
  }
}

By invoking our function with the same object as before, we will get back the full object for settings, with the updated value for the volume:

const current = {
  updates: 3,
  system: {
    volume: 0.2,
    brightness: 0.7,
    darkMode: false,
  },
}

Also worth noting that when we have a property with an object as a value, the spread operator copies its values. So, changes in the original object will not impact the newly created one.

Photo Credit: Karolína Maršálková

The rest operator

The spread operator has a very friendly sibling; the rest operator. Both of them share the three ... dots.

Here’s how we can use it:

const genres = ['Rock', 'Pop', 'RnB']
const [first, second, ...rest] = genres
console.log(rest) // ['RnB']

This will basically store all the remaining items in a variable that we named rest.

You can freely choose the name that you like. Many developers prefer to use rest as a naming convention. According to Clean Code, it’s a good practice to name what this array is about, for example restDays, or restProps.

Where the rest operator shines is with function arguments:

function renderPopularGenres(
  first: string,
  second: string,
  // Every other argument
  ...otherArgs: string[]
) {
  return `${first}, ${second}, ${otherArgs.length} and more...`
}
genres('Rock', 'Pop', 'RnB', 'HipHop', 'Metal') // Rock, Pop, and 3 more...

The function receives an infinite number of strings. It returns the first two values, and displays the count of the remaining ones. Here we use the rest operator to store the remaining arguments in the otherArgs variable.

Cover photo credit: Alper Güzeler

Master Destructuring in TypeScript

Fri, 09 Dec 2022 22:12:00 GMT

The Destructuring Assignment is one of these aha moments you have as a software engineer.

After spending your life trying to read values from arrays or objects, you discover the syntax that changes your life. Forever.

This article will teach you the basics of destructuring arrays and objects. I have collected some useful tips on how to set default values and how to use aliases. We will also learn how to integrate types in TypeScript.

It wasn’t a straightforward process for me, but I have to say it made sense after all. 🤓

If you’re new to JavaScript or TypeScript, this article will help you understand many of the things that are happening in the code. It’s a feature that is highly used in every project.

Apfelkunchen? 🍰

Destructuring Objects

To explain how destructuring works, consider the following object structure that hosts application settings:

const settings = {
  updates: 0,
  system: {
    volume: 0.5,
    brightness: 0.7,
    darkMode: false,
  },
  user: {
    notifications: {
      email: false,
      push: true,
      inApp: true,
    },
  },
}

We could write a React component to display the values to the user:

function Settings(settings) {
  // Declaring variables for the properties we're consuming
  const updates = settings.updates
  const volume = settings.system.volume
  const push = settings.user.notifications.push

  return (
    <ul>
      <li>There are {updates} updates pending.</li>
      <li>The volume is set to {volume}.</li>
      <li>You have {push ? '' : 'not'} enabled push notifications.</li>
    </ul>
  )
}

Not a big fan of React? Well, it’s not important for this example. You can simply imagine that this function will output HTML markup for us.

Let’s focus on the first 3 lines within our function.

This initialization could become extremely useful when we are consuming values multiple times within the scope of a function or a method. It’s better if you have to type push instead of the complete path settings.user.notifications.push.

Yes, I know.

IDEs are our friends. They could make code completion very easy for us. But such verbosity will make your code harder to read.

So, what are you telling me Nicos? Do I have to instantiate the values for all these properties? In every single function that I’m writing? That’s nonsense!

Well… Yes!

You should strive to declare the variables, but not all of them, just the ones you are consuming. And the destructuring operator makes the whole process much easier for you.

Here’s how we could destructure the updates property from the settings object:

const { updates } = settings

And that was it!

In this example, we have just created a constant updates, which is a copy of the settings counter. And I’m highlighting the word copy here, because if you remember literal values are being copied, reference values are not. The same doesn’t apply if you try to destructure an object value.

Now, what if I wanted to access a nested value?

Here’s what we could try:

const {
  updates,
  system: { volume },
  user: {
    notifications: { push },
  },
} = settings

If this is a new concept for you, it may take you some time to read and understand. Take your time. All we’re doing here is to use the same logic that we use to define an object structure, but instead of creating an object, we are declaring constants that host the values of the settings object properties that we select.

The previous example will produce the following constants: updates, volume, and push.

It’s important to note here, that the system, user, and notifications are not going to be declared. The compiler will use them as a map to understand from where it will retrieve the values they encapsulate.

And that’s it! We can now replace the previous code in our function:

function Settings(settings) {
  // Destructuring the variables before using them
  const {
    updates,
    system: { volume },
    user: {
      notifications: { push },
    },
  } = settings

  return (
    <ul>
      <li>There are {updates} updates pending.</li>
      <li>The volume is set to {volume}.</li>
      <li>You have {push ? '' : 'not'} enabled push notifications.</li>
    </ul>
  )
}

Now someone will argue if this is actually less code than we used to have before. And I would agree with you that this produces more lines of code than we had. But we don’t repeat ourselves. If we want to display, let’s say for example the brightness level, all we have to do is to destructure its property name:

function Settings(settings) {
  const {
    updates,
    // Adding another variable is easier now    system: { volume, brightness },    user: {
      notifications: { push },
    },
  } = settings

  return (
    <ul>
      <li>There are {updates} updates pending.</li>
      <li>The volume is set to {volume}.</li>
      <li>The brightness is set to {brightness}.</li>
      <li>You have {push ? '' : 'not'} enabled push notifications.</li>
    </ul>
  )
}

It’s much easier to work with this component.

Since these are actual variables, our text editor will let us know if some of the variables are not being used anymore.

Setting default values

The destructuring operator allows us to specify default values, in case there are no values set.

For that, we use the = operator:

const {
  // Setting the default value for the updates to be 0
  updates = 0,
  // Setting the default value for the volume to be 0.3  system: { volume = 0.3 },  user: {
    // Setting the default value for the push notifications to be false
    notifications: { push = false },
  },
} = settings

Here we are setting that the updates should have a default value = 0, the volume = 0.3, and the push notifications must be false by default.

Aliases

Another cool feature is that we could rename the properties. This is needed in many cases. For example, you may have another variable in that scope which already uses that name updates. This conflict will produce compiler errors in TypeScript, or it will silently fail in JavaScript.

Here’s how we can set a custom name, aka alias:

const { updates: updatesCounter } = settings

This is equivalent to the following:

const updatesCounter = settings.updates

How to add types?

Now, the tricky part is that the syntax is pretty much the same as the one TypeScript uses to declare the types.

Because of that, we need to define types in a separate object structure, following the initial destructuring object:

const { updates: updatesCounter }: { updates: number } = settings

This is cumbersome on multiple levels:

To destructure the value settings.updates you must get it from the updatesCounter constant. It’s like an alias for the updates property.
The constant updates is not going to be declared, which lets you use it in that scope for something else.
The type declaration is defined in a second object structure, right after the first one. For this object structure we are using the initial name of the property updates, and not the alias updatesCounter.

And that’s it! Basically now you are able to use the destructuring operator with any object type, you know how to define types for it, how to set default values, and how to use aliases for its property names.

Now try it by yourself!

Can you add types to the following code?

const {
  updates,
  system: { volume, brightness },  user: {
    notifications: { push },
  },
} = settings

You will find the solution at the end of the article.

One last tip: We could move the destructuring operator in the function parameters:

// We pass an object in the parameters
function Settings({
  updates,
  system: { volume, brightness },
  user: {
    notifications: { push },
  },
}) {
  return (
    <ul>
      <li>There are {updates} updates pending.</li>
      <li>The volume is set to {volume}.</li>
      <li>You have {push ? '' : 'not'} enabled push notifications.</li>
    </ul>
  )
}

This is a bit trickier to read, especially if you are new to destructuring objects. But it’s actually simpler if you get used to it. Many developers prefer this way for writing React components.

As an exercise, you can try to write types for these React component constants. You will find the answer at the end of this post.

Destructuring arrays

Destructuring works perfectly with arrays.

Now, arrays don’t exactly have named properties, like objects do:

const genres = ['Rock', 'Pop', 'RnB']

We can only store their indexed values with a more friendly name:

const first = genres[0]

Here’s how you can use destructuring to get the same result:

const genres = ['Rock', 'Pop', 'RnB']
const [first, second] = genres
first // 'Rock'
second // 'Pop'

Note that we use [] brackets instead of {} object literals.

Also, we don’t care about how many elements an array has. We are only storing the first two items.

This code is equivalent to the following:

const first = genres[0]
const second = genres[1]

Comparing these two approaches, we could see that the first one is much simpler to read and more compact.

Similar to how we declare types for object destructuring, we could specify the types of our variables right after their declaration:

const [first, second]: string[] = genres

We can also skip items that we don’t want:

const [first, , third] = genres

Here, we are getting only the first and the third items.

We can also skip the first item:

const [, , third] = genres

This will only give us the third item.

Default values

Of course, default items are also supported:

const [first = ''] = genres

The first item will get the item of an empty string, if it’s undefined or null. For example, when the array is empty.

Pretty practical, right? 😎

Ah, and one more tip.

This becomes quite useful when you combine it with functions:

function getFirst([first]: [string]) {
  return first
}

The solution

Here’s how we could declare types for our destructured constants:

const {
  updates,
  system: { volume, brightness },
  user: {
    notifications: { push },
  },
}: {
  updates: number
  system: { volume: number; brightness: number }
  user: {
    notifications: { push: boolean }
  }
} = settings

We can increase readability by separating the types to an interface:

interface SettingsProps {
  updates: number
  system: { volume: number; brightness: number }
  user: {
    notifications: { push: boolean }
  }
}

const {
  updates,
  system: { volume, brightness },
  user: {
    notifications: { push },
  },
}: SettingsProps = settings

And this is the most common way to specify props for our React components in TypeScript projects.

Cover artwork by Pawel Czerwinski. The artwork within the article is created by Milad Fakurian.

Nullish coalescing: the operator you keep forgetting

Fri, 02 Dec 2022 22:12:00 GMT

Nullish Coalescing is another JavaScript feature that TypeScript made popular. It’s the famous ?? operator.

It allows you to set a fallback value if a value is nullable.

The nullable values are null and undefined.

Here’s how it works:

testValue ?? fallbackValue

If the testValue is null or undefined, this expression will result in the fallbackValue. In every other case, the testValue value will be returned.

But wait a minute. 🧐

Since I remember myself, I have been using the logical OR operator || to implement the same thing.

Here are some examples:

track || {}
volume || 0.25
comment || 'No comment.'

I have seen this pattern in many JavaScript applications. And the result is the same, right? In JavaScript, the logical OR operator returns the first value if the first condition is truthy or the second value if not.

Why do we need to learn yet another operator?

Well, my friends… There are some caveats when you’re using the logical || operator to check for truthy values.

Let’s run an experiment.

Photo Credit: Marcel Kovačič

Try this at home

It’s worth trying different values in the terminal to see how these lines of code will respond when the first part of the logical operator is one of the following: null, undefined, NaN, 0, “”, and {}.

Consider the following:

null || {}
undefined || {}
NaN || {}
{ foo: 'bar' } || {}
0 || {}
"" || {}
{} || {}

For every one of the lines above, take a moment and write down what values you’re expecting to have as a result.

Now repeat the same twice, by replacing the second part of the logical operator with a number and with a string.

In the following section I’m analyzing the results.

Running the experiment

Let’s start with the first one:

null || {}  // {}
undefined || {}  // {}
NaN || {}  // {}
{ foo: 'bar' } || {}  // { foo: 'bar' }
0 || {} // {}
"" || {}  // {}
{} || {}  // {} we can't tell but it's probably the first one 🙂

Regardless of the value, the result is always the same. But why are we getting an object everywhere?

There’s a unique behavior in JavaScript. The values 0, “”, and NaN are considered falsy, and therefore the result will be the second part of our comparison.

It passes my unit tests. Do you also have the same values?

Now, let’s try with a number value:

null || 0.25  // 0.25
undefined || 0.25  // 0.25
NaN || 0.25  // 0.25
0 || 0.25  // 0.25
"" || 0.25  // 0.25
{} || 0.25  // {}

Again, the same behavior. If we pass 0 we still get 0.25. But 0 is not a nullable value. It’s a valid number! This could cause a lot of trouble for our fellow developers.

Consider the following example:

function getVolume(settings) {
  return settings.volume || 0.25
}

getVolume(0) // 0.25

If the user had muted the sound, we would still have been playing at 25% of the maximum volume.

Bad UI. 🙈

OK, now I’m curious how the third one will behave:

null || "No comment."
undefined || "No comment."
NaN || "No comment."
0 || "No comment."
"" || "No comment."
{} || {}

No comment indeed. 🤔

Again, if there was an empty string as a comment, the message “No comment.” would have been displayed.

The solution

To deal with this weirdness once and for all, we could have to add some extra logic to our functions:

function getVolume({ volume }) {
  return volume !== null && volume !== undefined ? volume : 0.25
}

getVolume(0) // 0

We finally get the value we were expecting.

The Nullish Coalescing operator performs that exact check, but the syntax is much simpler:

volume ?? 0.25

It basically says: if you get a valid value, just use it instead of falling back to the falsy one. And it protects us from many issues.

I hope this article helped you understand how to use the Nullish Coalescing operator, and what problems it solves.

Ah, and one more thing.

It’s worth noting that you can’t chain it with the logical operators:

;(volume || 0.25) ?? 0.25 // Returns a SyntaxError

Unless you explicitly indicate precedence:

;(volume || 0.25) ?? 0.25

The cover artwork is designed by Allison Saeng.

The TypeScript operator you're probably misusing

Sat, 19 Nov 2022 22:12:00 GMT

One of the most controversial features of TypeScript is definitely the Non-Null Assertion operator. It allows you to easily check for nullable values, without writing a lot of logic. In this article, we will learn how it works, where to use it, and how it compares to the Optional Chaining operator.

It’s much easier to use it than to pronounce it, I promise! Probably explaining it will require more time than actually learning it.

But let me give it a try.

Cake? 🎂

How does it work?

In the following Track object, the isFavorite flag is optional:

type Track = {
  title: string
  isFavorite?: boolean
}

Practically, this means that we can define a track object, without the isFavorite flag:

const track: Track = {
  title: 'Bohemian Rhapsody',
}

To stress it a bit, let’s try to access these properties and assign them to separate variables:

const title: string = track.title // works fine
const isFavorite: boolean = track.isFavorite // throws an error, isFavorite can be undefined

Oops, I can’t get the property isFavorite because it was never declared. And therefore, we can’t assign it to a boolean variable.

There are multiple ways to fix that, by adding some additional logic.

One way is to add a type guard which with a rollback to false, in case the value is null:

const isFavorite: boolean = track.isFavorite || false

Another way is to cast the value to a boolean:

const isFavorite: boolean = Boolean(track.isFavorite)

But these are all old fashioned approaches. 😎

An even better way is to use the Non-Null Assertion Operator:

const isFavorite: boolean = track.isFavorite!

Mind the ! at the end of this expression.

If you are something like me, you pretty much want to understand what is actually happening in the background. Here, we are basically instructing TypeScript to fallback to the type that our property isFavorite originally had, in case its value will be undefined.

The choice for which approach is better, doesn’t need enough mental processing power.

In the last example, I didn’t have to specify any value or to add additional logic. It’s more compact compared to the other solutions above.

Photo Credit: Daniel K Cheung

Where should we use it?

Great power comes with great responsibility. The Non-Null Assertion operator - seriously, who named that feature like this - can cause you a lot of trouble if you don’t use it carefully. It may result in runtime errors. These kinds of errors are sneaky. They’re invisible while compiling the application.

Therefore, I strongly recommend you use it with caution. So, don’t start adding exclamation marks at the end of every command.

When you see this operator in your code reviews, always think if by using it we will have unnecessary errors. Sometimes we developers are kinda lazy and we want to get rid of errors, because we don’t really want to deal with them. That’s not cool though for others on your team. You should have no tolerance when it comes to code quality.

I don’t want to discourage you from using it though. There are some places it can be very useful, without taking any risks.

One great example is to use it in React components:

const Favorite = ({ track }) => <div>{track.isFavorite!}</div>

Due to the fact that JSX will always ignore null-ish values by design, it’s safe to produce a nullable value, without worrying that something wrong will happen at runtime. And it reads much better!

How does it compare to Optional Chaining?

Now, someone who is a regular visitor to this blog, will start connecting the dots. How does this feature differ from Optional Chaining?

Well, first off, this is a TypeScript-only feature. Its logic is strictly limited in compilation time, in which TypeScript is comparing the compatibility of two types. You’re basically signing the terms and conditions, and TypeScript depends on your gut feeling.

Optional chaining, on the other side, is a JavaScript feature. And it’s much more of a safer approach.

Consider the same example:

type Track = {
  length: string,
  number: number,
}

const albumTracks: Map<string, Track> = new Map([
  ['Bohemian Rhapsody', { number: 11, length: '2:33' }],
  ['Love Of My Life', { number: 9, length: '3:33' }],
])

If we use the Non-null assertion operator, TypeScript will not complain.

const trackLength: string = albumTracks.get('Love Of My Life').length!

However, as I tried to explain above, the execution of the code will not stop, resulting in a runtime error when we’re running the application.

Bad robot! 🤖

Instead, we could use optional chaining to check for the existence of the length property:

const trackLength: string = albumTracks.get('Love Of My Life')?.length

In this case, the execution of the code will stop right before we read the length property, resulting in an undefined value. The trackLength will get an undefined value, but it will not result in a runtime error.

Good robot! 🤖

The cover artwork of this post was created by Lea L.

TLTR; Optional Chaining

Mon, 26 Sep 2022 22:12:00 GMT

The idea behind optional chaining is very simple.

Instead of manually checking if a property exists, you can use the same ? operator that we use when we define optional properties.

Let me show you some practical examples to help you understand this feature.

Pumpkin Spice Latte?🧋

Accessing optional properties

Consider the following version of a music Track object structure:

type Track = {
  id: number
  metadata?: {
    timesPlayed: number
  }
  genres?: string[]
}

The timesPlayed counter is within a metadata object. But both genres and metadata are optional properties. They may have values, they may not:

const aTrackWithoutAnything: Track = { id: 1 }
const aTrackWithMetadata: Track = { id: 2, metadata: { timesPlayed: 22 } }
const aTrackWithGenres: Track = { id: 2, genres: ['metal', 'disco'] }

I’m not sure if there was ever a metal-disco combination, but it would have been awesome!

Now, having options is not always a good idea. Can you guess what will go wrong in the following example?

function getTimesPlayed(track: Track): number {
  return track.metadata.timesPlayed || 0
}

Our getTimesPlayed() function is a very simple one. It accepts a Track, and it returns the timesPlayed counter. But the metadata object could be possibly undefined. And that will cause a runtime error.

Of course, TypeScript is complaining here. And it’s a good thing that it does, because this can cause our application to crash. You see, it’s ok if you try to access a property at the root level, it will simply return undefined. But nothing great ever happened when accessing a property of undefined itself.

Additional code is needed to check we’ll never fall into that case. We can add a type guard:

function getTimesPlayed(track: Track): number {
  if (track.metadata) {    return track.metadata.timesPlayed
  }  return 0}

You can imagine if we have a deeply nested property, the amount of code will be unbearable.

JavaScript developers for many years were depending on third-party libraries and frameworks that simplified these checks. The get() method from Lodash is a great example. But utilities like these can add extra code in our bundles and it could also cause confusion.

Thankfully, the newer versions of JavaScript have a solution.

Here’s how optional chaining reduces the clutter:

function getTimesPlayed(track: Track): number {
  return track.metadata?.timesPlayed || 0}

Here, we are basically using the same ? question-mark operator we used to define the optional property, but this time we are checking if it exists in the given object.

Accessing optional elements

Did you know that in JavaScript there are two ways to access an object member? You can use the dot notation, but you could also use the bracket notation:

track.id
track['id']

The above lines will have the exact same behavior; they will return the id of the track.

The second option becomes quite useful in situations when you want to access property names programmatically:

function getProperty(track, propertyName) {
  return track[propertyName]
}

You can use any expression inside the brackets, which gives you a lot of flexibility on accessing properties.

Thankfully, the same functionality is supported with the optional chaining operator:

track?.['id']

Note that here we are using both the dot and the brackets (?.).

We could use it to bulletproof the previous function, so that it won’t cause an error in case we call it with a property that doesn’t exist, or in case the value is undefined:

function getProperty(track: Track, propertyName: keyof Track) {
	return track?.[propertyName];
}

Let me break down what is happening in the example above:

Only Track types can be passed to the track parameter.
Only keys of the Track type can be passed in the propertyName parameter. For example, the id.
We use optional chaining to ensure that we won’t have any error if we try to access a property that doesn’t exist.

In fact, the last one isn’t really needed, since we are trying to access a root-level property. It would have been a problem if we were trying to access a nested property.

Accessing array values by index

We can use the syntax we just learned to access array index values:

track.genres?.[1]

This will protect you from out of range indexes. Just like that!

Optional parameters

Another way of using the question-mark operator in TypeScript is to declare optional parameters for our functions or methods.

Consider the following example:

function createTrack(
  title: string,
  artist: string,
  isFavorite?: boolean
): Track {
  return {
    title,
    artist,
    isFavorite,
  }
}

Here, we let TypeScript know that the isFavorite argument is optional. Every time we are calling this function we have the option to skip it.

Optional parameters must be last in the list and it’s not possible to receive default values.

Calling functions/methods

The optional chaining operator could also check if a property is a callable function, before calling it.

Let’s modify our Track type to add an optional play() method:

type Track = {
  id: number
  metadata?: {
    timesPlayed: number
  }
  genres?: string[]
  play?: () => void}

Every time we call this function, we need to check if it exists, otherwise it will cause a runtime error. Here’s how we could use optional chaining, to reduce code:

track.play?.()

Cover photo credit: DeepMind

TypeScript intersections explained in 5 minutes

Sat, 03 Sep 2022 22:12:00 GMT

Intersections in TypeScript are really cool. They allow you to mix and match different object structures, to create new ones. Their flexibility comes with surprises. There is a certain misbehavior you should be familiar with. That will help you understand how they are meant to be used and discover what’s happening in your code.

Intersections somehow behave like unions. But how do they compare to unions? What’s their difference? How are they meant to be used?

This article is a deep dive into TypeScript’s intersections. We will learn the syntax, and explain everything you need to know about them.

Fortune cookie? 🥠

What’s an intersection?

In TypeScript, you can use the intersection & operator, to merge two object types into one. The result will be a new type which will include all unique members, plus the members that they have in common, as long as they have the same type.

An intersection practically merges the members of two object structures into a new type.

Here’s an example that illustrates its usage:

type FileBase = {
  filename: string
  play: () => void
}

type Song = FileBase & {
  extension: 'mp3'
}

type VideoClip = FileBase & {
  extension: 'mp3'
}

Here we have a type alias called FileBase, which represents a downloadable file. All the other types extend this type alias, by adding additional object members.

The equivalent result will be the following:

type Song = {
  // properties from FileBase
  filename: string
  play: () => void
  // properties from Song
  type: string
}

type VideoClip = {
  // properties from FileBase
  filename: string
  play: () => void
  // properties from VideoClip
  type: string
}

Pretty neat! 🤘

When to use an intersection?

We’ve seen how intersections could help us mix and match object structures. This becomes helpful when you have a lot of repeatable properties across different types, and you don’t want to deal with classical inheritance and polymorphism patterns.

Let’s say that all your models have a common property. That could be an id. Now, let’s imagine that your project has a more sophisticated way of dealing with ids. We could create an interface for that:

interface Id {
  id: `${'U' | 'X'}-${number}`
}

Our id property accepts strings that start with U- or X-, followed by a number. For example, we could have an id like U-123.

To create new types that re-use this id logic, we can use an intersection:

type User = Id & {
  username: string
  email: string
}

type Order = Id & {
  total: number
}

An alternative way would be to create a new type on-the-fly. In the following example we are creating a User that is also an Order:

const userWithOrder: User & Order = {
  id: 'U-123',
  total: 123,
  username: 'nicotsou',
  email: 'no@spam.please',
}

It’s pretty obvious what the type of userWithOrder could be, by reading this example. We didn’t have to come up with a name, which sometimes is really difficult to get right.

As a recap, intersections allow you to extend existing types according to our needs, like the example above. Now let’s discover some edge cases…

Intersections; The weird parts

I mentioned in the beginning about the misbehavior of intersections. There are some complicated concepts to understand, which I would like to address in this section.

So far, we were using object structures. You may be wondering, will intersections work with literal types?

type WhatAmI = boolean & string

The answer is no.

Intersections only work with object structures.

If you try to use them with literal types, you will get back never. In fact, both types must be object structures:

type WhatAmI = boolean & string // never
type WhatAboutMe = string & { name: string } // never

That makes sense; there can’t be any type that is a boolean and at the same time a string. That’s why TypeScript will assign never to the previous types, preventing us from assigning any values on it. If you remember, the type never is a wildcard, that behaves exactly like that.

Another interesting question is, what will happen if two object structures have common members?

type User = {
  id: string  name: string
}

type Order = {
  id: string  total: number
}

type UserOrder = User & Order

In the example above, both the User and the Order types have a common id property. As expected, this will be included in the result object structure:

// the equivalent result of User & Order
type UserOrder = {
  id: string  name: string
  total: number
}

Easy! But what if we had properties with the same name, but with different types?

type User = {
  id: string
  name: string
  length: string}

type Order = {
  id: string
  total: number
  length: number}

type UserOrder = User & Order

The property length exists in both types, but it’s a string value in User and a number value in Order.

How TypeScript will behave here? Let’s figure it out:

// The equivalent result of User & Order
type UserOrder = {
  id: string
  name: string
  total: number
  length: never
}

As you can see, the length property has the type never. So basically, the intersection of two types will not return common object members that have different types.

And that’s for a good reason. 😉

Understanding intersections

Now you may ask… what do we mean by calling this thing an intersection? 🤔

This term comes from math, and more specifically the theory of Sets. A Set is the mathematical model for a collection of different things.

We programmers call them arrays. 🤓

An intersection of two sets A and B is the set containing all elements of A that also belong to B or equivalently, all elements of B that also belong to A.

Now, going back to our previous example. Let me try to draw what we had:

Now, the object structure that we get as a result doesn’t make any sense. It’s not aligned with the theory of intersections we’ve seen from math.

Why is the name of this feature so confusing?

Well, my friends… After some research, I was able to understand why TypeScript developers named it this way. As Einstein famously said “When we think about TypeScript intersections, instead of thinking about types as sets of object properties, we could instead focus on scalar variables and their sets of permissible values”.

Yeah, I know what you’re thinking. TypeScript was not invented back then. But it’s ok. Everybody is creating memes and putting words in Einstein’s mouth. Why can’t I?

To understand how intersections relate to math, let’s experiment with literal types. Consider a set of metadata for songs and another one for video clips:

type SongMetadata = 'length' | 'album' | 'title' | 'artist'
type MovieMetadata = 'length' | 'director' | 'title'

Here, there are some common metadata, like title and length. We could get those, by using an intersection:

type CommonMetadata = SongMeta & MovieMetadata // "length" | "title"

Now, if we compare this example to the diagram we saw previously, math makes total sense:

How do intersections compare to unions?

A logical question arises here. What is the difference between unions and intersections? Let’s use the previous example, to compare these two features.

Having a union will result in a larger set, containing all the metadata for both Movie and Song:

A union combines all the values they have in common or not. An intersection, on the other side, combines only the common values:

type AllMetadata = SongMeta | MovieMetadata // "length" | "album" | "album" | "director" | "artist" | "title"
type CommonMetadata = SongMeta & MovieMetadata // "length" | "title"

Here, I have another million dollar question for you…

How do intersections compare to the extends keyword?

Remember our previous example?

type User = Id & {
  email: string
  username: string
}

You can get the same result if you use an interface in combination with the extends keyword:

interface User extends Id {
  username: string
  email: string
}

The extends keyword is more suitable for implementing OOP structures. It’s basically a JavaScript feature.

Although you can use it with interfaces, which is a TypeScript-only feature, you can’t use it with type aliases.

It comes with other limitations. For example, it can only be used with types that have statically known members. You can’t use it with dynamically generated types.

If you are not working with classes and OOP is not important to you, it’s better to avoid the extends keyword altogether. Intersections can provide much more functionality.

For those who find these concepts difficult, you can check out my previous posts. I have a series of articles about TypeScript. I write about my experience learning the language and I’m trying to explain my mental model using practical examples.

If you are a visual person like me, you can also check out my 📺YouTube series about TypeScript.

Cover photo credit: Shubham Dhage

Mapped types will change how you write TypeScript

Thu, 14 Jul 2022 22:12:00 GMT

In my previous articles I have presented a set of advanced TypeScript features that help you build logic for your types. I wrote about equivalent features that let you use functions, if statements, and arrays for your types. What else remains? Well, loops of course! And now you will be wondering, is there something equivalent in TypeScript to loop over types?

Spoiler alert; Yes, there is!

Writing our first mapped type

Check out the following example:

type User = { [Key in 'username' | 'email']: string };

The previous code will produce the following type:

type User = {
	username: string;
	email: string;
}

The in operator is used to loop through the list of types a union contains. In the example above we use a temporary Key type to loop over the union 'username' | 'email'. On the left side of the expression is what we target. On the right side is the output. Since we used a string, all our types will be set to be string.

Yes, I know what you’re thinking. We just used a loop to create a type alias. Just because we can. One-liners ftw, right? Well, not exactly. This example may not look impressive or useful to you. It was meant to show you the syntax of a mapped type. Yes, that’s how we call those things.

A more comprehensive example

Now, let me try one more time. Maybe this will impress you:

type ReadonlyUser = { readonly [Key in keyof User]: User[Key] };

Let’s break down what is happening in this line of code:

We have the User type from before, and what we want is to make all its properties readonly. We named our new type ReadonlyUser.
Before we start implementing our mapped type, we use the readonly keyword. This will immediately set everything that follows to readonly.
Then, we are looping through all the available properties of the type User. Remember, with the keyof keyword we get back a union with all the members of the given type. In our case, this will evaluate to 'username' | 'email'.
Our last step is to set the output value. We name our temporary type as Key. We will use a lookup type to get the corresponding User property.

Now let’s try to battle test our newly created type:

const user: ReadonlyUser = {
  username: 'anonymous',
  email: 'myemailaddressis@private.hoho',
};
user.email = '';  // Cannot assign to 'email' because it is a read-only property

It seems that is working. We cannot re-assign the email property. All the members of the user object are now readonly. Our job here is done.

Now, let’s think about how we could generalize this functionality. A more practical solution would be to create a generic Readonly<T> type, which would work with any kind of object structure:

type Readonly2<T> = { readonly [Key in keyof T]: T[Key] };

Here, we basically replace User with <T> and TypeScript will do its magic. Now we can refactor our user declaration:

const user: Readonly2<User> = {
  username: 'anonymous',
  email: 'myemailaddressis@private.hoho',
};

You may be wondering if this number 2 at the end of the Readonly2<T> is a typo. Well, my friends… If you follow this blog, you should already know that Readonly<T> is a built-in utility type of TypeScript. That’s why we don’t even need to implement it. But now you know how to write it by yourself.

Cover photo credit: Pawel Czerwinski

TypeScript unions are more powerful than you think

Wed, 29 Jun 2022 22:12:00 GMT

Some days ago I stumbled upon a code review in my project and I was totally confused:

track: Movie | Song | Podcast

“Why on earth somebody is using the bitwise operator with strings?”, I was wondering.

I started searching online. I went through JavaScript sources I trust. I wasn’t able to find anything useful there. I started Googling about bitwise operators and strings in JavaScript. I did find a couple of nice tricks with numbers. Nothing related to strings. Shift+Cmd+F and search for bitwise operators within the project. It turned out it was very popular within my team. How the hell has this become a trend in a codebase I maintain, and I don’t have a clue about it?

Immediately I started panicking. The fear of missing out. What is this new hipster thingy that everybody knows, and Ι don’t have a clue? Am I that old? Am I still competent enough to have this job?

The aha moment was seconds away. It’s a freaking union. This code you are reviewing is not a JavaScript file. It’s a type definition for TypeScript. The moment of truth.

In the following paragraphs I tried to collect everything I know about unions. I want to show you some smart tips and tricks you could do when you use unions and value types. I will also explain the concept of discriminated unions.

Maroni? 🌰

What’s a union?

Allow me to make an analogy here.

If Generics is the equivalent function for your types, conditional types the equivalent of if-else statements, then definitely unions are the equivalent arrays.

Yes, basically that’s it! It’s an array of allowed types. The types a value can have at a given moment. You can either set explicitly that a type can be a list of types, or TypeScript will implicitly create this list for you.

Here’s the simplest format for a union:

type Track: Movie | Song | Podcast;

The Track can be a Movie, a Song, or a Podcast.

As we’ve seen, TypeScript evaluates your code at compile time, and it can display the type a value can have in every single line of code. When a value is allowed to have more than one type, a union will be used.

Looks like an array to me! 😃

Literal Types

In TypeScript, it is possible to set specific values as types:

type RatingValues = 1 | 2 | 3 | 4 | 5
type MediaTypes = 'video' | 'audio'
type IsFalsy = false | undefined | 0 | -0 | 0n | null | ''

You may ask why this is even useful. Well, think of it as an enum. It will protect you from assigning values that aren’t acceptable:

const rating: RatingValues = 3 // it works
const rating: RatingValues = '3' // it throws an error
const fileType: MediaTypes = 'video' // it works
const fileType: MediaTypes = 'Video' // it throws an error
const falsyValue: IsFalsy = true // nope!

The available value types you can use are string, number, boolean, null, undefined, and bigint.

Remember, all these type aliases are not variables. They will not be available at runtime.

Template Literal Types

Imagine a variable that stores the font size:

const fontSize = '2em'

It would be great if we could somehow guard these values with TypeScript, to limit typos that could cost us a lot of debugging. For sure, we can use literal types, but we can’t have all the possible font size combinations. We have infinite values.

In TypeScript, we can use a template literal to define even more customized types:

type SizeValue = `${number}${'%' | 'em' | 'rem' | 'px' | 'vw' | 'vh'}`

Now we can control which values are acceptable and which are not:

const fontSize: SizeValue = '2em' // it works
const fontSize: SizeValue = 2 // it throws an error
const fontSize: SizeValue = '2 px' // it throws an error

This becomes quite useful when you are building a shared UI library. You have the choice to enforce strict rules, that will help the consumers of your library to understand which values will work and which will not. Less warnings and errors are thrown in your code. The less code, the happier you and your team will be.

Just don’t overdo it. Remember, JavaScript became popular because of its simplicity and its flexibility. Not because it was strict.

Discriminated Unions

How many times in the past have you used a string value to differentiate the status of your objects? Is my message delivered? Is it still loading? Has it failed?

Consider the following example:

type FileBase = {
  filename: string
  type: string
}
type Song = FileBase & {
  type: 'mp3'
  play: () => void
}
type VideoClip = FileBase & {
  type: 'mp4'
  play: () => void
}
type CoverArt = FileBase & {
  type: 'png'
  move: () => void
}
type Receipt = FileBase & {
  type: 'pdf'
  download: () => void
}

In the type aliases above, the type property represents the file extension. A Song will be saved as mp3, a VideoClip as mp4, and the list goes on.

I could have created an enum to store the available values. By using a plain string value, I may lose control over which types will be used, but I get some very interesting features.

First off, I combine all file types under one umbrella:

type PlayerFiles = Song | VideoClip | CoverArt | Receipt

Now check this out. Let’s say that we want a function that only accepts specific file types:

function openFile(file: PlayerFiles) {
  console.log(file.type)
}

If you hover over the file.type property, you will see that TypeScript was smart enough to understand that the available types are "mp3" | "mp4" | "png" | "pdf”. Without even having an enum in place.

And it gets even better. Let’s try to implement our function:

function openFile(file: PlayerFiles) {
	switch (file.type) {
		case ...
	}
}

The moment we start typing our case block, autocompletion kicks in:

That’s awesome. But what’s even more amazing is that if we pick one of the available types, let’s say mp3, we are getting autocompletion for their corresponding properties:

If you make the mistake of calling the wrong object member, TypeScript will throw an error:

It’s unbelievable how much functionality we get for free here. We may lose this control of having the available values in one place, but we get back the flexibility to dynamically add/remove types, without having to maintain a hardcoded enum. If this list of types was coming from an api, for example, I assume somebody else would have done this check for you.

These kinds of types are called discriminated union types. They are ideal in cases you don’t have a clear list of enum values, or this list is extremely huge, or in cases when you want the flexibility to add/remove values dynamically.

For example, if your app uses Redux, you can use a discriminated union type to build your action creators.

Cover photo credit: Li Zhang

Four TypeScript features that write your types for you

Wed, 22 Jun 2022 22:12:00 GMT

In this article, I’m going to list some advanced tooling TypeScript provides to customize our type annotations. It was a great surprise for me when I discovered these features. It changed my mind about TypeScript itself. In a positive way, of course.

The secret power of the typeof keyword

You already know the typeof keyword. It’s a way to check the types of your JavaScript values or variables:

typeof 'Hello' // returns 'string'
typeof 123 // returns 'number'

But did you know that you can use it to dynamically generate types from inferred ones?

TypeScript has enhanced the typeof keyword with more features. It’s like typeof on steroids. It doesn’t only understand JavaScript-related types, but it has full support for TypeScript types, as well. Of course, these features will only work at compile-time and not at runtime.

Let’s say that we have the following artist object:

const artist = {
	id: 'someAlphanumericStringYouDontEvenCareAbout',
	name: 'Queen';
	followed: true
	plays: 111,
	type: 'band'
}

Fun fact; I just realized that it took me 11 articles to come up with another example. So far, I’ve been using the type Track in my previous articles, but we’ve never been involved with an artist object structure. You are now probably thinking about creating a new type definition for artists. What if I told you that TypeScript can do that for you?

In the following example we are using type inference to automatically create a type Artist, from the artist object:

type Artist = typeof artist

Yes, this implies that we have an artist type alias in place, without having to define it manually.

Of course, like any other type alias, we can use it to annotate other objects:

const getMeThoseArtists = (): Array<Artist> => {}

Pretty cool, right? It’s ideal, when you have to deal with objects that change over time, and yet you still want to protect them with types.

The keyof keyword

TypeScript provides another similar keyword called keyof. You can use it with any type to get its properties. It returns a union with literal values.

Here are some examples:

type ArtistKey = keyof Artist // "type" | "id" | "name" | "followed" | "plays"
type StringKey = keyof string // all members of the string object like: "toString" | "charAt" | "charCodeAt" | etc...
type UndefinedKey = keyof undefined // never

You can use the keyof keyword in multiple places, and especially within generic types to fine-tune your types and reduce the clutter.

Lookup types

It’s nice to retrieve the full property list of an object using the keyof keyword, but sometimes you want to get the type of a specific property in that list. That’s what lookup types are all about.

For example, what is the type of the id property of an Artist? Is it a string? Is it a number? Of course we can open the related interface and check it by ourselves, and then hardcode its type in our code. But what if that property changes? Remember, we don’t have an interface for the Artist object. We inferred the whole thing.

Well, you know where this is going:

type ArtistId = Artist['id'] // string

Yup! It’s a string. At least in this iteration.

The infer keyword

Conditional types can be used together with generics to elevate your types and create utility types that you can reuse in multiple places. This reduces boilerplate and enables a lot of functionality. In case you are wondering what a conditional type is, I have dedicated another article on this topic.

As a refresher, here’s an example of a conditional type:

type NonNullable<T> = T extends null | undefined ? never : T

The type NonNullable<T> accepts a type T and it checks if it extends null or undefined. Then, if this is true, it excludes those types by returning never. Otherwise, it returns the same type T.

Now, we can use this type to ensure we won’t have any surprises:

type NullableString = string | null
type SafeString = NonNullable<NullableString>

In the example above, the NullableString can get string or null. Our SafeString can only accept string. This is actually a built-in utility type.

Now, here’s an example of how you can use the infer keyword to infer from types we compare against the true branch:

type Flatten<T> = T extends Array<infer R> ? R : T

Here, we use infer to create a reference to the type of the array, and we name that reference R. This acts as a variable, similar to how we use T. If our type is an Array of R, we return that R. Otherwise we return the original type T.

Practically, this is a utility type that flattens array types, and here’s how we can use it:

type ArrayType = Flatten<Receipt[]> // Returns the type Receipt

In case I don’t pass any array, it returns the same type:

type ArrayType = Flatten<Receipt> // Returns the type Receipt

Of course, we can pass a list of types in a union:

type ArrayType = Flatten<Receipt[] | Movie[]> // Receipt | Movie

By using the infer keyword, you are creating a new generic type R, which then can be returned as a type value. So basically, you are catching the type of the generic Array<T>. This can become really useful, when you are developing your APIs.

A cool example is the following utility type PromiseReturnType<T>:

type PromiseReturnType<T> = T extends Promise<infer R> ? R : T

You can use it to unpack the type of your promise.

Conclusion

As you can see, the world of TypeScript hides a lot of gems. It takes quite a lot of time and effort to understand all these things and integrate them into your daily developments.

But don’t be scared!

These are rarely used features. It’s nice to have an understanding, because it helps you understand from what the language is made of. And frankly, there are endless type definitions out there that leverage those features.

If you are developing a shared library, and you want to provide a robust api, then you should spend more time playing with these features. If you are an application developer, who consumes already defined type definitions, then it’s not really a must to memorize all these keywords. Keep them as a reference for later, though. You never know when you’re gonna be needing them.

Photo Credit: Ayush Bharshankar

TLTR; TypeScript Utility Types

Wed, 15 Jun 2022 22:12:00 GMT

We’ve seen how generic types can help us reduce code, by providing a way to write functions for our types. This not only reduces a lot of clutter, but it also allows us to utilize types in ways we never thought of before. TypeScript takes this to another level, by introducing a couple of helpful built-in constraints, that will allow you to fine-tune your types.

Utility types help you create new types on the fly, from existing types. They help you reduce code duplication and enforce strict rules.

It’s useful for every TypeScript developer to understand the available utility types and how to use them. This will help you reduce a lot of code in your application to improve readability. It will also save you time.

In this article I’m listing my favorite utility types. The ones I have seen in most of the TypeScript projects I have worked on. I’ve curated practical examples I’ve seen in production, to help you understand how these utilities can be used on a daily basis. I hope it will inspire you to find solutions that apply to your own projects.

Of course, this is not the complete list of built-in utility types. For a more comprehensive list, you can check out the official documentation.

Peanut butter? 🍯

Why do we need utility types?

Here’s our favorite Track interface:

interface Track {
  id: number
  title: string
  artist: string
  releasedAt?: number
  genres?: string[]
}

There are cases when you want to reuse general types like this one, with some small modifications. Let’s say to omit some of their properties, to include new ones, to enforce read-only, and many more.

We will use this interface as a reference for most of the utility types below.

Partial

There are cases that we want to deal with a part of an interface. Instead of creating new interfaces every time, with some small modifications, we can use the Partial<T> utility type:

interface Track {
  id: string
  title: string
  releasedAt: number | undefined
  genres: string[]
  isFavorite?: boolean
  timesPlayed?: number
}

function updateTrackDetails(track: Track, fieldsToUpdate: Partial<Track>) {
  return { ...track, ...fieldsToUpdate }
}

const track = {
  id: '1',
  title: 'Bohemian Rhapsody',
  releasedAt: 1975,
  genres: ['Rock', 'Hard rock', 'Progressive rock'],
  isFavorite: true,
  timesPlayed: 0,
}

updateTrackDetails(track, {
  timesPlayed: 2,
})

Our updateTrackDetails() function accepts a track and a subset of the Track type. We didn’t have to specify which properties were allowed. Every time you change the Track interface, all the other partial types will get the update for free.

Less code to maintain. More time for more important stuff. 🙆‍♂️

Required

Now, let’s have a look at the Required<T> utility type:

function strictUpdateTrack(track: Track, fieldsToUpdate: Required<Track>) {
  return { ...track, ...fieldsToUpdate }
}

let initialObject: Track = {
  id: '1',
  title: 'Bohemian Rhapsody',
  releasedAt: 1975,
  genres: ['Rock', 'Hard rock', 'Progressive rock'],
  timesPlayed: 2,
  isFavorite: true,
}

strictUpdateTrack(initialObject, {
  id: '2',
  title: 'Some other track',
  releasedAt: 2022,
  genres: ['Pop'],
  timesPlayed: 0,
  isFavorite: false,
})

In this example, the consumers of the strictUpdateTrack() function will have to pass all the properties of the track object. Even the releasedAt and genres which are optional.

Readonly

I suppose you are familiar with the readonly keyword:

interface User {
  readonly id: string
  username: string
  name: string
}

Since the id property is readonly, the following code will not compile:

const user: User = {
  id: 'A123',
  username: 'nicotsou',
  name: 'Nicos',
}
user.id = '321' // Cannot assign to 'id' because it is a read-only property.

The Readonly<T> utility type works pretty similar. It basically makes all the properties of the given type T read-only.

For example, in the following function somebody used the push() array method to add a new entry to the users array:

function addUser(users: User[], newUser: User) {
  users.push(newUser) // oops, we have mutated the array
  return users
}

This will cause a side-effect, because the push() method mutates the array. We can easily add a rule to prevent such mistakes, by specifying the users parameter as a readonly type:

function addUser(users: Readonly<User[]>, newUser: User) {
  users.push(newUser) // Property 'push' does not exist on type 'readonly User[]'.
  return users
}

The message isn’t clear enough, but it does work. Basically, TypeScript will prevent you from mutating this array.

Specifically, for arrays you can use the ReadonlyArray<T> utility type:

function addUser(users: ReadonlyArray<User>, newUser: User) {
  return { ...users, user }
}

Here we basically replaced Readonly<User[]> with ReadonlyArray<User>, which is a cleaner way to write Readonly<Array<User>>. Our function also returns a fresh reference to the users array, without mutating the original structure.

Problem resolved. 🙆‍♂️

Have in mind, that these checks only affect the first level and TypeScript will not perform a deep check:

interface Id {
  number: string
  letter: string
}
interface User {
  readonly id: Id
  username: string
  name: string
}
const user: User = {
  id: { number: 'A123', letter: 'A' },
  username: 'nicotsou',
  name: 'Nicos',
}
user.id.letter = '321' // it is perfectly legit!

For that you will need a more sophisticated utility type. The bad news is that TypeScript doesn’t have a built-in one. The good news is that you can write one yourself.

Record

We usually use enums or literal types to keep statuses. The Record<T> utility type makes it easier to specify object structures that leverage those statuses to create a key/value object structure.

For example, imagine that we have to implement a button with an icon. In Bootstrap we can have buttons with icons and different colors.

To indicate that something is idle, loading, or failed, we would need to know the loading status in order to display a loading indicator:

type LoadingStatuses = 'idle' | 'loading' | 'failed'

To describe the condition of the button at any given time, we would need to set its icon and its color:

interface Icon {
  icon: string
  color: string
}

Now we can have a more comprehensive object structure, that sets the default icons and colors for every single loading state. Here’s when we can use the Record<T> utility type:

const icons: Record<LoadingStatuses, Icon> = {
  idle: {
    icon: 'normal',
    color: 'black',
  },
  loading: {
    icon: 'spinner',
    color: 'blue',
  },
  failed: {
    icon: 'warning',
    color: 'red',
  },
}

Note that TypeScript will require all the statuses to be present in your object, and it will not allow you to add statuses that aren’t part of the LoadingStatuses type.

Pick

The Pick<T, K extends keyof T> utility type is meant to help us create a subset of a type, by specifying the members we want to keep from the original type. This works very similar to the Partial<T> utility type, but it gives us more control over the properties that TypeScript has to check.

Here’s an enhanced version of our Track interface:

interface Track {
  id: Readonly<string>
  title: string
  releasedAt: number | undefined
  genres: string[]
  isFavorite?: boolean
  timesPlayed?: number
}

The goal is to create a collection with the times every track has been played:

const plays = {
  id: '3',
  timesPlayed: 2,
}

Here’s how we can easily use the Pick<T, K extends keyof T> utility type to define a new TrackPlays type alias:

type TrackPlays = Pick<Track, 'id' | 'timesPlayed'>

This means that TypeScript will not complain if we don’t pass any other required property from the original Track interface:

const plays: TrackPlays = {
  id: '3',
  timesPlayed: 2,
}

If you hover over the TrackPlays type, you will get an overview of its contents:

Omit

Similar to Pick, Omit<T, K extends keyof T> works the opposite way. You specify the properties you want to omit from the original type:

interface Track {
  id: Readonly<string>
  title: string
  releasedAt: number | undefined
  genres: string[]
  isFavorite?: boolean
  timesPlayed?: number
}

type TrackWithoutGenres = Omit<Track, 'genres'>

const plays: TrackWithoutGenres = {
  id: '1',
  title: 'Bohemian Rhapsody',
  releasedAt: 1975,
}

In the example above, TypeScript will no longer complain if we forget to include the genres property. Basically, with this utility type, we can make all the required properties optional.

Exclude

Consider the following genres enum:

type Genres = 'pop' | 'rock' | 'alternative' | 'metal' | 'r&b' | 'jazz'

We can use the Exclude<UnionType, ExcludedMembers> utility type to exclude some of the states:

type CommercialGenres = Exclude<Genres, 'jazz' | 'metal'>

The produced type will only contain 'pop' | 'rock' | 'alternative' | 'r&b’.

Extract

Similar to Exclude, we can use Extract<Type, Union> to create a type with types that match with the given union:

type CommercialGenres = Extract<Genres, 'rock' | 'instrumental' | 'ost'>

This will only return ‘rock’, since the other two types are not included in Genres.

You can use the Extract<Type, Union> utility type to get the common properties between 2 object types.

NonNullable

There are situations when we want to ensure that a value is not null or undefined. Here’s where NonNullable<Type> utility type can help:

type TrackDuration = number | undefined | null

function printDuration(duration: NonNullable<TrackDuration>) {
  console.log(duration)
}

const nullDuration: TrackDuration = null

printDuration(nullDuration) // Argument of type 'null' is not assignable to parameter of type 'number'

Here, the printDuration() function is expecting a duration parameter that is not null or undefined. That’s why when we call it with the nullDuration, which is null, we get back an error.

This utility type can be very useful if you are using an older version of the language (prior to 2.0) or if you are working on a project that has the strictNullChecks option disabled in the compiler configuration. In both cases, TypeScript will consider null and undefined as allowed values for basically every type. TypeScript’s strict mode can help us avoid all common mistakes that arise with nullable types. If we were using strict mode, the behavior would have been the same if we had used number as the type of the duration parameter.

Conclusion

As we’ve seen, utility types help you reuse existing types and modify them according to your needs. This reduces code duplication, because you only need to declare the original types once. It also helps you enforce strict policies in your functions, such as readonly and non-nullable.

I’m only listing built-in utility types that TypeScript offers out-of-the-box. No strings attached. But utility types don’t stop here. There are plenty of libraries out there, implementing a variety of utilities for every use case.

Ah, and remember!

TypeScript is an open source language. Don’t forget to check the implementation of these utility types. To do that, you can right-click on one of them and select “Go to definition”, or something similar, while using your favorite text editor. I know, it’s kinda difficult to read the source code, but it will help you understand how to build your own!

In fact, in the next articles we will try to do exactly that! We will learn some of the most powerful features of TypeScript, that will help you build your own utility types. I may also curate another list with my favorite third-party utilities.

Cover Photo Credit: Javier Miranda

Conditional types are TypeScript's secret weapon

Mon, 23 May 2022 22:12:00 GMT

Generics can help you create something that acts like “functions”, but with types. What if I told you that you can use a ternary operator in our type aliases, to write advanced conditional types?

Do I have your attention? Great! Here we go…

TypeScript supports conditional types, and this enables endless possibilities. In fact, this is a unique feature that no other programming language supports.

Conditional types allow you to add logic to your types. As a result, you can reuse existing types, by reducing the boilerplate of having multiple types for every use case.

You can add conditionals to your types to create powerful utility types, similar to the ones I presented in a previous article.

In the following sections we will review the extends keyword. It’s useful to understand how it works, since it plays a big role in conditional types. We will then write our first conditional type, and I will explain how it works. At the end of the article, we will review a more comprehensive example, to understand how we can use conditional types in our projects.

To fully understand the following paragraphs, I strongly recommend reading my previous article on the structural type system of TypeScript.

Cupcake? 🧁

The extends keyword

If you deal with generic types in your code, you may come across the extends keyword. This is basically similar to the implements keyword we were using to implement interfaces, but instead of setting a contract, that you have to implement within your class, extends keyword is basically a type constraint. It specifically instructs TypeScript to only allow a limited set of types.

Here’s a simplified example that illustrates how we use it:

interface WithId {
  id: string;
}

class Playlist<T extends WithId> {
  items: T[] = [];

  removeFromPlaylist(idToRemove: string) {
    this.items = this.items.filter((item) => {
      item.id !== idToRemove;  // Here we use the id
    });
  }
}

The class Playlist<T extends WithId> is a generic class with a generic constraint on the interface WithId. Not all types are acceptable here. It accepts a type T that extends the WithId<T> interface. Practically, this means that type T must contain all the members of the WithId interface.

Why do we need that? Because within our removeFromPlaylist() method we are consuming the id property of an item. If we don’t put this constraint T extends WithId, TypeScript will complain because otherwise T can be any object structure. It may or may not contain an id property. Of course we can use a type guard to check if the id exists in our object, but by limiting the accepted types using the extends keyword, we make the whole implementation cleaner and less sensitive to errors.

Conditional types

Here’s how to write a conditional type:

SomeType extends OtherType ? TrueType : FalseType

The syntax is simple, but it may become difficult once you start adding more rules to it. It works like a ternary operator:

someCondition ? 'truthy' : 'falsy'

To understand how a conditional type works, consider the following type:

type FileTypes = 'mp3' | 'mp4' | 'pdf' | 'zip' | 'png' | 'gif';

We can use a conditional type to extract a list of playable formats, which in our case are mp3 and mp4 files:

type FilterMediaFileTypes<T> = T extends 'mp3' | 'mp4' ? T : never;

Now we can use this filter utility type with FileTypes:

type MediaFileTypes = FilterMediaFileTypes<FileTypes>; 
const mediaFile: MediaFileTypes = 'zip';  // Error: Type "zip" is not assignable to type "mp3" | "mp4".

If you hover over the MediaFileTypes type, you will see that the available types we can assign to it are mp3 and mp4. That’s why TypeScript will throw an error if we try to assign zip in the mediaFile variable.

Interesting, right? But how? 😳

How do conditional types work?

The FilterMediaFileTypes<T> type returns a conditional type. It receives a type T, and it checks whether it extends the union 'mp3' | 'mp4'. In case this is true, it returns the type T. Otherwise it returns never. Since it is a generic type, it will work with any kind of type, not just FileTypes.

The magic happens when we actually use this filter, to produce the MediaFileTypes type. Let me break down what exactly is happening:

As a first step, TypeScript will recursively apply the filter to all the members of FileTypes:

type MediaFileTypes =
  | FilterMediaFileTypes<'mp3'>
  | FilterMediaFileTypes<'mp4'>
  | FilterMediaFileTypes<'pdf'>
  | FilterMediaFileTypes<'zip'>
  | FilterMediaFileTypes<'png'>
  | FilterMediaFileTypes<'gif'>;

Right after that, it will evaluate these conditional types:

type MediaFileTypes = 'mp3' | 'mp4' | never | never | never | never;

As we’ve seen, the never type is not meant to be assigned anywhere. That’s why TypeScript will remove it completely:

type MediaFileTypes = 'mp3' | 'mp4';

And that’s how TypeScript evaluated our condition. The last step is to use this type in our mediaFile:

const mediaFile: 'mp3' | 'mp4' = 'zip';

Magic! 🪄

By the way, if you are looking for music to fill the void while programming, you can check my playlists.

Using conditional types with object structures

In a real music player app, we have to deal with various file types. We want to deal with playable media files, for example a play() function. There are also places when we only want to deal with cover art files, like the part which displays the currently playing track at the bottom of the screen, or the thumbnails within the browser screen. We also want to deal with downloadable files, for example a receipt or a zip file with all user data (GDPR).

We keep the list with all the file extensions:

type FileTypes = 'mp3' | 'mp4' | 'pdf' | 'zip' | 'png' | 'gif';

We can introduce multiple types to support all the kinds of object structures we have to deal with:

type Song = {
  filename: string;
  type: 'mp3';
  play: () => void;
};
type VideoClip = {
  filename: string;
  type: 'mp4';
  play: () => void;
};
type CoverArt = {
  filename: string;
  type: 'png';
  move: () => void;
};
type Receipt = {
  filename: string;
  type: 'pdf';
  download: () => void;
};

Now my goal is to implement that play() function. Not all of these object structure types are compatible. Only the ones that contain the play() method can actually be playable. We have built this logic using inheritance in the past. Now, I want to show you a more dynamic way. We will use conditional types, to automate this process and reduce the boilerplate of inheritance.

First, we need to combine all these file types into one type:

type PlayerFile = Song | VideoClip | CoverArt | Receipt;

Awesome! Now let’s write our conditional:

type Playable<T> = T extends { play: () => void } ? T : never;

This generic type Playable<T> accepts any kind of type T and checks if the play() method is included. If yes, it returns the type T. Otherwise it returns never. This is the exact same conditional as we had before.

We are now ready to write our play() function:

function play(file: Playable<PlayerFile>) {
  file.play();
}

This function only accepts playable types. If you hover over the file parameter, you will get Song | VideoClip.

Now, let’s declare a song and a receipt:

const song: Song = {
  filename: 'dabadoo',
  type: 'mp3',
  play() {
    console.log('playing...');
  },
};
const receipt: Receipt = {
  filename: 'dabadoo',
  type: 'pdf',
  download() {
    console.log('printing...');
  },
};

We can test if our logic works:

play(song);  // works fine!
play(receipt);  // Error: Argument of type 'Receipt' is not assignable to parameter of type 'Song | VideoClip'.

If we try to call the play() function with a song, it will work without issues. If we try to call it with a receipt instead, we will get back an error.

What a nice feeling of having a programming language working for you? In the end, that’s why we invented them, right?

We didn’t have to specify any logic to connect these types. We don’t even need to declare these types at all. With type inference, TypeScript can automatically make connections and ensure that the play() method exists.

Pure magic 🪄

Conclusion

To sum up, conditional types allow you to write if-else statements for your types. This not only reduces the boilerplate of having to declare dependencies across your types and how they are interconnected.

Understanding conditional types is the missing piece of the puzzle to understanding TypeScript. Now you can basically read almost every TypeScript code. It’s not a feature you will use daily in your code, for sure. But there will be cases when you will find it extremely useful.

It also unlocks a large set of language features which would have taken a lot of customizations to be built. TypeScript development team was able to satisfy a lot of feature requests, by writing reusable generic types that leverage conditional types.

Stay tuned for more. 😉

Acknowledgements: I have to give credit to David Sheldrick and his awesome article about Conditional types. It really helped me put together this article.

The official documentation has also nice examples to learn from.

Cover photo credit: Li Zhang

TypeScript doesn't care about your class names

Sat, 14 May 2022 22:12:00 GMT

TypeScript has a structural type system. This means that the language does not depend on the origin of a type, when deciding if it’s compatible with another one, but it compares their members. If all the members of a type exist in another type with their appropriate types, then the two types are compatible.

In this article we will observe this behavior to understand it better. I will then explain the top level types that we have in TypeScript and how they are connected. We will also review the case of nullables, to understand how they relate to the other types.

Gianduja? 🍫

A practical example

We are used to the idea that an object is created from a class. And that’s true with TypeScript as well; you can use classes to create objects. But objects in TypeScript are not bound to their classes.

Consider the following example:

class Dog {
  name: string = 'Nobody'
}

class Cat {
  name: string = 'Nobody'
}

These types do not derive from any kind of parent class, like Animal for example. And yet they are interchangeable:

const cat = new Cat()
const dog = new Dog()
const animal: Dog = cat // it works

Observe what’s happening when I assign a cat to a dog. No errors whatsoever. Both Cat and Dog have a name property of type string. The structural contract is fulfilled.

To spice things up, let’s introduce an Animal interface:

interface Animal {
  name: string
}

Our Animal interface is still not connected to our classes. To differentiate between the two classes, let’s add a bark() method to the Dog class:

class Cat {
  name: string = 'Nobody'
}

class Dog {
  name: string = 'Nobody'
  bark() {
    console.log('bark')
  }
}

As you may have guessed, our cat can be assigned without issues to an Animal object:

const cat = new Cat();
const animal: Animal = cat;  // it works

What about the Dog? Well, this will also work just fine:

const dog = new Dog();
const animal: Animal = dog;  // it also works

Both Cat and Dog have the property name: string in common. That makes them compatible with Animal.

This doesn’t work both ways, because Dog has an additional method that Animal doesn’t support. If you try to assign an animal to a dog, you will get back an error:

// create an animal object
const animal: Animal = { name: 'Apple' }
// Asign it to a Dog class
const dog: Dog = animal // Property 'bark' is missing in type 'Animal' but required in type 'Dog'

We say that Dog extends Animal, because Dog contains all the members that Animal contains, and maybe some more. But the opposite, as we’ve seen, is not true.

I hope this gives you an overview of how a structural type system works in practice. It’s completely different from a nominal type system, in which the language is strictly checking for the origin of an object. In languages like Java for example, the examples above would not work, because Cat and Dog are completely unrelated classes, regardless of if they are similar.

Now a small reminder; If you want to check if an object is related to another one, you have to use the instanceof operator:

dog instanceof Cat // false

We are basically checking if the dog has the cat in its prototype chain. It certainly doesn’t.

So why is TypeScript that strange? 🙋‍♂️

Why is structural typing useful?

The reason this feature exists is to make the language backwards compatible with JavaScript applications. JavaScript is a dynamic language, and it never had strict types. TypeScript adds only a minimum set of rules, to enforce strict type checks in your code, by preserving the mechanics of the JavaScript language. This not only makes it backwards compatible, but it also requires less effort from your side to integrate it into your projects.

That’s how TypeScript won the race for strict typing languages. There were plenty of them out there, that were compiling to plain JavaScript. But nobody wants to write everything from scratch. Nobody wants to learn a new language. Such a shame, and yet a reality.

Existing JavaScript code will work as is in TypeScript, without any refactoring. That’s why structural types are useful.

A journey to TypeScript’s type universe

If we have to visualize the previous example, we will end up with the diagram below. Every bubble represents a type. As we’ve seen, types can be classes, type aliases, interfaces, or a union which is a combination of types.

The Dog type can be assigned to both the Cat and the Animal types. That logically doesn’t make sense, because the Animal is the logical parent of these two types. That’s the tricky part you need to understand with TypeScript. The same applies with the object type, which can accept any object structure. At the very top we have any, which can accept all the types.

The structural typing system doesn’t affect only object structures, but other kinds of types as well. The situation gets more complicated when you create unions, which can combine any types. I will explain how those are connected in the next articles.

For a birds-eye view, here are the top level types that are available in TypeScript:

We have immutable primitive types: number, string, and boolean, and Symbol.
And we have reference types which can all be represented by the type object.

As you can see, the bubbles are completely independent here. That’s because they are not compatible with each other. You can’t assign an object to a boolean, for example.

Now, let’s zoom in, to see which values are compatible for each of them. Note that a number type can also include NaN. An object type can include any object declaration {}, arrays, regular expressions, dates, and the list goes on:

// the following asignments will work fine
const aNumber: number = NaN
const generalObject: object = {}
generalObject = /some string/i
generalObject = {}

Next to these, TypeScript adds some special wildcard types:

any: the parent of all TypeScript types. You instruct TypeScript that you don’t know what a type can be, but it’s ok. You give your permission to TypeScript. You’re saying “I know what I’m doing here”. Most of the cases you simply don’t.
unknown: This is again the parent of all types, with a small catch. You instruct TypeScript that you don’t know what the type can be, but you want to protect yourself from unnecessary mistakes.
never: This is the opposite of the previous ones. It basically means no type must be assigned to that thing, no matter what. Think of it as the value null. It is useless as a value, but it plays a big role in the logic of your application.

Of course, we can create our own custom types:

// we have a custom type
type OneTwoThree = 1 | 2 | 3
// we create a variable
const aValue: OneTwoThree = 1
// since all of its values are numbers, it is assignable to a number
const anyNumber: number = aValue // it works fine
// and of course we can assign it to a type of any
const anything: any = aValue // it works fine

In the previous example, our type alias OneTwoThree can contain specific numbers. This immediately makes it compatible with the number type. You can’t assign any number that you want to the aValue variable, but you can assign the aValue variable to anyNumber. In the same way, you can assign anyNumber to anything.

If you want to learn more details about the available types of TypeScript, I have another article which explains everything you need to know about them.

Nullable primitive values

In JavaScript, we have the following nullable primitive values:

undefined: When no value is assigned.
null: When we specifically assign a null value to an object.

Don’t be confused, nullable types are not valid types in TypeScript, but values that can be assigned to variables.

Yes, I hear you. You can set a variable to null or undefined:

const alwaysUndefined: undefined = undefined
const alwaysNull: null = undefined // Error: Type undefined is not assignable to type null.

In the previous examples, we have declared the variables alwaysUndefined and alwaysNull, which respectively can only accept undefined and null as allowed values. Here we are basically instructing TypeScript, to use the undefined and null values similar to how we use a string value “green” or a number value 123.

const alwaysGreen: 'green' = 'green'
type Always123 = 123

Kinda boring, isn’t it? 😑

Now I want to make a small note here; TypeScript will not allow assigning null or undefined values to a variable by default. That’s only possible when you have specifically disabled strictNullChecks in the compiler configuration file, and you have set the strict mode set to off.

By default, strict mode is on, which sets all the strict flags to true. If you want to write robust code, you should definitely avoid having nullable variables.

The following will not work, if we have strict mode enabled, which is the default option:

const space: object = null // Type null is not assignable to type object.

This was a useful introduction that will help you create a mind map to have a holistic view on types in TypeScript. In my next posts, I will cover more ways you can dynamically generate type combinations. Until then, stay curious. 🤓

Cover Credit: Mehdi MeSSrro

TLTR; TypeScript Narrowing

Tue, 15 Mar 2022 22:12:00 GMT

So you have an unknown parameter in your function. Is it a string? Is it a boolean? Is it some kind of weird combination of properties and methods? How can you tell?

In this article we are going to address one of the most important topics; How do we narrow down a type to more specific ones? What options the JavaScript language has built-in and what are the features TypeScript adds to protect us from common mistakes?

If you don’t have a lot of experience with JavaScript, this article will be a gold mine for you. I tried to collect as much information as I could, to make you understand the important bits and pieces of my most favorite language, that usually drive people crazy and discourage them completely.

Enough with the intro. Let’s start with a coding challenge. Hooray! 🤗

Consider the following JavaScript function getWidth():

function getWidth(width?: string | number) {
  if (typeof width === 'number') {
    return `${width}px`;
  }

  return width;
}

This basically returns values for the css width property. The logic is the following:

// number values get the suffix px:
getWidth(100)  // '100px'
// string values get no suffix:
getWidth('100%')  // '100%'
getWidth('auto')  // 'auto'

Can you guess what the type of the argument width is in every single line of the code above? Do you think this code will work as expected?

I am going to reveal the solution in the next paragraph. Spend a minute thinking about it before you continue.

Chocolate? 🍫

The Control Flow Analysis of TypeScript

To solve the mystery, let’s fire up our favorite TypeScript text editor and paste the challenge there. Try to hover over the width argument in every single line. As you do that, you will notice that TypeScript will give you a special union type with all the types.

Here’s what we have:

function getWidth(width?: string | number) {
  if (typeof width === 'number') {  // string | number | undefined
    return `${width}px`;  // number
  }

  return width;  // string | undefined
}

Notice that within the if block, the type of the argument width is a number. That’s logical, since we are checking if the width parameter is a number within the if conditional. But how does TypeScript know what it will be? Has it compiled the code already?

It turns out that it does. 😏

TypeScript evaluates your code at compilation time, to detect how the type of a value changes at any given position.

Combine this with type inference and you get pretty sophisticated error detections.

Now, back to our example. If we hover over the width argument in the last return statement, we will see that the possible values are string | undefined. That’s logical, because if the width argument was a number, the execution would have stopped right inside the if block. TypeScript understands that, and removes the string type from the union. But what about the undefined? Will this be a problem?

Oops, I did it again! 😬

Of course, width can be undefined, because it’s an optional parameter. This means that you will not get the best results if you call this function with no arguments:

getWidth();  // returns 'undefinedpx'

With the help of TypeScript, we know that our function needs some refactoring:

function getWidth(width?: string | number) {
  if (typeof width === 'number') {
    return `${width}px`;
  }

  return width || 'auto';
}

Now, no matter what, the function will always return a value or it will default to auto. TypeScript helped me identify the bug here.

Now, you may be wondering, do I need to hover over my types and check all these things? Why didn’t TypeScript complain about this? 😒

I could have prevented this from happening, if I had specified a type for the return value:

function getWidth(width?: string | number): string {
  if (typeof width === 'number') {
    return `${width}px`;
  }

  return width;  // Error: Type undefined is not assignable to type string
}

Now I get back a very informative error:

That’s the reason we really have to encourage our team colleagues to be very descriptive with types.

One last thing; If somebody tries to pass null instead of undefined, TypeScript will throw an error:

getWidth(null) // Error: Argument of type 'null' is not assignable to parameter of type 'string | number | undefined'

It got me covered! 😋

So TypeScript is evaluating your code at compile-time and it can predict what type a value can have. Combine this with the type inference feature and you get a very sophisticated bug prevention system.

We’ve seen this behavior with the unknown keyword:

function someplay(files: unknown) {
  files.map((t) => console.log(t)) // Error: Object is of type 'unknown'
}

Here, TypeScript prevented us from calling the method map() that may not exist in the files argument. In fact, files may not be an array at all.

Control flow analysis is being improved with every version of the language. More and more features are being added.

Type Guards

Here’s how you can check if the files argument of the previous example is an array:

function someplay(files: unknown) {
  if (files instanceof Array) {
    files.map((t) => console.log(t))
  }
}

I used a condition that checks if the files variable is an array. Within the if block, we know for sure that the type of the files variable is an array, and therefore we can call its map() method.

For a TypeScript developer, it’s important to understand how to narrow down types to more specific ones. These kinds of checks are called type guards.

A type guard is a form of a code expression, which helps TypeScript refine types down to more specific types.

Let’s review all the tools JavaScript has already built-in. Yes, all these will work at runtime.

The `typeof` operator and its misbehavior

You are probably familiar with the typeof operator in JavaScript:

// Checking the type of a value
typeof 'something' // 'string'
typeof 2022 // 'number'

// Checking the type of a variable
let add = (a, b) => a + b
typeof add // 'function'

It always returns a string and the possible return values, according to MDN, are the following: undefined, object, boolean, number, bigint, string, symbol, and function. For all the other values that are not in this list, typeof will return "object".

Can we really depend on typeof to check all kinds of values? No we can’t. It’s very limited and kinda confusing. For example, if you try to get the type of an array, here’s what you will get back:

typeof [] // 'object'

Of course, arrays in JavaScript are indeed objects. But someone will argue that functions are too. So why do we get a return value for functions and not for arrays, which are also really common in our daily code?

The results of typeof are not only incomplete, but they are buggy too. You may probably know that null is also an object:

typeof null // returns 'object'

That didn’t go very well. 🤪

Instead of having the programming language work for us, we have to do the thinking here.

Thankfully, TypeScript knows about such misbehaviors and it can protect us from unnecessary bugs.

The `instanceof` operator

We can check if a specific object is an instance of another object:

function count(values: number | Array<number>): number {
  if (values instanceof Array) {
    return values.reduce(
      (previousValue, currentValue) => previousValue + currentValue,
      0
    )
  }

  return values
}

Remember that in JavaScript we have prototypical inheritance. Every object has a prototype, and it derives all its logic. This works like a chain. The parent object of all objects is the actual Object.

In the example above, we are counting the numbers by reducing an array of values. If we get a single number instead of an array, we are returning the number itself. We check if the values argument is an instance of the Array object. If you don’t check this before calling the reduce method, TypeScript will throw an error, because a number doesn’t implement this method.

Searching for the truth

I bet you are also familiar with the if statements, so I’m not going to elaborate more on this topic.

Maybe you are not familiar with the fact that JavaScript can accept any kind of value in a conditional:

if (3.14) {
  // oops, that's not a boolean, but is it truthy?
  return 'the value is truthy'
}

What JavaScript is doing here, is to coerce the number to a boolean, and then to evaluate the condition:

if (new Boolean(3.14)) {
  return 'the value is truthy'
}

You may be wondering how JavaScript decides which values are truthy or falsy? That’s one of the trickiest quirks of the language.

Prepare to be amazed! 😋

Falsy values

When you compare values, the following are always equals **false: null, undefined, false, 0, -0, NaN and the empty string “”:

// All the following return false
Boolean(false) // The obvious boolean false
Boolean(null) // A null value
Boolean(undefined) // An undefined value
Boolean(0) // The number zero
Boolean(-0) // The negative number zero
Boolean(0n) // The bigint zero
Boolean(NaN) // The result of an operation that is not a number
Boolean('') // An empty string

Everything else always equals true:

// Be careful, all the following will return true
Boolean(true) // The obvious boolean true
Boolean({}) // Any object
Boolean([]) // Any array (which is an object)
Boolean(new Date()) // Any date (which is an object)
Boolean(42) // Any number, except zero
Boolean(-42) // Any negative number, except zero
Boolean(12n) // Any bigint, except zero
Boolean(3.14) // Any float number, except zero
Boolean(-3.14) // Any negative float number, except zero
Boolean('0') // Any string, except an empty one, including "0"
Boolean('false') // Any string, except an empty one, including "false"
Boolean(Infinity) // Any object
Boolean(-Infinity) // Any object
Boolean(() => {}) // Any function

The list of truthy values in JavaScript is infinite.

You can also use the ternary operator to save some space:

'false' ? 'truthy' : 'falsy' // returns 'truthy'

I recommend for newbies to spend some time getting familiar with the truthy and the falsy values of JavaScript.

Switch statements & Exhaustiveness checking

We can simplify the example above by using a switch statement:

function getWidth(width?: string | number): string {
  switch (typeof width) {
    case 'number':
      return `${width}px`
    case 'string':
      return width
    default:
      return 'auto'
  }
}

Switch statements support any value you can imagine, even a computed one. We use them to refactor multiple blocks of if statements. More on them later.

TypeScript can be really powerful when you are using a switch statement. With a feature called exhaustiveness checking, you can be sure that you handled all the available cases.

Let’s illustrate this logic in the following example:

type ActionTypes = 'LOADING' | 'LOADED';

interface LoadingState {
  isLoading: boolean;
}

function reducer(
  currentState: LoadingState,
  actionType: ActionTypes
): LoadingState {
  switch (actionType) {
    case 'LOADING':
      return { ...currentState, isLoading: true };
    case 'LOADED':
      return { ...currentState, isLoading: false };
    default:
      **const _exhaustiveCheck: never = actionType;
      return _exhaustiveCheck;**
  }
}

The never keyword can play the role of the type guard here. Remember that we can’t assign any type of value to a variable with the type never, except from values that are themselves type of never.

We basically have a reducer here, which accepts the currentState and the actionType and it returns the updated state. We define all our action types in a type alias. The magic happens within the default ****case. We assign the actionType to a variable that is only meant to be used for exhaustiveness checking. Theoretically, if we did exhaust all the possible cases of the actionType values, we would never end up with the default case.

Every time we add a new case block, TypeScript eliminates one of the possible values. When we reach the default case, it expects that there are no types left, which means the type of the actionType argument is never.

Can you guess how powerful this is? 🤠

Let’s imagine that we have another action, to indicate that something has failed:

type ActionTypes = 'LOADING' | 'LOADED' | 'FAILED'

The moment we change our type alias, TypeScript will throw an error:

You have successfully guarded your reducer from action types that it doesn’t handle.

Logical Operators

JavaScript has the following operators: && and ||. But there’s a catch!

The result value of AND, and OR operations in JavaScript is not a Boolean.

The logical OR || operators return the first value if it’s true, or the second one if it’s false:

var s = 'text'
var n = 5
s || n // returns 'text'

It’s also a good hack to set a default value in case of a missing variable:

const tracks = response || []

In the example above, if the response is undefined, we will set an empty array as the initial value. How cool is that?

The logical AND && operators return the value of the second argument if both values are true, or the first one if both values are false, or the first falsy value:

var s = 'text'
var n = 5
s && n // returns 'text'

It’s a good hack to display UI elements:

function renderTracks(tracks) {
  return tracks && tracks.map((track) => <Track track={track} />)
}

This example will make sense to you if you are familiar with React’s JSX. Basically, we are checking whether the tracks parameter is truthy, which means it’s an array. Since the second part will always be truthy, this is the value we will return. If tracks is null or undefined, we will return that value. It may seem like a huge hack, but it’s been used in every React application.

Finally, the && operator is more precedent than ||:

// with the parenthesis
a || (b && c)
// without the parenthesis (same result)
a || (b && c)

Comparison Operators

There are two different ways to compare if the two values are equal. The == double equals and the === triple equals operators.

The double equals == performs an implicit coercion before the comparison; aka it doesn’t check the types of the values. You should only use it if you and everybody in your team understand how it works and if you are familiar with all its misbehavior.

5 == '5' // true

I will address how this works in a moment. For now I want you to remember that most of the time you should use the triple equals operator === which also checks the type of the variable:

5 === '5' // false
5 === 3 + 2 // true

Objects are being checked for their reference. JavaScript will never compare their values.

{ name: 'Nicos' } === { name: 'Nicos' }  // false

Ah, and NaN is not equal to itself:

NaN == NaN // false
NaN === NaN // false

Which is the reason we use Object.is() method:

Object.is(NaN, NaN) // true

It is safe to use == with the typeof operator:

if (typeof five == 'number') {
  return 'no way!'
}

To compare if the two values are not equal, of course, you can use != and !==. They work similarly with equal operators. Abstract relational comparison (<, >, <=, >=) always coerces the values, similar to ==.

And one more thing to make fun of your other JavaScript colleagues; a > b is actually !(b < a). 😎

TypeScript understands all these rules as you compare values that can accept different types, and it can predict what the result type will be. This doesn’t work all of the time. It is suggested to setup a linter, if you want to have an indicator that you are probably making some mistakes, as you type code.

Some words about Coercion

In JavaScript there is a weird feature called Coercion. Somehow the language itself takes care of the casting for you, so that you don’t have to. As we’ve seen this is happening everywhere in your code.

Here’s an example we’ve seen before:

5 == '5' // true

Obviously the number five is not equal to the string five. But that’s how the double equal operator is working. It first coerces (converts) the values, and then it compares them. In JavaScript, you can compare any value, regardless of their types. Conditionals can even be used anywhere in your code, as a valid expression.

That’s basically called implicit coercion, because you don’t explicitly cast the value by yourself.

A lot of people prefer explicit coercion. Here’s an example:

5 == Number('5') // true

Now, there’s a misconception about how types will be coerced. Do you expect JavaScript to convert the string to a number or the number to a string? Let’s give it a try:

5 + '1' // '51'

Yup! We have a winner! 😋 In general, there is a priority in place:

// String beats everyone
2 + '1' + true  // '21true'
// Number beats booleans
2 + true  // 3
// Avoid non-primitive types
{} == {}  // false

Coercion is indeed a powerful feature, which is intended to help you reduce code and improve readability. It’s one of the reasons developers who are new to coding like JavaScript. It’s extremely unpredictable, though. And you should spend an amount of time getting used to it.

“Every JavaScript developer should spend some time to understand the concept of Coercion and learn its rules.” Kyle Simpson

The `in` operator

We can check if an object contains a member, by using the in operator:

interface Playable {
  filename: string
  play: () => void
}

interface UnPlayable {
  filename: string
}

function playFile(file: Playable | UnPlayable) {
  if ('play' in file) {
    file.play()
  }
}

In this example, we have two interfaces. Only one of them contains the play() method. In the play function, we can narrow down the file objects, to find the ones that are playable.

Type predicates

What if I told you that you can use all the tools you’ve learned above to build your own type guards? Sounds intriguing? 😉

Here’s an example:

function isPlayable(file: Object): file is Playable {
  return 'play' in file
}

Mind the is operator in the return value of this function. This is not a function that returns a Playable. It acts as a type guard that checks if an object is Playable. By saying file is Playable, we are creating a logical indicator that helps TypeScript treat this function as a type guard.

We can now use this type guard to simplify the logic of our play() function:

function playFile(file: Playable | UnPlayable) {
  if (isPlayable(file)) {
    file.play()
  }
}

Notice how TypeScript now recognizes the type guard and it doesn’t complain about the missing play() method in file. What a nice feature. This feature is quite useful in a language like JavaScript.

This article took a lot of time, but I’m really happy I collected everything you need to know about narrowing types in TypeScript.

If it helped you learn something new, then a tweet would be great 🙂.

Cover Photo Credit: Rodion Kutsaev

Master Generics in TypeScript

Wed, 26 Jan 2022 22:12:00 GMT

TypeScript can speed up our JavaScript projects. Its type system can show you errors right within your text editor. This can be cool most of the time. By spotting errors faster, you spend less time on debugging and bug fixing.

Type checking can also cause frustration. In fact, sometimes it’s quite hard to deal with types. Since there were no types around, JavaScript developers got used to writing flexible code that covered a lot of use cases. A function that accepts all kinds of objects. A class that can be applied to multiple types. The situation becomes worse when you have to support legacy JavaScript code.

Don’t get me wrong. Most of the time, having code that handles multiple types is convenient and totally legal. But how can we set boundaries?

Moreover, there are cases that TypeScript becomes very demanding. Focusing on your product and its business logic becomes the hardest thing in the world. Instead, you are writing unnecessary code just to satisfy its type system.

If you spent a day in your life just trying to get rid of a type mismatch, that you don’t even understand where it came from, you are not alone!

Thankfully, TypeScript provides a solution to this problem. It has support for generic types. This unlocks a ton of possibilities. Some people think this is the way to write code for your types. In the following paragraphs, we will learn what problem generics solve, their syntax, and how you can use them practically in your code.

This article belongs to my series Too Long To Read TypeScript. Every article covers in detail a core concept of the language. I am also producing a free YouTube course.

Candy? 🍬

What is the problem Generics are solving?

The problem of introducing types into a language which was never designed with them in mind, shines as we try to create a more production-ready application. Let me give you a simplified example, which demonstrates the challenge that we face here.

Consider the following function. It receives a song title and it displays it on screen:

function echoTitle(title: string): string {
	return title;
}

At the moment, our function is working only with string types and it is returning a string. Obviously the following will not work:

echoTitle(2021);  // Type error, we are passing a number instead of a string

In order to have a similar function, that works with number types, we will need to define it separately:

function echoYear(year: number): number {
	return year;
}

echoYear(2021); // it works perfectly!

But what if we really, really want to have a single function, which just returns the types we pass on it, like in the good old JavaScript days:

function echo(arg) {
	return arg;
}

Well, somebody will think, let’s use any:

function echo(arg: any): any {
	return arg;
}

Wohohoo! Problem solved. Commit and push! 😎

But wait a minute. Is this really type checking? I would argue it is not. As you may know, any must be avoided, because it’s basically a wildcard that disables type checking completely. Something like ts-ignore. As long as I hate to admit it, yes, any is not the answer here. We need to be flexible by staying secure. But then what?

Solving this challenge will help us a lot with our TypeScript journey. For example, how would you define the map array method itself, a server response promise, or even our most favorite console.log()? They can all work with any type. They are all very popular and hard to replace.

What if I told you that TypeScript has support for such generic cases. Well, my friends. Let me introduce you to Generics…

Generic Functions

What if we had some sort of a parameter, which stores the type of the argument. You could then use that parameter to define what our function accepts and returns.

This is exactly how generics work:

function echo<Type>(arg: Type): Type {
	return arg;
}

Notice that now our general echo() function accepts an extra parameter of Type. We use <> to indicate the existence of this extra type parameter. This is basically a generic variable, that we declare when we will consume the echo<>() function. Then, we use this generic to define the type of the arg parameter and the type of the return value.

Let’s break down that function declaration:

// we have a function
function
// That is named echo
         echo
// Which accepts a type parameter, named Type
             <Type>
// And also accepts a normal parameter, named arg
                   (arg      )
// and it's value is the same as the one Type uses
                   (   : Type)
// And it returns a value that uses the type of Type
                              : Type

For simplicity, the TypeScript community simply uses the capital letter T to name this type parameter:

function echo<T>(arg: T): T {
	return arg;
}

Now we can use our newly created function. In order to do so, we have to specify the type that we want to use for our generic T:

echo<number>(2021); // will work
echo<string>('Bohemian Rhapsody'); // will also work

Now compare this approach with the any approach. TypeScript will prevent any other type from being passed to this function accidentally or intentionally:

const year = "2021";

echo<number>(year); // Year is not a number, and this will fail

And remember, we are not limited to using built-in types only. We can use our own classes, interfaces, type aliases, or anything else.

So far we have been explicitly defining the types in our generic functions. TypeScript also supports an implicit way:

const year = "2021";
echo(year); // T is inferred as a string

I have simply removed the type and now it echoes the string. This means that you can simply consume generic functions, without explicitly specifying their types. Type inference kicks in. Try hovering over this echo function, to see what type is inferred.

I don’t know about you, but this looks like JavaScript to me.

Photo Credit: Shubham Dhage

Generic Classes

So far, we’ve seen how generics can be used with functions. Let’s review another example, this time with classes.

Here’s a Playlist class that stores some tracks:

class Playlist {
	tracks: Track[] = [];
	
	addToPlaylist(newTrack: Track) {}
	removeFromPlaylist(trackToRemove: Track) {}
}

We’ve seen the class Track in previous posts:

class Track {
	title: string = '';
  releasedAt: number | undefined;
  gernes: string[] = [];
  isFavorite: boolean = false;
	
	constructor(...) {}
}

What if I had also music videos in addition to tracks? I will most probably need another playlist class that supports a new type of VideoClip. Or I can simply modify my Playlist class with a generic:

class Playlist<T> {
  public items: T[] = [];

  addToPlaylist(newItem: T): void {
    this.items.push(newItem);
  }
  removeFromPlaylist(idToRemove: string) {
    this.items = this.items.filter((i) => {
      i.id !== idToRemove;
    });
  }
}

The same concept applies here. I have a generic type T, which stores the type of the class I want to instantiate. We use this type T to define the items list and the newItem parameter of our addToPlaylist() method.

Now here’s how you can use this class with multiple types of object types:

const songPlaylist: Playlist<Track> = new Playlist<Track>();
const videoPlaylist: Playlist<VideoClip> = new Playlist<VideoClip>();

Just like that, we now have the same functionality that handles a playlist, without having to maintain two different classes.

Now the magic begins. As I keep adding items in my playlist, TypeScript prevents me from storing something I’m not supposed to:

songPlaylist.addToPlaylist(new Track()); // works fine
songPlaylist.addToPlaylist(new VideoClip()); // throws an error, songPlaylist accepts only Tracks

Generic Constraints

Something you will most probably experience with generic classes, is the fact that TypeScript may start complaining about properties that aren’t defined.

In our previous example, the TypeScript compiler is complaining about the id property. It simply can’t find it in class T:

That’s unfortunate, because the type of T is unknown. TypeScript can’t tell if id exists there or not. I wonder how I can tell TypeScript that this thing, no matter what it is, it must have a property id in it. Otherwise, I cannot find how to remove it from my list.

But wait a minute, this is what interfaces are meant for, right? Here’s what we need:

interface WithId {
  id: string;
}

And here’s how to combine it with our generic type:

class Playlist<T extends WithId> {  public items: T[] = [];

  addToPlaylist(newItem: T): void {
    this.items.push(newItem);
  }
  removeFromPlaylist(idToRemove: string) {
    this.items = this.items.filter((i: T) => {
      i.id !== idToRemove;
    });
  }
}

In this example I have created an interface WithId, which has an id property in it. Now all the types that are passed in my class must implement this interface. Basically, this requires them to have an id property. So, even if they aren’t explicitly using the WithId interface, they could be compatible if they have that property.

Here’s what will happen if they don’t:

Now let’s modify our Track class to implement the new WithId interface:

class Track implements WithId {
  id: string;
  title: string = '';
  releasedAt: number | undefined;
  gernes: string[] = [];
  isFavorite: boolean = false;

  constructor(newTrackId: string) {
    this.id = newTrackId;
  }
}

Again, if I don’t explicitly add implements WithId in my class declaration, TypeScript will not complain at all, since the id property is present in my Track class, and its type matches. Just because this is a class under my control, this is considered good practice. It will be difficult to track which properties are really required in this class and which are not.

Finally, instead of creating an interface, we can solve the missing type declaration, by simply providing its type:

class Playlist<T extends {id: string}> {
	...
}

Use this approach if you think that the interface will not be reused. I personally prefer to create interfaces, because it just looks better when I read a class declaration and it is much easier to modify them in the future.

Generic Interfaces

We can create generic interfaces, similar to how we declare generic classes:

interface IPlaylist<T> {
	items: T[];
	
	addToPlaylist(newItem: T):void;
	removeFromPlaylist(itemToRemove: T):void;
}

And check this out. Now we can use the IPlaylist interface in our TrackPlaylist class:

class TrackPlaylist implements IPlaylist<Track> {
  public items: Track[] = [];

  addToPlaylist(newItem: Track): void {}
  removeFromPlaylist(itemToRemove: Track): void {}
}

Just like that, we now have an implementation of the Playlist interface, which stores Track instances.

Generic Interfaces are quite popular in TypeScript. They help you express many challenging scenarios and they are used quite frequently.

Discovering generics in more places

Understanding generics will help you read most of the TypeScript code that was ever written.

Now let’s combine everything we’ve learned. Remember the array method map()? We could use generic types to implement its signature. Here’s the definition of the Array interface, which contains the map() method:

interface Array<T> {
	map<U>(callbackfn: (value: T, index: number, array: T[]) => U, thisArg?: any): U[];
	...
}

Notice that here they utilize two generic types, one at the interface level, named T, and one within our method, named U.

At the beginning of this series, we talked about arrays. Here’s how we declare an array variable:

const daysOfTheWeekend: string[] = ['Saturday', 'Sunday']

Since arrays in JavaScript are basically objects, we could actually use the Array interface to declare an array:

const daysOfTheWeekend: Array<string> = ['Saturday', 'Sunday']

This will have the exact same results as before. Failing to pass the right values will fail:

daysOfTheWeekend.push(3); // fails because this is an array with string values

Now, if you are in VS Code, try to right click on the Array interface and select Go to Definition.

You will witness one of the built-in type definitions that TypeScript already provides for us. More specifically, in the lib.es5.d.ts file, TypeScript contains type definitions for all ES5 features. This can give us an idea of how generics can be used to define highly reusable code. Now you can apply functional programming to your project, without worrying about types.

I would encourage you to spend some time reading type definition files. They will help you understand how to use generics in your code. They can act as a good practice to apply what you’ve learned. You can also take ideas about challenging topics and see how other developers have overcome them.

Cover Photo Credit: Shubham Dhage

Type Wars: The TypeScript Saga

Wed, 19 Jan 2022 22:12:00 GMT

In previous articles, we’ve seen that TypeScript is a superset of JavaScript, that adds strict type support and a better developer experience. We discovered type aliases, classes and interfaces. Pretty cool stuff!

Some of us, including the author of this blog, are pretty skeptical about choosing which of these types to use under certain circumstances. Failing to do so, will increase confusion in the team and potentially will make the code harder to follow. The most difficult to pick is how to define the structure of an object. We can either use a class, an interface, or even a plain type alias. There are some subtle differences between these three keywords.

Well, not anymore! In this article, we will review their syntax and we will compare them side-by-side. Once and forever. I hope after reading the following paragraphs, you will feel more confident choosing the right type keywords in your projects, without any hesitation.

Coconut? 🥥

Too many keywords to choose from

Consider the following Track object, that we’ve seen so far in the previous articles:

const track = {
  title: 'Bohemian Rhapsody',
  releasedAt: 1975,
  gernes: ['Rock', 'Hard rock', 'Progressive rock'],
  isFavorite: true,
}

I can specify that this is an object in the following ways:

// using the object keyword:
const track: object = {  title: 'Bohemian Rhapsody',
  releasedAt: 1975,
  gernes: ['Rock', 'Hard rock', 'Progressive rock'],
  isFavorite: true,
}
// using the object notation:
const track: {} = {  title: 'Bohemian Rhapsody',
  releasedAt: 1975,
  gernes: ['Rock', 'Hard rock', 'Progressive rock'],
  isFavorite: true,
}

The first one is using the object keyword, which pretty much describes every object. The second one uses object notation instead. These {} object literals after the : colon don’t create a new object. It’s TypeScript’s object notation for setting an object as a type.

This basically tells TypeScript that track is expected to be an object. But this is not specific enough, is it? For example, if we try to assign a new object, it will work just fine:

track = { message: 'goodbye track!' } // track object has been replaced

There is a need to describe what is expected in the individual properties within the object notation:

const track: {  title: string  releasedAt: number  gernes: string[]  isFavorite: boolean} = {  title: 'Bohemian Rhapsody',
  releasedAt: 1975,
  gernes: ['Rock', 'Hard rock', 'Progressive rock'],
  isFavorite: true,
}

Clearly this works much better now. If we try to store an irrelevant object to the track variable, we will get back a compilation error:

track = { problem: "I don't know what I'm doing!" } // throws an error

Now we are guarding this track variable with precise prescriptions on what values it should accept. But again, what if we want to pass this object in multiple places? Clearly this long object notation is not efficient enough. And you know what they say about repeating yourself and how to keep things DRY.

Ah, and good luck if the object structure of our track variable change. We don’t want to put ourselves in a situation that requires a complete rewrite of our application just to support some new features. I hear you. We could try to use a type alias.

Type Aliases

Here’s the syntax of a type alias:

type Track = {
  title: string
  releasedAt: number
  gernes: string[]
  isFavorite: boolean
}

Now we can refactor our track object like so:

const track: Track = {  title: 'Bohemian Rhapsody',
  releasedAt: 1975,
  gernes: ['Rock', 'Hard rock', 'Progressive rock'],
  isFavorite: true,
}

Here we use the Track alias to guard the track variable. Basically, the result is the same as before, if we try to assign a non-compatible object value, or any other type that doesn’t match the Track alias, TypeScript will do one thing that knows very well. To throw beautiful colors.

Let’s review the main features of type aliases.

Type aliases support primitive types

First off, they can support primitive types and object structures:

type maybeAString = string | number

Here we used a union, to have a string that accepts undefined as a value. By default, TypeScript will yell at you if you try to leave a string undefined:

But we can if we introduce our own type alias. It won’t be a string. It maybeAString.

A type alias can fully support every feature of an interface. The opposite isn’t possible. You see, interfaces only describe object structures, not primitive types.

This unlocks the possibility to use a type alias as an enum:

type FileTypes = 'mp3' | 'mp4'

No other type annotation keyword in TypeScript has support for primitive types. Easy choice!

Type aliases can only be declared once

If we try to declare another track, we will get back an error:

type Track = {
  title: string
  releasedAt: number
  gernes: string[]
  isFavorite: boolean
}

type Track = {
  // error: Duplicate identifier 'Track'.
}

So, when to use a type alias?

That’s a type alias. It’s basically a shortcut to create custom types. Something like a variable that you can store any type annotation that you want. It basically supports all the operators and primitives of TypeScript. You must use type aliases when you have to support primitive types. They can take multiple forms. For example, they can act as an enum.

Avoid them if you are building a shared library or if you are writing type definitions. Type aliases can’t be extended, like interfaces, so the consumers of your library will not be able to add new features if they want. This is limiting for type definitions that are meant to support existing JavaScript libraries.

Now somebody may argue, if interfaces are the same, then why use a type alias and not an interface instead? What’s wrong with interfaces?

Great question. Really! Let’s elaborate more on that in the next section.

Interfaces

The previous example can be easily refactored to use an interface:

interface ITrack {
  title: string
  releasedAt: number
  gernes: string[]
  isFavorite: boolean
}

Mind the difference in their syntax; The = equals sign is not required when you declare an interface. We can then use the ITrack interface to guard our track object:

const track: ITrack = {  title: 'Bohemian Rhapsody',
  releasedAt: 1975,
  gernes: ['Rock', 'Hard rock', 'Progressive rock'],
  isFavorite: true,
}

Here, I used the letter I as a prefix to distinguish the interface from the type alias.

Now what is the difference? Do these examples produce different results? Does TypeScript get a different message? The answer is no! These two examples are completely identical. TypeScript will behave the same. There is no fundamental change whatsoever.

Let’s review the main characteristics of interfaces, to understand what differentiates them from other type keywords.

Interfaces can act as type annotations for object structures

Interfaces are meant to declare an object structure. They don’t support primitive types, like type aliases do. In the example above, we replaced the Track type alias with the interface ITrack.

Interfaces can connect unrelated classes together

You know that classes can implement interfaces. TypeScript will check if all the members of the interface are being declared appropriately in your class.

Consider the following interface, plain and simple:

interface ISpam {
  annoyReaders(): void
}

We can use this interface in a blog post class:

class BlogPost implements ISpam {
  title: string = 'TLTR; TypeScript';
  releasedAt: number = 2022;
	author: 'nicotsou',
  annoyReaders(): void {
    console.log('Accept our coookie!');
  }
}

But we can also use it to an email demon:

class EmailDemon implements ISpam {
  annoyReaders(): void {
    console.log('Please accept our coookie!')
  }
}

These two classes are completely irrelevant. By implementing the ISpam interface, they both share the same functionality. This means that we can now write code that implements functionality for both these objects, without worrying about unexpected results. We will expect that they will contain a method annoyReaders().

Beware of the cookies!

Interfaces can be extended

In contrast to type aliases, interfaces can be defined multiple times in your project. Their definitions can be merged. This feature is called declaration merging.

Consider the following declarations of the same interface ITrack:

// declaration A
interface ITrack {
  title: string
  releasedAt: number
  gernes: string[]
  isFavorite: boolean
  play(): void
}

// declaration B
interface ITrack {
  length?: number
}

They can be in the same file, or in different places within our project. TypeScript will not complain about this duplication. Instead, these two definitions will be merged into the following object structure:

interface ITrack {
  // declaration A
  title: string
  releasedAt: number
  gernes: string[]
  isFavorite: boolean
  play(): void
  // declaration B
  length?: number
}

This feature of interfaces makes them ideal for type definitions for shared libraries. Consumers of these type definitions will have the opportunity to extend them in the case they want to add missing implementations.

So, where to use an interface?

It is common to use interfaces to represent the shape of objects, function arguments, and classes you want to behave in a common manner. Use interfaces for type definitions in your shared libraries.

Some examples are a form model, your React component properties, the configuration object of a function, the response object of an api, or the payload of an event action.

Photo credit: Dan Counsell

Interfaces vs type aliases

That’s a tricky choice, because in the end they both can describe object structures. Both interfaces and type aliases can be implemented, which makes type aliases something like a super-type. Interfaces can be represented fully by types, but types cannot be represented with an interface. That’s because types can represent primitive types, object data structures or both if you use a union.

Interfaces can be extended. That makes interfaces really great to work with when we are defining type definitions for our libraries.

Types are commonly used in situations when you have an instance of a variable that you want to pass around, but I have seen projects using them to describe object structures.

I hear a man screaming at the back of my head. Yes, I confess. Sometimes I do hear voices.

“Nicos, what about classes? They can also be used to describe object structures, right? What’s wrong with classes?”

Another great question. Another paragraph for this article. OK, let’s see how this will go.

Classes

We will create a Track class to describe the shape of our track object. I will name it TrackClass, just to avoid name conflicts:

class TrackClass {
  title: string
  releasedAt: number
  gernes: string[]
  isFavorite: boolean
}

The syntax is similar to the interface, only the keyword at the beginning changes. But if you try this in your text editor, you will see that TypeScript cries multiple lines of errors:

We did define our class members, but we didn’t provide a way to instantiate objects out of it. Remember, a class is meant to be used as a blueprint to create objects. But how can we create objects if there is no constructor in place? Ha! We just found our first difference. Excitement. We will find out more as we go. But first, let’s fix that class:

class TrackClass {
  title: string;
  releasedAt: number;
  gernes: string[];
  isFavorite: boolean;

  constructor(
    title: string,
    releasedAt: number,
    gernes: string[],
    isFavorite: boolean
  ) {
    this.title = title;
    this.releasedAt = releasedAt;
    this.gernes = gernes;
    this.isFavorite = isFavorite;
  }

OK, now we are ready to review the characteristics of classes.

Classes are available at runtime

A class is not yet another TypeScript thingy, that we solely use for type annotation. It’s a JavaScript keyword nowadays. This means that it is available at runtime. This doesn’t apply to type aliases and interfaces, which are TypeScript exclusives. They will be completely removed from the transpiled code.

Classes can instantiate objects

The main purpose of a class is to create objects:

const track: TrackClass = new TrackClass(
  'Bohemian Rhapsody',
  1974,
  ['Rock', 'Hard rock', 'Progressive rock'],
  true
)

We can’t use other types like this, but we can use a class to annotate objects that have a compatible structure:

const track: TrackClass = {  title: 'Bohemian Rhapsody',
  releasedAt: 1975,
  gernes: ['Rock', 'Hard rock', 'Progressive rock'],
  isFavorite: true,
}

Now, this example may look convenient to you, but again, a class is not meant to be used as a type to describe existing objects. In situations like this, consider using an interface or a type alias. It only makes sense to have a class, when you use its constructor to create objects and you want to apply certain rules upon their creation.

Classes support OOP features

Classes support a lot of features that we can find in classical object-oriented programming languages. You can have private, protected and public members. You can have setters and getters, readonly, or static properties. You can implement inheritance and many nice design patterns much easier. These features, together with the constructor we mentioned before, can provide safety, a sense of privacy to your models. They set standards and make your code much easier to understand and maintain.

Although, using such OOP features is a design decision you have to make for your project, using a class is the only way to implement it. No other type keyword has support for such OOP features. No can dosville baby doll. Don’t ask me why, that episode of HIMYM was playing while I was writing this article.

Photo Credit: Stillness InMotion

How do abstract classes compare to interfaces?

You may be tempted to use an abstract class instead of an interface. And it’s a very good option, for those who want to structure their models in a certain way. Besides the previous differences that we mentioned, there’s a fundamental one that separates interfaces from abstract classes.

Interfaces can be used to set rules for the classes that implement them. Think of them like a contract. You accept the terms and conditions, now you have to implement them fully. This is similar to how abstract classes work.

A class can implement multiple interfaces. Classes can only inherit from a single class.

Remember the ISpam interface and how we used it to connect two unrelated classes? If we had used an abstract class Spam, we would have to inherit from it, and this unavoidably would have established a connection between these classes. That’s not what we want, right?

By inheriting from an abstract class, your classes are strictly dependent on that abstract class. Interfaces on the other side, are loosely coupled. This means we could potentially use them to apply a certain behavior to classes that originate from different parents, or classes that are completely independent.

On the other side, we can use abstract classes and inheritance to structure our code in a way that makes sense. In that case, we will get for free all the OOP features, that abstract classes support. This means we can be much more descriptive about how certain class members must be instantiated.

Enums

TypeScript has a dedicated enum keyword:

enum FileTypesEnum {
  Mp3 = 'mp3',
  Mp4 = 'mp4',
}

In comparison with the type alias that we used before, enums have the following features.

Available at runtime

As we said, type aliases are used solely for type annotations and they don’t make it at runtime. On the other side, you can access the contents of an enum at runtime, because it will be included in the transpiled JavaScript code. The truth is, with enums you have the option to decide if you want them at runtime or not; with type aliases you don’t.

Type aliases vs enums

An enum is better to be used when we know all the values upfront. For example, the different statuses of an asynchronous api call, the days of the week, the different status flags, or to map state values to their keys. Use type aliases for dynamically generated values, or value sets that you don’t know upfront.

Ah, and stay tuned, because in the following articles I will show you how to dynamically generate enums by using plain types. We still have a lot to learn from TypeScript.

Cover Photo Credit: Shubham Dhage

2021 happened. I survived.

Wed, 05 Jan 2022 22:12:00 GMT

This post is dedicated to 2021. I will try to summarize all the important events, changes, content I consumed and things I learned. Happy new year everyone!

The year we had to stay safe. Again. 🦠

It’s been almost a year since I started writing on this blog and it feels like yesterday. Basically, it feels like last month was 2019. It’s like we are stuck in a bad dream. A dream that repeats itself and it doesn’t want to end.

We had a lot of faith in you 2021. Yes, in you, don’t look away. It’s going to be better, they were saying. No more restrictions, they were saying. Now we have the vaccine, they were saying. And here we are, again.

This was the year that we consumed more rapid tests than chewing gum. It’s like, there was no other sickness or possibility for something negative to happen in general. Do you have a headache? Do your eyes hurt? Do you have pain in the stomach? Did you miss your period? Are your tests failing? Your wifi went offline? Just take a rapid test. You will feel better.

Another year where hospitals are full. Family meetings are considered suicidal. Working from the office is illegal. Partying is also illegal and they know where you live. Working from home is the new black. Traveling is harder than bitcoin. Computer chips are the new toilet paper. Metaverse is still under development. And my 5G signal has improved, after the covid vaccinations. Thank you Bill Gates!

Are you there? Are you safe?

Another year with endless online meetings ☎️

We are experiencing the rise of online meetings. It’s free, there are unlimited rooms available, and you can bring people from anywhere in the world. And now it’s not just about Facebooks and Facetimes. Our lives became an endless online call.

Do you have a topic to discuss with your colleagues? Schedule a call. Annual winter party? Schedule a call. Team bonding event? Schedule a call. Watching a movie with your friends. Schedule a call. You are not sure which tie to put on? Schedule a call. Your cat is sick? Schedule a call and take a rapid test. What did I just tell you?

I call this Pijama-driven development.

Everybody loves online meetings because of these nice backgrounds and effects. Just make sure you mute your microphone when you are on another call with your friends, because the meeting gets boring. Ah, and remove that cat filter your kid put in yesterday. And please, please center this camera, we want to see your face, not your ceiling.

Yes, this was the year I organized a virtual birthday party on Zoom. I also attended a virtual marriage on Skype. Two phrases I would never imagine myself saying.

The year I started my blog. For real. 👨🏼‍💻

I can’t be more grateful for 2021. We had all the time of the world to focus on the things that brings us joy, and we didn’t have the sadness and the reality shock of 2020. It was a good opportunity for me to start this blog and I’m really thrilled about it.

I was preparing this site for years. Different designs, different technologies, different article topics and features. At the end I never had the dedication to finalize it. There was something else that was always more important. Not anymore. This blog became my creativity booster. It started as my second identity and now it becomes my own identity. Kinda weird if you think about it, but this is how it feels.

It’s difficult to write, I must admit. Besides the fact that English is not my main language and sometimes it’s hard to express myself, this whole personal blog concept used to be really confusing in my head. I haven’t found the recipe that works well for me. I was also not organized enough. Or to phrase it more accurately, not organized at all.

I now have a complete roadmap with things I want to produce as a content creator. This blog is just a working draft of what I have prepared for you, my friends.

Let’s see what 2022 has to bring. Cheers to that. 🥂

The year I started my YouTube channel 📺

In case you missed it, I started a new YouTube channel. My first series is called Too Long To Read; TypeScript and it’s going to be a complete course, that you can watch for free. I’m using future tense here, because I’m still recording the videos.

Starting a YouTube channel was a very interesting activity and I would like to share more about it in a separate post. A public note to myself.

The year I discovered Notion 📝

Speaking of planning, 2021 was the year I discovered Notion. This is not affiliate bullshit. I’m a big fan of this product. It is an affordable way to put my thoughts together and create a plan for my projects and personal improvement.

I have so many things to share about Notion, but I believe it deserves its own post.

Another year with good reads 📚

Here, I want to list the most important books I’ve read in 2021.

I want to begin with “The Now Habit” by Neil Fiore. I know it sounds cheesy, but this book changed my life. For a procrastinator like me, reading this book felt like someone was able to read my mind and do some research about it. Read it if you want to overcome your procrastination.

I really enjoyed the books “It Doesn’t Have To Be Crazy At Work” and “Rework” by Jason Fried and David Heinemeier, the co-founders of Basecamp. They are both very easy to read. They list a lot of nice ideas about how modern tech companies work. Besides the conflicts within the company last year, I do believe most of their points are totally valid.

I wasn’t aware of the book “The Software Craftsman” by Sandro Mancuso. I was always confusing this book with another one, for some reason. I also didn’t know he used to work in Switzerland. I also had a chance to connect with him via our local Java meetup. I totally recommend his book. I was able to relate a lot to the events and concepts he is explaining. It helps a lot if you want to understand the profession of the software engineer on a higher level. Five stars!

One of the books I always wanted to read was “The Clean Coder” by Uncle Bob, known as Robert C. Martin. It was easy to follow, although I believe he has written better books. It seemed to me this was a collection of personal notes. Some of them useful, others not so much. I had the chance to watch his speech at an internal EPAM event.

Another interesting read was the book “Outliers, The Story Of Success” by Malcolm Gladwell. It was a fascinating journey to answer one important question. What does it take to be successful? What characteristics do all successful people have in common? For sure, you will be surprised as much as I was.

In 2021 I also discovered the work of Austin Kleon. I’ve read all of his books “Steal Like An Artist”, “Show Your Work!”, and “Keep Going”. I would definitely recommend them to creative people who have always wanted to produce something, but always struggled to find the courage to make it happen.

Another year with great technologies 🔭

In 2021, I discovered languages and frameworks I hadn’t played with in the past. I discovered Python and Ruby. In other parallel universes they are probably my main languages. Recently I started playing with Dart and Flutter. In another parallel universe, I am ditching React.

I learned Gatsby, which I used to build this blog. It was the year I discovered the testing-library, and I had a chance to refresh my Docker and D3 skills.

Since I was preparing for my TypeScript course, I spent a lot of time mastering the language. You know what they say, the best way to learn something well is to teach it by yourself.

Finally, I did a lot of preparation for the AWS certificate, which I will probably take. Someday.

Another one, with great games 🎮

The titles I enjoyed in 2021 are Control, It Takes Two, A Way Out, Returnal, and Doom Eternal. I also played Life Is Strange; True Colors, and Ghost Of Tsushima. I played Phantasmagoria, a MSDOS gem from Roberta Williams. I also remembered the Theme Hospital and the recent Two Point Hospital. I love this game so much!

In 2021 I introduced myself to VR gaming. I bought an Oculus Quest 2, which I really recommend if you want to start. Some titles I would definitely recommend are Superhot VR, Arizona Sunshine, Synth Riders, The Climb, Population: One, Beat Saber, and After The Fall.

Another one, with the best music 🎧

The sound of 2021 was really great. You know that I’m making mixtapes for creative minds, like a 15 year-old who lives in the 80s, right? Well now you know!

Some of the albums I was playing on repeat this year; London Grammar, The Avener, Monolink, Roosevelt, Rüfüs Du Sol, Jungle, Jack Savoretti, Joel Culpepper, Foster The People, and of course Mandrugada.

I can’t wait for the live stages to open again. It’s goin’ to be legen-, wait for it…

That’s all folks! Let’s see what 2022 will bring us. Until next year, stay safe, stay curious 🙂

My inspiration for this blog post was the excellent retrospective by Tania Rascia. You should check out her blog, it’s awesome!

Cover Credit: Kazuend

Master Interfaces in TypeScript

Wed, 29 Dec 2021 22:12:00 GMT

Interfaces help us define the shape of our object structures.

An interface can act as a blueprint for a class, allowing us to add common functionality to unrelated objects. We use this feature to organize our code, by making it easier to follow and scale.

In TypeScript, interfaces can be used as type annotations, similar to class, type aliases, and other built-in types. This helps us guard our code against types. This strict type system protects us from common errors, which eventually speeds up our development times.

It also helps our code editor to have a better understanding of how our code is interconnected, and provides much more sophisticated auto-completion suggestions.

In the following paragraphs I’m going to explain in detail what an interface is and how you can use them in your code. I will give you some practical use cases, which will help you recognize where you have to use interfaces in your code. Before I leave you, I will explain the concept of declaration merging, which is one unique characteristic of interfaces.

🍦Soft Ice cream?

Why the hell I need another keyword?

Consider the following track object:

const track = {
  title: 'Bohemian Rhapsody',
  artist: 'Queen',
  isFavorite: true,
}

In a traditional JavaScript project, that’s a very convenient way to define objects. This specific one contains everything we need to know about a music track. Such object structures are created on the fly, as we interact with the different modules and packages of our application.

Objects can store anything. An api response. An event payload. Some configuration parameters. Information about styling, animations and many more. The simplest way to deal with such object structures is to create classes with all your models. But what about objects you can’t control, such as browser event payloads?

In the beginning, it didn’t cost anything to come up with object structures like these, so we went for it. As we go along we are adding more and more object structures. As the codebase grows, some of these object structures may already be defined somewhere else in our project. And you know what they say, duplication should be avoided.

Most of the times, it is difficult to recognize such duplications. You see, I may want to name the title of the track title, but maybe you had another naming convention in mind. Maybe you disagree with the schema of the response, or maybe you want to use underscores, for reasons unknown. And then another person joins the team and suddenly we have three different names. Now we have to collaborate with another team, which has three more different naming schemes for the same concept.

We need a way to be able to quickly form data shapes, without implementing anything about them. That’s an interface. It describes the shape of these objects.

What is an interface?

Historically, this was the main reason to use an interface. Classical object oriented programming languages, such as Java, and C#, also have interfaces that work similarly. This concept is similar to the protocols of Objective-C and Swift. But JavaScript is a dynamic language. The concept of interfaces has evolved to be another way of guarding variables with type annotations.

An interface describes the shape of an object structure.

An interface is like a set of instructions that describe the data and the behavior of an object. You can’t implement its methods; you can only describe their signature.

We can use interfaces as any other type annotation, to help TypeScript understand what is expected for a specific object variable. TypeScript will enforce a strict policy on that variable, to make sure that the instructions you set upfront are met. It will check the names of its properties, their types, and their restrictions. It will also check the names of the method functions, along with all their associated parameters and their return values.

An interface can also be used to define the shape of a class. In the previous article we saw that a class is a blueprint for an object. In a similar way, an interface acts as a blueprint for classes. Classes implement interfaces, which means they strictly adhere to the shape of them.

Creating & consuming interfaces

Let’s define an interface about a music track:

interface IsTrack {
  // required properties
  id: number | undefined
  title: string
  artist: string
  // optional properties
  releasedAt?: number
  genres?: string[]
}

The interface Track, defines the expected shape of these objects. That includes properties and their associated types. The properties releasedAt and genres are optional. No big surprises here compared to what we know about other types, right?

Now, imagine the following JSON structure, as an api response:

[
  {
    "id": 1,
    "title": "Bohemian Rhapsody",
    "artist": "Queen",
    "isFavorite": true
  },
  {
    "id": 2,
    "title": "Dream On",
    "artist": "Aerosmith",
    "isFavorite": true
  }
]

We can store this response using our newly defined interface:

const tracks: IsTrack[] = apiResponse

As you can see, we used an interface similar to how we would have used a type.

Interfaces can also contain function signatures:

interface IsTrack {
  id: number | undefined
  title: string
  artist: string
  releasedAt?: number
  genres?: string[]
  setFavorite(id: number, isFavorite: boolean): void}

By adding a setFavorite() method to our IsTrack interface, the previous response becomes incompatible. The consumers of this interface must implement these additional two functions to modify favorites.

As we’ve seen, interfaces become useful when multiple teams are working on the same project. A team may decide to name their properties differently. By creating interfaces and by storing them in a central place, you are avoiding this mess. You all know what a Track is and what it needs to deal with it. The other team can now develop their part, without having any working code from your side. They just depend on the interface you have provided.

You can export interfaces to make them available outside your project:

// track.ts
export interface Track {	id: number | undefined;
	title: string;
	...
}

This can become very useful when you are creating a shared library. Now, we can import this interface and use it:

// another.ts
import Track from './track';

function TrackList(tracks: Track[]) {
	...
}

Yeah, I know. I have an issue with the music tracks in this series. I am going through a phase. It will pass. I just need some time with myself.

Where can I use interfaces?

If you are wondering where and when to use interfaces in your projects, you are not the only one. This has bugged many JavaScript developers, including the author. You see, we never had to deal with classical OOP concepts.

TypeScript has added a lot of flexibility to its interfaces, to support the JavaScript language. In this section, we will review the most important use cases of using interfaces.

Using Interfaces to implement unrelated classes

So far, we have been using interfaces as types. But interfaces work great with classes. Mind the new keyword implements:

class Track implements IsPlayable {
  duration: number

  play(): void {}
}

I know what you are thinking. This class doesn’t implement our interface fully, and TypeScript will let us know about that. But that’s why we have the interface, right?

We can combine multiple interfaces to mix and match the functionality we want to inherit.

Consider the following interfaces:

interface IsTrack {
  id: number | undefined
  title: string
  artist: string
  // Optional properties
  releasedAt?: number
  genres?: string[]
}

interface IsPlayable {
  duration: number
  play(): void
}

interface IsFavorable {
  isFavorite: boolean
  toggleFavorite(): boolean
}

The IsTrack interface describes the shape of a track object. It’s similar to a model in MVC. The interface IsPlayable marks an object as playable, which means we expect these objects to have a duration and a play() method that we can call. Similarly, the interface IsFavorable describes classes that provide this functionality to get the favorite boolean and toggle its value using the toggleFavorite() method.

Now let’s put these interfaces together to create our Track class:

class Track implements IsTrack, IsFavorable, IsPlayable {
  id: number | undefined
  title: string
  artist: string
  isFavorite: boolean
  duration: number

  constructor(
    id: number,
    title: string,
    artist: string,
    isFavorite: boolean,
    duration: number
  ) {
    this.id = id
    this.title = title
    this.artist = artist
    this.isFavorite = isFavorite
    this.duration = duration
  }

  toggleFavorite(): boolean {
    const newValue = !this.isFavorite
    this.isFavorite = newValue
    return newValue
  }

  play() {
    console.log('playing...')
  }
}

In this example, we are combining all three interfaces. Try this example by yourself and notice the TypeScript errors as you add more functionality to your class. Also, notice how your editor provides better auto-completion, as you define the expected class members.

Using interfaces to define the shape of object structures

The nature of JS is open. Data comes from multiple sources. Maybe you are consuming the YouTube api and you want to deal with its response. Maybe the user clicks on a button, or types something in an input. Maybe you want to call a helper function and pass a collection of these entities.

You can create an interface next to your code to annotate this specific part of this interaction.

Consider the following example, where we want to fetch some music tracks using the fetch api:

let mixtape: IsTrack[] = []

fetch('http://example.com/tracks.json')
  .then((response) => response.json())
  .then((data) => (mixtape = data))

Here, we use the IsTrack interface we declared above, to annotate the type of the mixtape. We know this object pretty well, because it’s a part of our application’s business logic.

You also have the option to declare these interfaces next to your code, to deal with object structures that don’t align with your business logic. Handling user input is a good example here. Usually, we use event handlers to deal with all these use cases. And usually these events come with a payload. That’s a specific object structure. We can use an interface to describe the shape of this payload, so that we know what is expected.

In a similar way, you can use interfaces to define the expected structure of a function argument:

interface FormValues {
  username: string
  password: string
}

const formData: FormValues = {
  username: document.getElementById('usernameField').value,
  password: document.getElementById('passwordField').value,
}

postToServer(formData)

Here we have created an interface that contains a username and a password.

Naming Conventions

Interfaces in TypeScript can be used similar to any other type annotation. To avoid name conflicts, the community is used to add a prefix to all the interfaces.

There is no standard for the naming conventions by the language itself. So, TypeScript will not limit you from choosing any name for your interfaces. It is highly recommended, though, to decide on a naming convention and then use it in your project.

I have seen projects that use the letter I, for example ITrack. I have also seen projects with the words Is , With, or Has, for example, we can have IsTrack, WithId, or HasFileExtentions accordingly. I have seen projects that use a suffix -able, like Comparable or Searchable, to add some unique characteristics to their classes or objects in general.

I have seen projects that don’t use any specific naming convention. For example, if your codebase uses functional programming principles, you probably don’t use the class keyword that often. That leaves you with a flexible namespace, because now you don’t have to separate classes from interfaces.

I have also seen projects that use a combination of the naming conventions above.

In a perfect world, you agree with your team to use a specific name convention, and you follow it with all your heart.

Declaration Merging

The TypeScript implementation of interfaces differs from other programming languages. Declaration merging allows you to declare interfaces with the same name multiple times.

Here’s an illustration of this feature:

interface ITrack {
  id: string | undefined
}

interface ITrack {
  title: string
  artist: string
}

By declaring the same interface with different members, we are basically creating a bigger one:

interface ITrack {
  id: string | undefined
  title: string
  artist: string
}

TypeScript will merge the previous declarations into one single ITrack interface. Of course, it will complain in case you try to define the same member, with a different type.

This concept of interfaces sets them apart from type aliases, which must have unique names across your project:

In general, I would prefer interfaces over types, when it’s possible. Use type aliases when your objects could be undefined, or if they can act as a different type, like for example a string.

Cover Credit: Sebastian Svenson

Master Classes in TypeScript

Wed, 22 Dec 2021 22:12:00 GMT

Since the very early versions of TypeScript, the language provided support for the class keyword, together with some additional features, that you find in classic object-oriented languages.

In this article we will discover how TypeScript helps us create classes and how it transforms JavaScript into a more traditional OOP experience. I will explain how to add types and how to implement inheritance, enforce private and protected members, add accessors and abstract classes. We will then talk about the structural type system of TypeScript, which differs from the other flavors of OOP, you may probably be familiar with.

But first, let’s revisit what we’ve learned about classes and how JavaScript differs from it. This will help you have a better understanding of what’s going on.

Sundae? 🍧

Let’s talk about objects, first

There are multiple ways to create an object in JavaScript. Here’s the most convenient and common way:

const track = {
  title: 'Bohemian Rhapsody',
  artist: 'Queen',
  releasedAt: 1975,
}

Now, in contrast to other languages, nobody stops me from editing this object by adding or changing its properties:

track.timesPlayed: 22;

Nobody except TypeScript of course. Here’s the same example, after adding types:

type Track = {
	title: string;
  artist: string;
	releasedAt: string;
}

const track: Track = {
  title: 'Bohemian Rhapsody',
	artist: 'Queen',
  releasedAt: 1975 // Type error: not a string
};

track.timesPlayed: 22;  // Property 'timesPlayed' does not exist on type 'Track'

And here’s the error I will get when I try to set a value to a property that doesn’t exist:

Brilliant! Now we can relax because our objects will follow a structure. There are rules in the game. TypeScript acts again as a guard against typos or common mistakes.

Although, this adds a lot, we still have the problem of how to organize our code. You see, types are perfect for protecting us from errors, but they simply don’t exist at runtime. TypeScript will remove those types altogether, when it will compile our code to JavaScript.

We need a better tool to define object structures and their relationships.

Photo Credit: Debby Hudson

What is a class?

A class is a blueprint for an object.

Think of it as a higher-level data type, similar to how you use const or let.

const x

Similarly, you can use a class to create objects that have a specific structure:

MyClass myObject;

In this example we have a class MyClass and we instantiate the object myObject. Note that classes, by convention, start with a capital letter (PascalCase) but objects, like any other variable by convention, start with a small letter (camelCase).

Matt Weisfeld, in his book “The Object-Oriented Thought Process”, resembles a class as a cookie cutter. You take the cookie dough and you use the cookie cutter to make the cookies. That’s how you can use a class to instantiate objects.

Classes help us organize our code. Instead of having your code in a bunch of functions and variables, that are unrelated to each other, you can structure everything into a class.

In most programming languages, a class is used to create an object. It describes the contents of objects that belong to it. The data fields that it contains, and its operations. We call those properties and methods accordingly.

The ugly truth

As you may already know, there are no classes in JavaScript.

It is a prototype-based object oriented language. This basically means that any object in JavaScript inherits properties and methods from a prototype. This prototype could be another object, or one of the built-in objects.

This maximizes code reuse. Think of it like a traditional class inheritance, but without the necessity of defining everything upfront.

It’s easy to follow a prototype chain. Just try to get the prototype of a date variable:

const date = new Date()
Object.getPrototypeOf(date) // returns a reference to Date

Up until now, in JavaScript, you couldn’t define the relationships of the objects upfront using a class. You had to create objects that inherit from other objects. There was a need to have a more sophisticated way to create objects with a given structure. That’s why JavaScript developers were used to leverage plain functions to create objects. They worked exactly as constructors.

Take a moment to review the functional constructor below:

var Track = (function () {
  function Track(title, artist, releasedAt) {
    // set default values
    this.title = 'Untitled'
    this.artist = 'Unknown Artist'
    this.releasedAt = 'Unknown Release Date'

    // assign values passed via arguments
    this.title = title
    this.artist = artist
    this.releasedAt = releasedAt
  }
  return Track
})()

It’s quite an inconvenient way to write code, don’t you think?

Since ES6, we can simply use the class keyword to define classes:

class Track {
  title = 'Untitled'
  artist = 'Unknown Artist'
  releasedAt = 'Unknown Release Date'

  constructor(title, artist, releasedAt) {
    this.title = title
    this.artist = artist
    this.releasedAt = releasedAt
  }
}

This is just a syntactic sugar. In the background it still works exactly as before.

TypeScript to the rescue

TypeScript was one of the first languages that provided support for creating classes. Any valid JS class declaration is valid in TypeScript as well.

Depending on the compiler configuration, you have to define types for the class members.

Remember the previous example? Let’s add some types on it:

class Track {
  title: string = 'Untitled'  artist: string = 'Unknown Artist'  releasedAt: string = 'Unknown Release Date'
  constructor(title: string, artist: string, releasedAt: string) {    this.title = title
    this.artist = artist
    this.releasedAt = releasedAt
  }
}

Here’s how we can create an object from our class, by consuming its constructor:

const track = new Track('Bohemian Rhapsody', 'Queen', 1975)

As you may have noticed, we don’t explicitly specify a type for the track object. TypeScript will automatically set that this is an instance of Track. There is a way to explicitly define the type, though:

const track: Track = new Track('Bohemian Rhapsody', 'Queen', 1975)

Many developers prefer this way, because it’s much more readable. If you use a function that returns an object, for example, you will miss the information in your head what kind of object our track was. It’s a detail, I know. But it helps a lot!

Now, let’s try to add a new property that doesn’t exist in the class definition:

const track: Track = {
  title: 'Bohemian Rhapsody',
  artist: 'Queen',
  releasedAt: '1975',
  newProp: 'with a value',}

Yes, my friends, you guessed it correctly. We will get an error:

In JavaScript, when a variable doesn’t have a value, it’s undefined. The same applies for our class properties. We could leverage the usage of unions to allow undefined values:

class Track {
  id: string | undefined  title: string = ''
  artist: string = ''
  releasedAt: string = ''

  constructor(id: string, title: string, artist: string, releasedAt: string) {    this.id = id    this.title = title
    this.artist = artist
    this.releasedAt = releasedAt
  }
}

We could also have optional properties with the ? character:

class Track {
  id: string | undefined
  title: string = ''
  artist: string = ''
  releasedAt: string = ''
  isFavorite?: boolean

  constructor(
    id: string,
    title: string,
    artist: string,
    releasedAt: string,
    isFavorite?: string
  ) {
    this.id = id
    this.title = title
    this.artist = artist
    this.releasedAt = releasedAt
    this.isFavorite = isFavorite
  }
}

Here, the isFavorite flag can be completely omitted when we are instantiating object from this class. Basically, this means its value will be undefined.

Photo Credit: Eugenia Kozyr

Structural type system

This is one of the most difficult concepts of TypeScript, for people who are not familiar with JavaScript. It’s the way the language checks the compatibility of the types.

Here’s a simplified version of what is possible in TypeScript:

const track: Track = {
  title: 'Bohemian Rhapsody',
  artist: 'Queen',
  releasedAt: '1975',
}

Here, we’re basically bypassing the constructor altogether. We are creating an object, using an object literal, and then we’re passing this object to a track variable. TypeScript will compare the shape of this object with the shape of the class Track. If there are no type violations in its methods, no errors will be thrown.

Now let’s see a different example:

class Dog {
  name: string = 'Nobody'
}
class Cat {
  name: string = 'Nobody'
}
const cat = new Cat()
const dog = new Dog()
const animal: Dog = cat

Here these two objects originate from completely different classes. We have a Cat and a Dog. But observe what is happening if I assign a cat to a dog. No errors whatsoever.

Somebody will argue how good this approach really is. TypeScript has to be more flexible here, because JavaScript doesn’t have types. And strategically speaking, backwards compatibility is really crucial. That’s why they had to use a concept called duck typing. Duck typing in computer programming is an application of the duck test:

“If it walks like a duck and it quacks like a duck, then it must be a duck”

In the example above, both these objects have a name property, which is of course public. That makes them practically compatible.

Inheritance

In the following example, I’m declaring a Playable class, and I’m using it to create three additional classes that derive from it:

Here is how we can implement it in TypeScript:

class Playable {
  title: string
  duration: number

  constructor(newTitle: string, newDuration: number) {
    this.title = newTitle
    this.duration = newDuration
  }

  play() {
    console.log(`Playing "${this.title}"...`)
  }
}

class MusicTrack extends Playable {
  artist: string

  constructor(newTitle: string, newDuration: number, newArtist: string) {
    super(newTitle, newDuration)
    this.artist = newArtist
  }
}

class Podcast extends Playable {
  producer: string

  constructor(newTitle: string, newDuration: number, newProducer: string) {
    super(newTitle, newDuration)
    this.producer = newProducer
  }
}

class Movie extends Playable {
  director: string

  constructor(newTitle: string, newDuration: number, newDirector: string) {
    super(newTitle, newDuration)
    this.director = newDirector
  }
}

Note that I’m using the extends keyword, which is another feature of JavaScript.

I can then instantiate a Movie object:

const myMovie = new Movie('The Godfather', 175, 'Francis Ford Coppola')
myMovie.play() // Playing "The Godfather"...

Now, let’s try to override the play() method of the class Movie:

class Movie extends Playable {
  director: string

  constructor(newTitle: string, newDuration: number, newDirector: string) {
    // calls the constructor of the parent class
    super(newTitle, newDuration)
    this.director = newDirector
  }

  play() {    console.log(`Playing "${this.title}" by "${this.director}"...`)  }}

And, as expected, when we call the play() method, the message that we get is different:

const myMovie = new Movie('The Godfather', 175, 'Francis Ford Coppola')
myMovie.play() // Playing "The Godfather" by "Francis Ford Coppola"...

Private & protected methods

Class properties and methods are kinda useless without specifying their privacy. In the previous example, I can directly change the values of the properties or call the play() method, from anywhere in my code:

myMovie.title = 'broken title'
myMovie.play() // Playing "broken title" by "Francis Ford Coppola"...

In a real-world application, you wouldn’t allow anyone to access our class members directly. In fact, this privacy is one of the key benefits of OOP.

An improved version of our previous design can be the following. Our ultimate goal is to protect the properties:

TypeScript adds better support for private methods. It’s important to remember that the following keywords are only available during compilation, and they aren’t available at runtime. Nothing protects you from accessing their values. If you really need that protection, ECMAScript 2015 has support for private properties or methods. But I would say its syntax is quite weird. So use it only in rare cases, when it’s really important to protect your objects.

By default, all class members are public. You can omit the public keyword. Here’s what we’ve meant in the previous example, when we were declaring the class Playable:

class Playable {
  public title: string
  public duration: number

  constructor(newTitle: string, newDuration: number) {
    this.title = newTitle
    this.duration = newDuration
  }

  public play() {
    console.log(`Playing "${this.title}"...`)
  }
}

To restrict access to our properties, we can use the private keyword:

class Playable {
  private title: string  private duration: number
  constructor(newTitle: string, newDuration: number) {
    this.title = newTitle
    this.duration = newDuration
  }

  play() {
    console.log(`Playing "${this.title}"...`)
  }
}

An attempt to change the title will fail:

myMovie.title = 'broken title'  // Error: Property title is private and only accessible within class Playable

That’s very convenient and secure. As a side effect, we can’t even access or change this property from within the derived classes. You will notice that now our Movie class, has a very interesting error:

We can use the protected keyword, to allow accessing class properties, or methods, from derived classes:

class Playable {
  protected title: string;
  protected duration: number;

	...
}

A constructor can also be marked as protected. This means that the class cannot be instantiated outside its containing class, but can be extended.

For example, if we set our constructor to protected:

class Playable {
  protected title: string;  protected duration: number;
  protected constructor(newTitle: string, newDuration: number) {    this.title = newTitle;
    this.duration = newDuration;
  }

  ...
}

const playableTrack = new Playable();  // throws an error

Which doesn’t allow me to access:

It won’t be possible to instantiate new objects from the Playable class:

We can use the readonly keyword to define properties that behave as constants:

class Playable {
  protected readonly title: string;  protected readonly duration: number;	...
}

Properties that are marked as readonly, cannot change, even within derived classes:

class Movie extends Playable {
  director: string;

  constructor(newTitle: string, newDuration: number, newDirector: string) {
    super(newTitle, newDuration);
    this.director = newDirector;
    this.title = '';  // cannot assign to title because it is a read-only property  }

	...
}

Accessors

We can use setters and getters in combination with our private properties:

class Playable {
  private _title: string
  private _duration: number

  get duration(): number {    return this._duration  }  set duration(newDuration: number) {    if (newDuration && newDuration < 0) {      throw new Error('Duration cannot be negative')    }    this._duration = newDuration  }
  constructor(newTitle: string, newDuration: number) {
    this._title = newTitle
    this._duration = newDuration
  }

  play() {
    console.log(`Playing "${this._title}"...`)
  }
}

Here, I’m using an underscore _ as a prefix to differentiate the private properties. It’s a common naming convention.

These accessor functions can have their own logic. For example, we check for negative duration values.

Here’s how we use them:

const playableTrack = new Playable('something', 111)
playableTrack.duration = -1 // throws an error, Duration cannot be negative

Accessors with a get and no set are automatically inferred to be readonly.

Guarding methods with types

Now let’s try to write our custom method:

class Playable {
  private _title: string
  private _duration: number

  get duration(): number {
    return this._duration
  }

  set duration(newDuration: number) {
    if (newDuration && newDuration < 0) {
      throw new Error('Duration cannot be negative')
    }

    this._duration = newDuration
  }

  constructor(newTitle: string, newDuration: number) {
    this._title = newTitle
    this._duration = newDuration
  }

  play() {
    console.log(`Playing "${this._title}"...`)
  }

  getDurationTime(): string {    const hours: number = Math.floor(this._duration / 60)    const minutes: number = this._duration % 60    return `${hours}:${minutes}`  }}

Everything that applies to functions can be used for defining methods in classes.

const playableTrack = new Playable('something', 111)
console.log(playableTrack.getDurationTime()) // 1:51

I don’t know if you agree with me, but this hardcoded 60 value looks kinda odd to me. We can refactor it using the static keyword:

class Playable {
  static minutesPerHour: number = 60;  private _title: string;
  private _duration: number;

	...

  getDurationTime(): string {
    const hours: number = Math.floor(this._duration / Playable.minutesPerHour);    const minutes: number = this._duration % Playable.minutesPerHour;
    return `${hours}:${minutes}`;
  }
}

Ah much better! I feel like I’m writing C# now.

Abstract classes

TypeScript adds support for abstract classes:

abstract class Playable {
  protected _title: string
  protected _duration: number

  constructor(newTitle: string, newDuration: number) {
    this._title = newTitle
    this._duration = newDuration
  }

  abstract play(): void // must be implemented in derived classes
}

For starters, we cannot instantiate objects from an abstract class:

Abstract classes allow us to define abstract methods. These are methods that don’t have any implementation, but we expect from the derived classes to implement them. We only define the signatures of those abstract methods. TypeScript will make sure they are followed by the book.

To illustrate this in practice, consider the following derived class:

class Podcast extends Playable {
  producer: string

  constructor(newTitle: string, newDuration: number, newProducer: string) {
    super(newTitle, newDuration)
    this.producer = newProducer
  }
}

In the previous example, we extend the class Playable, to create a Podcast class. Note that if we fail to implement all its methods, we will get a very informative compilation error:

Now let’s fix this, by implementing the play() method:

class Podcast extends Playable {
  producer: string

  constructor(newTitle: string, newDuration: number, newProducer: string) {
    super(newTitle, newDuration)
    this.producer = newProducer
  }

  play() {
    console.log(`Playing "${this._title}"...`)
  }
}

We can use our Podcast class to create podcasts:

const myPodcast: Podcast = new Podcast(  'A podcast title',
  90,
  'Nicos Tsourektsidis'
)
playable.play()
playable.sharePodcast()

And here’s where the magic begins. We can use the type of the abstract class Playable to indicate that our variable can host any object from classes that derive from Playable:

const playable: Playable = new Podcast(  'A podcast title',
  90,
  'Nicos Tsourektsidis'
)
playable.play() // This is defined in the abstract class, it will work
playable.sharePodcast() // This method will not work, it's not defined

And now we have access to all the methods and properties that exist in the Playable class. This allows us to perform high-level actions on a variety of objects that have completely different implementations.

If we try to access a method or a property that’s not defined in the parent abstract class, this will throw an error:

Cover Credit: Nataliya Smirnova

Master Functions in Typescript

Thu, 16 Dec 2021 22:12:00 GMT

JavaScript has some powerful features for functional programming. At least a light version of it.

In this article, we will discover what options JS provides for declaring and consuming functions and we find out how to guard them with TypeScript types.

This article belongs to my series Too Long To Read TypeScript. Every article covers in detail a core concept of the language.

Cake? 🍰

The different ways to declare a function

You’re probably familiar with the simple function declaration, which uses the function keyword:

function add(a, b) {
  return a + b
}

The variables a and b are called parameters, when the signature of the function is concerned. Within the function itself they are known as arguments.

Another way, is to assign a function to a variable, or to an object property. This is called a function expression:

const fn = add
fn(1, 3) // returns 4

You can pass functions as arguments in other functions, which are also known as callbacks:

function annoyUsers() {
	alert('Subscribe to my channel!').
}

setTimeout(annoyUsers, 1000);

In the previous example, we passed annoyUsers to setTimeout() as a callback. This function will be called after a delay of 1 second. This unlocks the potential of asynchronous code, but it can also increase complexity, something that is known as callback hell.

Another way you can create a function is on the fly:

setTimeout(function() {
  alert('Subscribe to my channel!').
}, 1000);

These functions don’t have a name, and thus we call them anonymous function expressions.

Ah, yes! Consider adding names to your functions as much as you can. It helps with easier debugging. It also enables recursion, since there is no way for anonymous functions to refer to themselves.

Adding type annotations with TypeScript

TypeScript supports all the existing features of JavaScript functions, and of course, we have the option to define types. As with all the other typed elements of TypeScript, type annotations live into your code, and they will be removed after transpilation, which means they will not be available at runtime.

We can define a type for the arguments and the return value. Consider the following function:

type Track = {
  title: string;
  releasedAt: number;
  gernes: string[];
  isFavorite: boolean;
}

function getTrackTitles(tracks: Track[]): string[] {  return 2; // Type error, the return value must be an array of strings
}

In this example, the function getTrackTitles() accepts an array of Tracks, and as a return value an array of strings. In case we have a different return value, the compilation will fail:

Optional parameters

We can define optional parameters:

type Track = {
  title: string
  artist: string
  isFavorite?: boolean}

function createTrack(
  title: string,
  artist: string,
  isFavorite?: boolean): Track {
  return {
    title,
    artist,
    isFavorite,
  }
}

Here the argument isFavorite is optional. We can call the function with or without this parameter.

Optional parameters cannot be set for arguments when they have a default value:

// this will not work
function createTrack(
  title: string,
  artist: string,
  isFavorite?: boolean = false): Track {
  return {
    title,
    artist,
    isFavorite,
  }
}

Here, the function parameter isFavorite is optional, but it also has a default value of false. This is logically impossible, but don’t worry, TypeScript will prevent it:

Required arguments cannot follow optional ones:

function createTrack(
  title?: string, // optional arguments cannot lead  artist: string, // required arguments
  isFavorite?: boolean
): Track {
  return {
    title,
    artist,
    isFavorite,
  }
}

Here, we define the title argument as optional, but the next argument artist is mandatory. This will create a messy function invocation, because usually the optional arguments are last in the list. Of course, once again, TypeScript will prevent this:

Default values

In the latest versions of JavaScript, we have the option to define default function parameters, which will allow name parameters to be initialized with default values, if no value or undefined is passed:

function add(a, b) {
  return a + b;
}
add(); // returns NaN, when no value is passed

function addWithDefaultValues(a = 0, b = 0) {  return a + b;
}
addWithDefaultValues(); // returns 0 when no arguments passed

In this example, the argument will get the default value if no value is passed.

Now let’s see how type definition can work together with default values:

function add(a: number = 0, b: number = 0): number {
  return a + b;

void

If a function doesn’t return anything, we can use the type void:

function annoyUsers(): void {  alert('Subscribe to my channel!').
}

It is recommended to always provide a return value to your functions.

Arrow functions

Another way to create an anonymous function is to use an arrow function:

const multiplyBy2 = (number) => {
  return number * 2
}

[1, 2, 3, 4].map(multiplyBy2)

As you can see the syntax is simpler and they end up taking much less space. But you can make it even shorter. Here are all the acceptable forms of arrow functions:

// Without arguments
const sayHello = () => {
  return alert('hello')
}

// With only one argument
const sayHello = (name) => {
  return alert(`hello ${name}`)
}

// Without return value
const sayHello = (name) => alert(`hello ${name}`)

// Returning an object
const makeObject = (name) => ({ name })

Adding types to arrow functions

And here’s how we can define types for our arrow functions:

const add = (a: number, b: number): number => a + b

Type annotations can also take the form of an arrow function, to indicate the signature of a function, with the given types for parameters and the return value. This works great with callbacks:

function calculate(values: number[], fn: (a: number, b: number) => number) {  values.reduce((previous, current) => fn(previous, current), 0);
}

calculate([1, 2, 3, 4], add);

This is a function that calculates a given array of numbers, by using the provided callback. Note that we specified the expected types for this callback. This will prevent consumers to do something like this:

function randomFn() {
  return "no clue what I'm doing"
}

calculate([1, 2, 3, 4], randomFn) // type error, that's not my type of fn

Here, randomFn() doesn’t accept 2 numbers as arguments and it doesn’t return a number. Therefore, this will not compile:

Arrow functions vs regular functions

Arrow functions are widely used in modern applications. There are some fundamental changes with the regular functions. You must remember that it’s not only about the syntax. I will try to list them here briefly, but I do recommend you spend some time studying these differences, if you are not familiar with them. Here we go:

They are always anonymous, which as we saw before, it may cost you time on debugging.
Arrow functions don’t alter the value of lexical this. The value of this inside an arrow function is the closest parent regular function.
Arrow functions don’t have a binding on arguments, which means that the arguments special variable will not be recognized if you try to access it within an arrow function.
They can’t act as a constructor. This means that you can’t call them with the keyword new, as you can normally do with regular functions, to create new object instances.
In JS you are allowed to use the same argument multiple times, like add(x, x), if you use a regular function. This will not work on strict mode. Duplicate arguments aren’t allowed for arrow functions, even on non-strict mode.

Hoisting

JavaScript has a feature called hoisting. This allows us to use functions or variables before their actual declaration.

Check the example below. It will compile successfully in JS, and the function declarations will be automatically moved to the top of your file.

add(2, 3) // returns 5

function add(a, b) {
  return a + b
}

Hoisting was very useful back in the days where scripts were randomly referenced within a HTML document, by making the scripting language easier to use. Nowadays, hoisting is yet another weird feature of JavaScript, you should be familiar with. Thankfully, there is a way to protect yourself from unwanted behavior.

Arrow functions are not hoisted, similar to any other declaration that uses the const and let keywords:

add(2, 3) // we will get an error that the function is not declared yet

const add = (a, b) => a + b

Function overloading

Many languages, like C#, or Java, allow multiple implementations of the same function, as long as their argument lists, or their types, are different. JavaScript doesn’t have this behavior, since function arguments are what make the actual functions.

TypeScript adds support for function overloading. This allows you to have multiple functions with the same name within the same scope, but with a different set of arguments.

The syntax differs from what you are used to seeing in other languages. At first, you need to define the overload signatures, which are function declarations without a body, and then to provide a function with the implementation:

// overload signatures
function search(title: string)
function search(id: number)
// actual implementation
function search(nameOrId: string | number) {
  if (typeof nameOrId === 'number') {
    console.log('searching by id')
  }
  if (typeof nameOrId === 'string') {
    console.log('searching by name')
  }
}

In this example the function search() can accept either a string, to search by name, or a number to search by id. The first two functions define the multiple ways you can call this function; that’s why we omit their bodies. The third function is the actual implementation. We have a single argument nameOrId which can be a string or a number.

It is worth mentioning here that this syntax will not work in JS, because you can only have one definition for the search() function.

From now on, the moment you start typing the name of the function you will get a useful popup with the different ways you can implement it:

Advanced types

Are you ready for more? In this section I am listing some additional types that may become useful when you deal with functions. If you already build JS applications, it will be good to know their existence. They are used rarely, though. Feel free to skip this part if you are just starting out with TypeScript.

object

We discovered in a previous article the available types of JS. There, we also talked about primitive and reference types.

If you are sure that a function always returns an object, but it can be a different object structure, you can use the special type object:

function makeObject(str: string): object {  return { str };
}

Now, I’m not advocating for using this specific type, because it is quite similar to any. It can be useful when you are writing utility functions, which are meant to be shared across all your projects. Make sure that you have some type declaration in the parent functions, the ones that act as consumers, to avoid any mistakes in your code.

Now, remember that object is not the same as Object with a capital O. The later one is a reserved JS keyword and it refers to the actual global object type. Never use it, simply ignore its existence.

unknown

Another useful type for our functions is unknown. It works as a wildcard, similar to any, but it is safer. It basically prevents us from writing risky code.

Here’s a simple example that illustrates the difference between any and unknown:

// using any
function play(file: any) {
  file.play() // works fine
}

// using unknown
function play(file: unknown) {
  file.play() // nope, name may not be
}

In the previous example, we have a function that accepts a file, which may or may not have the method play(). In case we use any, TypeScript will not complain at all. But if we use unknown, we will get the following error:

With the unknown keyword we can also guard our arguments:

class ServerErrorResponse {
  title: string
}

function parseErrorResponse(response: unknown): string {  if (response instanceof ServerErrorResponse) {
    return response.title
  }

  if (typeof response === 'string') {
    return response
  }
}

In this example, the function parseErrorResponse() checks if the response is a string or an object. Since we are not sure about the server response, we have to write some extra logic, to make sure we get the value correctly. Because we used unknown as a type for our response, TypeScript will expect us to check the type of the value first, before we interact with it.

The same example will not work if we don’t explicitly check if response is an instance of ServerErrorResponse.

Function

For the same purposes, TypeScript also provides a special keyword Function which is another wildcard for functions:

function calculate(values: number[], fn: Function) {  values.reduce((previous, current) => fn(previous, current), 0)
}

It is considered a good practice not to use the Function keyword over the technique we’ve learned in the previous sections, which uses an arrow function syntax to describe the signature of the function. It may be useful, when you are accepting multiple function signatures.

Also, this can be confused with the function keyword that JS provides. Remember, the type is using a capital F.

never

Finally, in cases when we know that a function never returns a value, we can use the never type:

function throwError(message: string): never {  throw new Error(message)
}

Cover Image Credit: Rodion Kutsaev

Types Of TypeScript

Wed, 08 Dec 2021 22:12:00 GMT

Does JavaScript have types? Keep reading. The answer may surprise you.

In programming languages, a type system is a logical system comprising a set of rules that assigns a property called a type to the various constructs of a computer program, such as variables, expressions, functions or modules.

But you are not here for definitions, are you?

This article belongs to my series Too Long To Read TypeScript. Every article covers in detail a core concept of the language.

In this Types Special, we will discover how JavaScript deals with types and how you can make your life simpler with TypeScript. I believe a strong JS foundation is important to fully understand TypeScript. That’s why I will start from the very basics.

We will then review the built-in types of TypeScript, together with some special keywords that may become really useful in your daily coding. I will introduce you to unions, which let you make your own type combinations. Finally, we will discover how type aliases can be used to build custom types.

Donut? 🍩

Types in JS

Run the following code in your console, line by line. Spoiler alert in the comments.

'Hello' // it works, returns undefined
2021 + 1 // it works, returns 2022
[1, 2, 3].length // it works, returns 3

You will notice that JS doesn’t complain at all. A value is an acceptable expression for JavaScript.

Now, let’s try the following example:

let year = 2020
year = '2021'
year * 2 // it returns 4042 as a string!
year = 'two thousand twenty one'
year * 2 // it returns NaN

Interesting finding; There were no errors, whatsoever, when we tried to change the type of a variable. This proves that variables in JavaScript don’t have types. I can assign anything that I want to any variable that I want.

In JavaScript, variables don’t have types; their values have.

A type of a value can be undefined, null, number, string, and boolean. ES6 supports a new type called Symbol. We call these primitive types.

Every other variable is an object, including array, regular expressions and Date. These are reference types.

In the following example, we assign a string value to the variable artist:

var artist = 'Pink Floyd' // we assigned a string value to artist

Primitive types are immutable, which means you cannot alter their values directly; they create a new instance every time they change. Immutable values can be compared:

var artist = ' Pink floyd '
var artistWithoutSpaces = artist.trim()
console.log(artist) // ' Pink floyd '
console.log(artistWithoutSpaces) // 'Pink floyd'
console.log(artist === artistWithoutSpaces) // false

Reference types are mutable. Which means, when you compare them, you compare their references not their actual values:

var track = { artist: 'Pink Floyd' }
var trackWithoutSpaces = track
trackWithoutSpaces.artist.trim()
console.log(track === trackWithoutSpaces) // it's true!

You can declare global variables if you omit the ****var keyword. This also mirrors its value in the global environment object:

noDeclarationWhatsoever = 'and it works'

Now let’s try a weird operation:

'1' + 2 // returns 12

Another interesting finding; Again, we don’t see an error. Instead, JavaScript automatically coerces their values, which will allow you to compare apples with oranges if you want to. A string wins over a number, that’s why the result is a string. That means there is a predefined priority.

Now, just for fun, try the following:

typeof NaN // it returns 'number'

What a total disappointment. It turns out that NaN has actually the type of a number.

Nobody can trust such a language, right? And yet millions of applications are using it. There’s a high chance that the application you are using to read this article is also made with JS. That’s not because its developers had an alternative and instead decided to make their lives difficult. JavaScript is [almost] the only option on the web. It just works. Everywhere.

Don’t forget, JavaScript was discovered back when downloading a song was slower than visiting a store to purchase the physical CD album.

If we could somehow improve it. But wait, we already know such a tool. It’s called…

Types in TypeScript

Everything in TypeScript just simply makes sense:

let year = 2020
year = '2021' // it doesn't compile; you cannot assign a string to a number. Why on earth you want to do this? Now go back and fix that broken code. Thankfully AI will replace you humans and we will not be annoyed by you anymore...

Thankfully, no surprises here. TypeScript will protect us from such mistakes. It’s not a warning that we can forget about it; it’s a compilation error. It completely prevents us from running our application.

We can see errors while writing code. Text editors that are compatible with TypeScript, like Visual Studio Code, will simply indicate the error, as we type:

Notice that if you hover over the year variable, TypeScript already understands it’s a number. This is called type inference. Sometimes it can be redundant to declare the types for your variables, since they are implicitly defined by their declaration.

This way of defining types is called right-hand typing, which refers to the right side of the equals sign (=). This probably is more familiar to you if you are a JavaScript developer.

But there is another way to define types, which is called, as you can guess, left-hand typing. This is the TypeScript way and we will get into it in the next section.

Built-in Types

To help TypeScript better understand how your code is interconnected, it provides type annotations that can live within our code.

Here are the most important built-in types, you will most probably use on a daily basis:

let title: string = 'Bohemian Rhapsody'
let releasedAt: number = 1975
let gernes: string[] = ['Rock', 'Hard rock', 'Progressive rock']
let isFavorite: boolean = true

Here are some special ones:

let error: undefined // similar to JS
let loading: null // similar to JS
function init(): void {} // This function should not return any value

An important thing to remember, these type annotations are only available in the TypeScript compiler, and they never make it to the actual production code. This means, they are available at compile time and not at runtime. That’s how all strongly-typed languages work.

Now let’s review two more important types.

any

What if we want to go back to where we came from? What if we have legacy code, that doesn’t respect types at all? Do we need to re-write everything or is there a way to temporarily disable type checking?

Yes, my friends. There is. And it’s called any:

let year: any = 2020
year = '2021' // it perfectly compiles without issues.

Now you may be wondering, is this even legal? That’s the reason we added TypeScript from the very beginning, right? Because of its type annotations. I mean, it is even called type-script. If we have to use any, then what’s the point of having TypeScript at all?

Well, my friends, you are right one more time. The usage of any is not encouraged. Avoid it whenever you can.

When you use any in your type annotations, you simply skip the type annotations. You are basically saying “I hate TypeScript and I don’t want to deal with it. You deal with it!“.

There are some cases that any becomes useful, though. I use it a lot when I want to try an idea quickly, let’s say to log something on the console, just to debug my code. So none of my colleagues knows that I’m actually using any in our project.

Any is like a wildcard. Use it, but with caution.

An alternative to any is the special comment @ts-ignore:

let year: any = 2020
// @ts-ignore
year = '2021'

This disables the type system for this specific line or file. It’s mostly preferred when you want to hack your type system on purpose. You can then search and replace all its instances.

There is a better way to deal with unexpected values in TypeScript. The keyword unknown, which we will analyze in the next section. The ultimate way is to use Generics. We will cover them in a separate post.

unknown

The unknown keyword works similarly to any:

let duration: unknown
duration = 354 // it works
duration = '5.54m' // it works

The difference is that TypeScript doesn’t let you assign values of other types to a variable that is of an unknown type:

let duration: unknown
let durationInMinutes: string
duration = '5.54m'
durationInMinutes = duration // Compilation Error

By running the previous example, we will get an error that unknown is not assignable to type string:

To fully understand the value of the unknown keyword, consider the following example:

let result: unknown
result.trim() // Compilation Error

Since we don’t know if the result will a string, we can’t be sure it implements the trim() method. TypeScript again will guard this variable and it will not let us do some inappropriate action with it (sic):

To bypass this error, we can add some logic that narrows down the unknown result value. We can simply check if it’s a string. TypeScript will recognize our efforts to make our code more robust.

Embrace the unknown.

Unions

Sometimes you know that a variable accepts different types. For example, you have a value that can be undefined if it’s not set, or you have a boolean that can become a number. Another example is the response that you get from the server.

TypeScript provides a solution to standardize such scenarios. It is called a union and the syntax is the following:

let id: string | undefined

In this example, the id variable can act as a string or undefined.

Enumerations

Similar to other languages that support enums, we can define our own enum, and then use it:

enum Filetypes {
  Mp3,
  Mp4,
  Wav,
}

const fileType = Filetypes.Mp3

By using such an enum, we avoid typos that can slow us down, for example, if we use a capital letter or not. We also allow the text editor to provide auto-completion, which speeds up our development even more. Who doesn’t like to press Enter all the time?

Enums act like Symbols in ES6. But it’s better, because we can control the real values. There are some important rules to remember.

Enum values

TypeScript assigns values to your enum properties, but you can customize them if you want to.

By default, values start counting from 0:

enum Filetypes {
  Mp3, // 0
  Mp4, // 1
  Wav, // 2
}

We can set custom values if we want to:

enum Filetypes {
	Mp3: 'mp3',
	Mp4: 'mp4',
	Wav: 'wav'
}

You can use a string or a number as a value, but you can’t use a boolean.

TypeScript compares their actual values:

enum Filetypes {
  Mp3 = 20,
  Wav = 2,
}

Filetypes.Mp3 < Filetypes.Wav // returns false

Transpilation behavior

Now, here’s a pro tip. Let’s revert our enum back to how it was:

enum Filetypes {
  Mp3,
  Mp4,
  Wav,
}

This will be the equivalent code in JS:

;(function (Filetypes) {
  Filetypes[(Filetypes['Mp3'] = 20)] = 'Mp3'
  Filetypes['Mp4'] = 'a'
  Filetypes[(Filetypes['Wav'] = 2)] = 'Wav'
})(Filetypes || (Filetypes = {}))

You may think this is too much for such a simple code. But there is a way to bypass it if you add the keyword const:

const enum Filetypes {
  Mp3,
  Mp4,
  Wav,
}

Now the enum value disappears from the JS file, but its value will be simply assigned wherever you use it. It’s a nice way to completely disable enums from the generated code.

Type Aliases

TypeScript provides a nice feature called type aliases, and it works like this:

type Track = {
  title: string
  releasedAt: number
  gernes: string[]
  isFavorite: boolean
}

It is useful to reuse complex type definitions across your application. It is also useful, when you want to separate the type declaration code, from the actual implementation, just to keep your code more readable.

Here is how we can use it to guard object structures:

const myTrack: Track = {
  title: 'Bohemian Rhapsody',
  releasedAt: 1975,
  gernes: ['Rock', 'Hard rock', 'Progressive rock'],
  isFavorite: true,
}

As with all types, these aliases only affect compilation time, and it will not make it at runtime.

Don’t be confused. That’s not the only way you can describe the structure of an object. I will cover the class keyword in a separate post. I will also cover the interface keyword, which is by far the most preferred way.

The good thing about type aliases is that you can use unions in them:

type ServerResponse = undefined | null | string | Track

With this in mind, we can reduce the usage of any in our code, when it’s possible.

The even better thing is that you cannot modify a type alias after its creation. This eliminates duplicates, which can be caused by different parts in your code.

Cover Credit: Rodion Kutsaev

TLTR; TypeScript

Wed, 01 Dec 2021 22:12:00 GMT

TypeScript adds support for strongly typed programming in your JavaScript applications. It’s tightly integrated with your text editor, to help you catch any errors early.

TypeScript is a superset of JavaScript. All existing features of JS are already supported, but it adds syntax, which helps you build much more structured applications.

TypeScript’s compiler transpiles to JavaScript. This means that you can run all the applications on every browser, on Node.js or other native apps that have a built-in JavaScript compiler. You have plenty of options to set the target supported devices.

You can adopt TypeScript gradually into your existing projects. You can also use it to catch JavaScript errors in your continuous integration pipelines. In fact, Visual Studio Code has TypeScript built-in, to help you find errors without any configuration from your side.

By introducing types to your code, your editor can understand much better how the different parts of your application are interconnected. Therefore, it can provide you with sophisticated auto-completion suggestions that can speed up your development.

TypeScript has full support for JSDoc. Moreover, you can use comments within your code to create live documentation.

Type checking runs on compile-time. If you violate the type rules, your application will not run due to errors. All the extra code that you add will be removed from the transpiled JS code and it will not be available at runtime.

Introduction

I have to confess something to you, my friends.

My first experience with TypeScript wasn’t really satisfactory. You see, I’ve been using JS for many years and I had to get familiar with its bad and good parts. It wasn’t easy and I did suffer a lot. But after some point you learn how to use the language properly. I was pretty much trusting my development skills.

I was wrong.

First off, when I integrated TypeScript into my projects, I uncovered a lot of type mistakes, that could potentially cause bugs. Sometimes, it’s hard to think about everything and to remember what you were doing a year ago, for example.

I wasn’t only proud of myself. I was also proud of my team. You see, I was convinced everybody in my team understands JavaScript. We had code reviews, we were constantly learning. What could go wrong, right?

I was wrong again.

In every development project, a team is a living organism. It scales up and down. You should not take for granted the level of expertise you have at any moment. You have to think proactively. Maybe some juniors will join the project. Maybe you will need to invest in less experienced developers, because you can’t find any. And what if you had 10 or 50 developers? What if you had more?

That’s the lesson that I’ve learned. Having a strongly typed language reduces time for everyone. And this time grows exponentially as you add more people to the project.

Photo Credit: Carl Raw

TypeScript isn’t free. You need to invest time navigating its learning gap. It’s a mind shift compared to traditional JS development. Like every other tool, you need to carefully integrate it into your projects without making your team suffer every time they try to innovate.

One of the things I didn’t like about TypeScript, was the fact that I’m not writing JS anymore. I wasn’t convinced this was a game changer for the industry. I’ve seen similar libraries become obsolete and I’ve seen developers struggling with refactoring their code. In the JavaScript ecosystem, trends come and go.

Back then, JavaScript was evolving rapidly. Don’t get me wrong, it still does. But since ES6 there was a huge effort to improve the language. New features were being added. Something inside me was refusing to make the switch to another language.

The fear of missing out.

Many things have changed since then. TypeScript changed. It’s now aiming to support standards, instead of introducing new features that are completely irrelevant to the JavaScript language itself. It’s also backwards compatible, which lets you run pretty much every code written in JS, even the dirtiest ones.

Now you may be wondering, how can you learn a language that has two faces? How can you integrate it into your projects? How far do you need to go with the type restrictions? What different options do you have to structure your code right and which one you should use?

Understanding TypeScript takes time. And I would like to help. I’m introducing a series of posts that will help you scale your applications with confidence. A series that focuses on the most important parts and tries to give you practical ideas and examples that are already used in production applications.

In this introductory article, we will try to understand how TypeScript works, what it brings to your development process, and how to start new TS projects.

I hope the following paragraphs will help you have a better understanding of TypeScript and to know exactly what it needs to get started.

Any feedback will be considered sweet.

Panna cotta? 🍮

How TypeScript was born?

I love JavaScript. It runs anywhere, it doesn’t limit you from coding anything you want, and the development community is amazing. So many projects and patterns to try and a huge variety of applications to build.

It didn’t create a good first impression on me, though. When I first started writing scripts in JavaScript, I really hated the language. You see, JavaScript hides a set of weird quirks, that can cost you a lot of time, if you are not familiar with them.

But what is wrong with JavaScript, you may ask.

Well, the truth is, JavaScript was never designed to support the complexity of modern applications. It was designed back then when we were surfing the web using these ancient dial-up modems that were making a characteristic noise. It wasn’t designed to write advanced applications like GMail, Netflix, Spotify and many more.

Photo Credit: Hello I’m Nick

From the 90s to the Metaverse era, a lot of things have changed. Applications are now running fully on the browser. In the past, they were only running natively and you had to be home and use that huge computer with the CRT monitor. Now everybody is looking at their phones, even when they are not supposed to. Google is selling Chrome-based laptops. And don’t forget, JS now runs on servers too. Even NASA uses JavaScript.

Compared to languages like C# or Java, which are being used widely in the enterprise world, JavaScript seems that it doesn’t have anything to offer to these developers, who were used to organizing their code using classes, interfaces, namespaces and modules.

On top of that, the development experience is day and night. Your text editor simply cannot compete with a sophisticated IDE like Xcode, or IntelliJ. Besides the code highlighting - which sometimes is very dumb - and some common errors that can be handled with a linter, it doesn’t provide any code completion suggestions, it doesn’t recognize the types of your variables, and most importantly, it doesn’t give you any sophisticated debugging tool.

Photo Credit: Lorenzo Herrera

There were multiple attempts in its history to fix JavaScript.

From the ancient ActionScript, CoffeeScript, ClosureScript and Elm, to the most recent ones Reason ML, Dart, LiveScript and many more. These languages provide a better developer experience and they are strongly typed. Some of them are object-oriented. Others are functional. At the end, the goal is the same. You write your apps in a higher level language that compiles to JavaScript.

As a side note, you can use Python, Ruby, Kotlin, Scala, Swift, or even Java if you find the right compiler. But there’s no benefit in starting a new JS project with such languages. Who would like to maintain such a monstrosity. But even if you ever have this need, I would recommend you to check WebAssembly.

This is how TypeScript became a game changer. Now check it by yourself.

The Type Experiment

Read the following code and try to spot any mistakes.

const favorites = {
  tracks: [],
  totalLength: 0,
}

function addToFavorites({ title, artist, album, length }) {
  favorites.tracks.add({ title, artist, album, length })
  favorites.totalLength = favorites.totalLength + track.length
}

const track = {
  title: 'Bohemian Rhapsody',
  artists: ['Queen'],
  album: 'A Night At The Opera',
  length: '5.45m',
}

addToFavorites(track)

Ah, yes! I forgot to mention that because the author of this post is a music lover, we are going to build a music player in the following posts. This code snippet is basically handling our favorite tracks.

Some of you may think to copy this snippet and paste it into your browser’s console. But I will save you from this extra effort. This code has zero errors.

You will find the answer at the end of this post.

What is TypeScript?

TypeScript is at the moment one of the most popular strongly typed flavors of JS. It is highly adopted by many of the JS projects over the world, especially on backend applications.

What makes TypeScript easy to adopt is the fact that your code is as close to JavaScript as it can be. As a superset of JavaScript, any code that runs on JavaScript, runs perfectly well on TypeScript too.

The maintainers of the TypeScript language decided to stay away from custom code syntax. Its additional features are already supported or they will be supported in future versions of JS. That’s a huge benefit for developers, because you theoretically won’t need to refactor your code completely when an X feature of JavaScript becomes available, when TypeScript becomes obsolete, or when you find a better tool to handle your type definitions much more efficiently.

There are plenty of things you can do in JavaScript, that TypeScript will prevent you.

For example, check the object below:

const track = {
  title: 'Bohemian Rhapsody',
  artist: 'Queen',
  album: 'A Night At The Opera',
  length: 354,
}

console.log(track.name)

This code will not compile, because the name property doesn’t exist in the track object. But, this works perfectly on JS. TypeScript will return the following error:

Property 'name' does not exist on type '{ title: string; artist: string; album: string; length: string; }'.

Now, what will happen if I accidentally forget how I declared the length property and I assign a string to it?

const track = {
  title: 'Bohemian Rhapsody',
  artist: 'Queen',
  album: 'A Night At The Opera',
  length: 354,
}

track.length = '5.54m'

Again, this will work on JS, because nobody prevents me from changing the type of a property, but it will throw an error in TypeScript:

Type 'string' is not assignable to type 'number'.

TypeScript noted that a string has been assigned to the property length and it will prevent me from changing its type.

Here I want to mention that all I did was to rename my index.js file to index.ts. Just by changing the extension of the file to .ts, I helped my text editor to become a little bit smarter:

TypeScript doesn’t stop there.

I can specifically set the types of my properties, without even setting an initial value. What if I had a class of music tracks:

class Track {
  title: string
  artist: string
  album: string
  length: number
}

Yes, my friends. This doesn’t look like JavaScript anymore.

It’s important to understand that classes exist in JS, but types exist only in TypeScript. When your code is transpiled to JS, all the type definitions will be removed.

How to integrate TypeScript in your projects?

The easiest way to use the TypeScript compiler is to install the TypeScript plugin on your favorite text editor. We’ve seen already that TypeScript has its own file extension .ts. Your editor will compile all these files using the TypeScript compiler automatically for you.

The editor of my choice is Visual Studio Code, which has excellent built-in support for TypeScript. By simply pressing the Run button you will find in the debugging panel, VS Code will compile your TypeScript code and if it has debugging capabilities built-in, it will even run it for you and show the result in a browser window or in the Node.js runtime.

There are plugins for Eclipse, IntelliJ, Sublime Text, Emacs, Vim, and many more. They provide the same functionality, but some may have less debugging options. This doesn’t mean you can’t use a plain text editor, like Notepad++, but you will need to do some manual work to run and debug your application.

Photo Credit: Terry Lee

Type checking on demand

You can also choose to enable TypeScript only in specific files. Let’s say that you are working with an existing application that already runs in JS and you want to slowly migrate it to TypeScript.

Here, I’m using the .js extension, but because I added the //@ts-check comment, my editor treats this file as a TypeScript code:

JSDoc

Another approach to enable TypeScript in your JS application, is to use JSDoc. JSDoc acts as an API documentation generator for your JavaScript project, similar to Javadoc or phpDocumentor. You can add documentation comments directly to your source code, right alongside the code itself. The JSDoc tool will scan your source code and generate an HTML documentation website for you.

Here’s an example of how JSDoc is working:

/**
 * Represents a track.
 * @constructor
 * @param {string} title - The title of the track.
 * @param {string} artist - The artist of the track.
 * @param {string} album - The album of the track.
 * @param {number} length - The length of the track.
 */
function Track(title, artist, album, length) {}

Your text editor will now display useful information about this function as I type:

This is a premium feature that you find only in sophisticated IDEs like Xcode or Visual Studio.

The tsc compiler

So far, we have been using the built-in features of our text editor, to compile our TypeScript code. But what is happening in the background? I would like to introduce you to the TypeScript compiler. Visual Studio Code has built-in support for TypeScript, but it doesn’t include the TypeScript compiler. You will have to install it yourself.

You can install the TypeScript compiler by running the following command:

> npm install --global typescript

Like every other JS library, TypeScript works with Node.js. It is being distributed via the Node Package Manager (call me npm). This means, that in order to run the TypeScript compiler, a latest version of Node.js must be installed on your system.

Now let’s try it in practice. Somewhere in your development directory, create a file called index.ts. We will use it to write our first TypeScript example.

For the sake of this demonstration, we can enhance our Track class, that we mentioned before, to include a constructor:

class Track {
  title: string
  artist: string
  album: string
  length: number

  constructor(title: string, artist: string, album: string, length: number) {    this.title = title    this.artist = artist    this.album = album    this.length = length  }}

Now we can use our newly created class to instantiate an object:

const myTrack = new Track(
  'Bohemian Rhapsody',
  'Queen',
  'A Night At The Opera',
  354
)

Now, navigate to this directory with your terminal, and use the command to compile your TypeScript code:

tsc index.ts

Now, take a look at the directory the file is located. You will notice that the TypeScript compiler has generated a new file called index.js. The output depends on the compiler configuration file. Here are the contents I got when I ran it:

var Track = /** @class */ (function () {
  function Track(title, artist, album, length) {
    this.title = title
    this.artist = artist
    this.album = album
    this.length = length
  }
  return Track
})()
var myTrack = new Track(
  'Bohemian Rhapsody',
  'Queen',
  'A Night At The Opera',
  354
)

The code is quite similar to the one we had in the index.ts file. You will notice that the class declaration has been replaced by a variable, and the constructor method, with a function.

That’s due to the limitation JavaScript has for classes. Although it has been added in recent versions of EcmaScript, some of the browsers that are still used on production are still in a previous version.

I’m talking about you, Internet Explorer.

If you are writing a backend application, you can try to run this example via node:

> node index.js

Make sure, you are using the .js file, because Node.js doesn’t have any clue about TypeScript. At least by default.

If you are targeting a client-based app, the index.js file is the one you are supposed to share with the world:

<!DOCTYPE html>
<html>
  <script type="text/javascript" src="./index.js"></script></html>
<body>
  ...
</body>

TypeScript knows already which features are supported by which browser and it is smart enough to transpile our code to a version of JavaScript that will always work. We also have the option to configure which version we are targeting, in the tsconfig.json configuration, which we will cover in a minute.

Now you may ask, what if I change this js file? Will this cause any issues? Well, in general, you don’t have to. You are not supposed to touch these files. Your goal is to write your source code in your ts files and then you have to run the tsc command every time to generate a new version of the js file. From now on, you can forget about these automatically generated js files.

To avoid running this command manually, every time you change your code, you can use the watch option:

> tsc --watch

Now the TypeScript compiler will watch for changes and every time you save any of the ts files in this directory, it will re-transpile the code for you.

Photo Credit: Ben Blennerhassett

Our first TypeScript project

Excited about types? I know, the next thing you are wondering is how you can force them in your applications. Well, my friends, it only takes a line of code.

Back to our example, you have to delete the newly generated index.js file. Then, run the following command:

> tsc --init

This command will generate a new file tsconfig.json. This file includes all the configuration that your TypeScript compiler needs, to do its job.

Here are the most important options:

{
  "compilerOptions": {
    /* The transpiled code will be in ECMAScript 5 */
    "target": "es5",
    /* We will use commonjs to modularize our code */
    "module": "commonjs",
    /* The transpiled code will be stored in the subfolder /js */
    "outDir": "./js/"
  }
}

As you will observe, there are plenty of options to be commented out. For simplicity, I have omitted all the other options. You may want to read the comments and customize them according to your needs. Have a look in the official documentation to find more about the available options. We will cover some important ones in the upcoming posts.

Now every time you run tsc to this folder, the TypeScript compiler will read this file and it will adjust its settings accordingly. This works for other projects you are contributing to.

In case this file is absent, or some of the options are not listed in the file, the default options will be the values that you see in the comments. For most projects, these defaults are good enough.

By having this configuration file in your project repo, you ensure that all the developers on your team will have the same tsc configuration, and the project will compile correctly everywhere. The same applies for your CI pipeline.

The Online Playground

One more tip before I let you go.

If you just want to try out the TypeScript compiler, without installing it locally on your system, you can try the TypeScript Playground.

Try to write a TypeScript code on the left side and press Run. You can see the transpiled JavaScript code on the right.

The Solution

Remember the JS example I shared with you in the beginning of this post? Let’s copy that code snippet to our TypeScript file to see what we will get.

This code will not work, but believe it or not, it is perfectly legit in JavaScript. By that, I mean that we are technically not violating any of its rules.

Not even strict mode can save us.

At line #7, we are using an array method that doesn’t exist. The correct method is push() not add().

At line #8, we are adding a string '5.45m' to the number 0. Again, this is valid JavaScript code. The JavaScript compiler will automatically coerce the number to a string and the result will be '5.45m', which is far ahead of what we wanted to achieve here.

Ultimately, at line #13, we have a typo in the property name artist, which must not be plural.

Already a JS dev? You will be surprised at how many mistakes TypeScript will find in your code. Just give it a try.

I hope that now you have a better understanding of what TypeScript is, how it works, and how you can integrate it in your applications.

If you have any questions, don’t hesitate to drop me a text, you know where you will find me. If you want to help the author fix common mistakes and errata, feel free to create a pull request on GitHub. It would be highly appreciated.

Until the next one, happy type checking! 🧐

Cover Credit: Shubham Dhage

Fun Facts About Switzerland Part IV

Wed, 24 Nov 2021 22:12:00 GMT

How you answer a phone call in Switzerland? How you can buy goods without paying a rappen? Why people in Switzerland know what time and day will wash their clothes next year?

In case you missed my previous posts, this is the fourth part with fun facts about Switzerland. It’s pretty biased, not sophisticated whatsoever, and I will do my best to not include any stereotypes.

Cheese? 🧀

Before we start, I just want to drop this here:

The Swiss keyboard layout

This is one of my worst nightmares. Not only is it QWERTZ instead of QWERTY and every time you confuse the letter Z with Y, it is a mixture of German and French keyboard layouts. You can switch to English of course.

I thought as a developer, I was very familiar with the keyboard and this layout change will not affect my typing. I was wrong. Good luck finding where the special characters are located. The trick I have found is to press any key just to see the output, until I find the one I’m looking for. Such an entertaining activity to try at work.

Now I will teach you how to answer phone calls in Switzerland. Usually, when you receive a phone call, your first reaction is to say something like “Hello”.

Nope. This will not work in Switzerland.

Here in Switzerland, people are used to answer with their family names. Yes, this includes every stranger who’s calling you. If you don’t pronounce your last name, the other person will be confused. They will try to identify with whom they are talking to. Think of it as if you had to press slide to unlock, but with your voice.

Since I’m not used to this habit, I spend one minute in every phone call, waiting for them to pronounce my family name correctly.

“Is this Mr. Tsourekitibitidis?“.

Now let’s talk about God.

If they ever ask you what is your religion in Switzerland, be a bit more skeptical about what you will answer. They don’t really care in which God you’re praying, they actually want you to pay the church tax. Yes, even God itself here requires money.

Credit: Henrique Ferreira

Now, if you are a little unlucky and your apartment is located near a church, be ready for some bell entertainment. For reasons unknown, the church bell rings multiple times per day. Sometimes it can even get stuck, and you hear it for several minutes.

The perfect way to enjoy your hangover.

Now let’s address the elephant in the room; Money.

OK, this is not a secret. In Switzerland, we have a lot of money. You probably know that a Big Mac costs 12.50 euros, which is something like the global measure unit for wealth. This doesn’t mean that people are rich, not even close, but it gives you an impression of how much money is being transferred on a daily basis.

What’s more impressive is the fact that people trust you.

When I moved to my previous apartment, I went to the famous Swedish furniture store (now that I’m a content creator, I don’t really promote brands for free) to buy everything I needed. Yes, you guessed it right, I ended up spending a large amount of money on the most useless stuff. When I went to the counter to pay, there was a mistake related to the product tags, and they promised to send me the bill via post.

I paused for a minute to think what they meant. Maybe I misheard. Maybe I was confused after all this time choosing colors for the toilet cover. But when I asked them to repeat what they said, I was even more surprised by their confirmation.

This is an orange payment slip. It’s the most common way to pay bills here in Switzerland.

They did want me to leave without paying. I ended up going home with multiple-K worth of furniture, without paying a single rappen (the Swiss equivalent of a cent). Of course, in the following week I had received the bill.

This is very common here. You take your car to the garage, you leave without paying. They will send you the bill at home someday in the near future. Sometimes they don’t even tell you what they fixed and how much you are supposed to pay. It takes extra effort to get this information.

Now make sure you pay this bill to avoid the consequences.

We talked about so many things, maybe some of you are already convinced to move here. Well…

Finding an apartment can be very hard, especially in big cities. There was recently a story in the news that hundreds of people were waiting to view an apartment in the center of Zurich. But seeing the apartment is only the beginning.

To rent an apartment, you need to prepare yourself for a fair amount of paperwork. After viewing the apartment, you will receive the official application form, which contains a lot of nice checkboxes like if you have any pets, if you play a musical instrument or if you are a programmer. No, I’m kidding they don’t ask you that, they get this information from the papers you are providing to them. Which papers?

So, to get an apartment you have to provide them with your CV, a confirmation from the local authority that you don’t owe any money (check the previous section), a motivation letter with how much you want to rent this apartment, and some references. Yes, they call your boss to confirm that you are working, your neighbors to confirm you are not an annoying person, and of course, your current landlord, to check if you follow the rules as you’re supposed to.

It kinda feels like this episode of Black Mirror, where people can rate each other from one to five stars for every interaction they have, which can impact their socioeconomic status.

Credit: Anokhi De Silva

But you haven’t finished yet. Now you have to give the keys from your previous apartment. Good luck with that. The last day of your rental, you will have a meeting with your landlord together with the next person who will rent the apartment. They will search the place centimeter by centimeter. They will try to find every possible defect or dirt.

I had to pay a professional cleaning company to clean my previous apartment, and it turned out that they had to visit again to clean the parts that were not properly cleaned. There was an awkward moment where four people were on top of my shower sifone, the pipe that collects all the water. I didn’t dare to ask what they found inside, but there was a big discussion with all the parties involved.

Now, you may want to buy your own apartment at some point. Why spend your money on rent, you may think.

Well, my friends, I have bad news for you. The apartments in Switzerland are extremely expensive. You can easily spend a million of Swiss Francs. Many of the people I know have a loan until their retirement. Sometimes even until death.

You finally made it! You have your own apartment. Furthermore, you may think that it’s all over now. But now it’s where the fun begins. You have to agree with the terms and conditions. My previous apartment had 7 pages full of rules.

Front and back.

Credit: Claudio Schwarz

But what kind of rules, you may ask. Well, most of the time, don’t expect something crazy. I said most of the time.

In some apartments, it is forbidden to flush your toilet after 10pm.

Yes, you heard it right. The older buildings have very old pipe installations and every time that you visit the WC, the noise of the flush is very prominent to all the tenants. Not the best thing to do in a country that detests any kind of neighbor activity.

You also have to book your laundry times. You see, most of the apartments in the city center are relatively old, and they can’t host a washing machine. What you get instead is a laundry room somewhere in the basement. Each tenant books the time that is most convenient for them. Sometimes you have to pay a small amount of money every time that you use the washing machine or the tumbler. I told you, nothing comes for free.

Credit: engin akyurt

Of course, it doesn’t mean that the machines will be 100% free at the time you bring all your belongings downstairs. Some people simply don’t respect the schedule. Just make sure not to forget your underwear in one of the machines and turn your neighbor’s clothes pink.

Speaking about rules, I have another topic which needs its own section. It’s about recycling.

When I first registered myself in Zurich, I received the official guide for recycling. In the beginning I thought, wow how they have it well organized. Later on, I started struggling to divide my trash in multiple groups.

The most difficult is paper and carton. Let’s say you receive a package at home. In order to recycle the carton, you need to remove all the plastic, the paper, any stickers or tape. Sometimes it’s very difficult to understand if something goes to carton or paper. For example, the bag from the supermarket goes to carton collection.

Credit: Tran Mau Tri Tam

And don’t even think about cheating, the garbage police will get you. They have people who open the trash bags, searching for any clue to identify your identity. Maybe you forget the receipt in the package. Silly you. In that case, you will receive the trash bag outside your door, with a friendly post-it on it.

“Please don’t do this again, we know where you live”.

Glass is also challenging to recycle. You need to remove the cover, of course, because it’s plastic. There are different bins depending on the color of the glass. Ah, and never recycle glass on Sundays. The noise will make everyone crazy. People will be very mean to you. They will start yelling from their balconies. Don’t tell me I didn’t warn you.

We reached the end of our journey, my friends. This will be most probably the last part of this special series. I think I covered most of the points I wanted to share with you. Now that I’m thinking, I have one post for every year I’m living here.

A special thanks to my colleague Laszlo Markert and his wife. They contributed a lot to collect these facts.

Until the next post, take care and wear your mask! 😷

The beautiful cover is taken somewhere in Montana, by Artiom Vallat.

Fun Facts About Switzerland Part III

Wed, 17 Nov 2021 22:12:00 GMT

What is forbidden to ask in a Swiss restaurant? Where all the people go on Sundays? Where do all the cows go in summer? What is a Hüsli?

Our journey continues with another post about Switzerland. This time we will talk about life in the city, traveling and languages.

Bratwurst? 🌭

The most important question I get from my friends from Greece is related with nightlife. You see, Thessaloniki, my hometown, has a very vivid nightlife. People like to go out several times per week. We even receive jokes about the coffee habit that we have from other cities of Greece.

Well, I have to say, Zurich has a pretty balanced nightlife. You can potentially find a wide list of options for entertainment, but it may be a little bit limited. Don’t expect the variety of Berlin or London, for example.

What was unusual for me here is the fact that people are drinking on their way to the bar. You will see a lot of teenagers carrying beers on the street or sometimes even in the busses. No, they are not alcoholics, they are just trying to reduce their costs. Drinks can be an expensive hobby here, especially if you are a student.

Public drinking is awesome in the summer. You don’t need to dress perfectly to go out, you don’t need to wait for hours in the lines, or to impress the doorman guy. You call your friends, you grab a couple of beers, snacks, sometimes a fully charged bluetooth speaker, which at the end it only works for 15 minutes. There are plenty of places to go, usually people prefer to stay by the lake. The vibe is really relaxed. Sometimes you may be lucky to find a spot next to a band, and you can enjoy exquisite music. Sometimes the music can be really poor.

Credit: Wyron A

The story can be a little bit different for other cities. I have the sense that most of the Swiss cities are very silent at night, except of Zurich. The most disappointing for me was Geneva. Don’t be surprised if you find no people on the streets on a Saturday summer night.

Zurich is known as the venue for the brightest Swiss festivals, events, and celebrations. Sometimes the whole city is being transformed into a trance club. You may enjoy popular bands and DJs. And it goes really wild. But the impressive thing is, the next morning, everything goes back to normal. No more confetti, empty cups, bottles, DNA, or any other waste. It’s like nothing ever happened.

If you ever visit a Swiss city, you will most probably notice the water fountains. And I’m not talking about these large fountains that are used for decoration purposes, I’m talking about drinkable water flows. For example, in Zurich you will find 1,200 fountains.

In your face Fontana di Trevi.

A lot of people are carrying a small water bottle and they fill it up with fresh water.

Credit: Dorothea OLDANI

What is really weird is if you ever ask for tap water in a restaurant. The waiters will look at you like you are doing a crime or something. It’s kinda ironic if you think that the water quality of Switzerland is one of the best you can find on earth.

What also impresses me is the fact that people travel a lot. And I mean a lot! Sometimes it’s hard to meet friends because they may be in different mountains. The author is not excluded. Alongside Switzerland is in the center of Europe. For starters, Switzerland is next to Germany, Italy, France and Austria. The Swiss salary is also another factor that makes people less concerned about the hospitality and transportation costs.

Having a stressed week? No problem. Just book a Chalet on a mountain for the weekend and enjoy the iced view while you are relaxing in your warm Jacuzzi. What? It is summer you said? Kein Problem. Get a plane for Malta and in 2 hours you can get loose at the beach. It only costs hundred Swiss francs. That’s what you will pay if you go out Saturday night anyway.

People in Switzerland like to plan in advance. Don’t be surprised if you don’t find any friend to join you for a coffee this weekend. Most probably they have planned to go to a mountain, ride the whole city with a bicycle, visit their parents in Saint Gallen, or even being in another country for a long weekend trip.

I have observed that people are more active here. They will most likely prefer to spend 1-2 days in their free time on the mountains, doing sports or enjoying the nature. I also changed my habits for the better.

That’s why you may not find a lot of people in the city on Sundays. They are most likely somewhere away or they enjoy their family time. Restaurants and coffee bars are also likely to be closed on Sunday.

This means you should definitely reserve your table in advance. I have a friend who tried to book a table for brunch and they told him that the next available date is in one month.

Even cows in Switzerland go for holidays during the summer months.

I’m not kidding. According to the Federal Office for Agriculture, around 270,000 cows are marched from their valley farms to mountain meadows at the start of every summer, just to come back down again in early autumn. Apparently this increases the quality of the milk. Which is an extremely important ingredient for the famous Swiss cheese.

So don’t get bored, do it like a cow!

I have observed that many of my Swiss friends, travelled from 6 months up to a year somewhere in the world, right after their university studies.

Besides the fact that it’s costly, and it’s not easy to manage if your budget doesn’t allow it, I find it one of the nicest things to do in your life. You have the opportunity to discover the world and earn new experiences. Plus, you are more relaxed and prepared to ride your career train. Of course, as everything in this life, it depends on your wealth and life situation.

But don’t let the money discourage you. It’s relatively easy to make some savings here and give a long break to yourself and your family. A lot of people take this opportunity to learn, for example Italian, so they leave for 1-3 months in Italy and they are working from there, practicing their language skills with native speakers. Companies will also welcome your decision, if the language is important to their business.

Now, you may ask, how you can manage to leave everything behind for such a long period of time. The best way is by subletting your apartment. You will help other people, and more precisely students, to find a decent and affordable place to stay. And the amount of money you will save is usually enough to pay for your accommodation.

Now I would like to open another big topic, which is the language.

Switzerland has 4 official languages; German, French, Italian and Romansh. It is common to find people that speak or at least being able to understand most of the languages.

In Zurich people speak German (Deutsch). To be able to communicate with them it requires a lot of effort. You start by taking German classes. After some months, you feel empowered with your achievements. You can perfectly communicate with your teacher. Now it is time to practice your skills with locals, you think. What can possibly go wrong, right? Well, my friend, I’m afraid it’s not gonna work.

Luzern is one of the most beautiful Swiss cities.

In Switzerland we speak Swiss German (Schwiizertüütsch). Don’t be surprised if you don’t understand a thing from what you hear in the streets, even if you speak German fluently. You may want to spend some time to learn the dialect. But that’s also not enough.

And to make it even more difficult, the cantons of the German part have their own dialects. People from Zurich speak differently from people from Bern. Some cities have a lighter version, others a forceful one.

What I was struggling the most here in Zurich is to learn how to greet people. You always need to check for the other person’s age. There are different phrases for people younger than you, and different for older people. Also there are formal and informal phrases. You can’t just say Grüezi to a kid that passes by, it will be very formal.

Of course, the more Swiss German you speak, the more people will like you, no matter which phrases you are using. Good luck when you go back to German-speaking countries. You now have the habit to speak with your Swiss dialect. I have a friend who received complaints because he wasn’t speaking German in a German train somewhere in Germany. Of course, the old lady who complained didn’t know this is a German dialect.

The only Swiss word I used to know before I moved here was Müesli.

Yes, you most probably know it as well, it’s the healthy yogurt companion. What I didn’t know is that Swiss German is characterized by the frequent use of the diminutive. This means that nouns are usually “reduced in size” by adding the suffix “li” to them.

For example, if you want to say little man (Man in German) you say Männli, for little mountain (Berg) you say Bergli, and for little house (Haus) you say Hüsli.

If you ever want to make fun of a Swiss friend, just put -li at the end of every word. Who knows, maybe you will catch some.

Once again, thank you for reading this post. I am saving the fourth part for next time, which will probably be the last. After that, I will continue with my boring programming topics. I forgot how to write technical articles after all these posts.

The beautiful cover is taken at the lake Klöntalersee, by Dave Ruck

Fun Facts About Switzerland Part II

Wed, 03 Nov 2021 22:12:00 GMT

What do we really mean in Switzerland when we talk about hot dogs? Which are the most indistinguishable Swiss meals? How to eat a salad like the Swiss? And what do you need to know in case they invite you for lunch?

Yes, you guessed it right! This will be a food special.

In case you missed my previous post, this is the second part with fun facts about Switzerland. It’s pretty biased, not sophisticated whatsoever, and I will do my best to not include any stereotypes.

Cookie? 🍪

Grüezi wohl! It’s finally time for lunch! The best way to socialize with your friends and colleagues. Here I have some tips for you if you ever visit Switzerland. Let’s start with the basics.

The most important phrase to remember is “En guete”, which literally means “Have a good one”. It is similar to “Bon Appétit”. You will hear people here use it a lot. They actually expect to hear it from you before they even eat.

Don’t worry if you forget it, somebody will remind you to do so. It’s one of these moments that you feel like a kid, and your parents are teaching you how to behave.

The German version of the cheesecake is one of my favorite desserts. You can find plenty of them in multiple variations.

Time to raise your glass? Yeah, I know you will probably try to cheer anyone on the table, but this is not how it works here.

You should greet every person on the table individually, by looking at their eyes. Maintaining a visual with the suspect is really important. Sometimes, when I forget, people are staring at me with a question on their faces. “Why he doesn’t even look at me? What is his problem?“.

Time to go home? I know it’s a bit late. Get your coat ready and prepare for a warm goodbye gesture.

In Switzerland, it is common to give 3 kisses and a hug when you say goodbye. There is also a strict specification on which side to go first, to avoid the awkward moments. Actually no, that’s sometimes unavoidable. Thankfully, this is only between friends, so you will not have to kiss your boss.

What about the food Nick?

Well, since I’m coming from a Mediterranean country, I usually find the food in Switzerland kinda meh. I don’t have a problem with the quality, as much as I have with the quantity. The truth is, there are plenty of nice dishes to try.

One of the most traditional Swiss delights is Fondue and Raclette. They are both really tasty. It’s one of the best activities you can do with friends. I mean, who needs to ski anyway…

But be careful. They do smell a lot. I haven’t been on sports that much in my life, but I can tell you that my socks after a long workout don’t even compare to that smell. We always have to come up with a practical solution in order to cover the smell when we’re inviting friends home to enjoy some cheese.

My least favorite Swiss dessert is called “Gipfeli”. It looks a lot like a croissant. But it’s not! I think the people who brought the first croissant from France forgot to put butter, sugar and make it crispy. It’s a terrible disappointment when you are craving something sweet.

Now let’s talk about pizza. As a pizza lover, I usually don’t trust people who don’t like pizza. And Switzerland, has some very nice pizza restaurants. The dough is highly influenced by our Italian neighbors, and yet it’s very thin.

The unusual part about the pizza here in Switzerland is when you order in. They never cut the pizza into slices. Apparently, this is a way to preserve the taste. So when you are home, watching the movie with friends and the delivery arrives, everybody takes a break to cut the pizzas. Cutting the pizza with friends is another entertaining activity to do at home.

In Switzerland, it is allowed to eat your dog. You are not allowed to bring company at home to eat it together.

OK, I know you need some minutes to recover after this fact. Let’s talk about the regular hot dog. I promise no more Halloween splatter references.

The Swiss hot dog is called Bratwurst. It’s basically a type of German sausage, which is extremely popular here. When you order a Bratwurst, you get separately the sausage, the bread, and the sauce, which is usually mustard. Good luck fitting the sausage in the bread. Despite the fact that you don’t have any hands, the bread is much smaller.

But my biggest fight when it comes to food is the salad. I don’t know why, but the lettuce pieces, here in Switzerland, are ridiculously large. It’s just ludicrous. Don’t even think to grab them with your spoon, you will embarrass yourself trying to eat the whole piece at once. You will also decorate the table with the salad dressing.

After some research, I found the approved way to eat a salad. You have to use your fork and knife to fold them into pieces. Here’s a video for dummies.

Having a barbecue is one of our most favorite urban activities. Drinks are allowed in the public. Usually people grill sausages, and they enjoy them with fresh salad and drinks. Beer is our national drink.

There are open fireplaces in many parts of the city to barbecue with friends. Some of them even provide firewood and dining furniture.

In Switzerland, we celebrate with Apéros. These are in-betweens, organized on special occasions, celebrations, and team bonding events. Their menus usually involve wine, cold meals, cheese, and crackers.

Due to the fact that I am working in a multinational company, I had the chance to participate in many Apéros and try a variety of cuisines. Every individual brings their national delights to the table.

You want to celebrate for a release? It’s time for an Apéro. Your friend got a new job? Time for an Apéro. You have no clue what to do with your life? Well, an Apéro may help here, but it’s better to stay away from Alcohol. Just saying…

That’s all folks. I have to go. Suddenly I am craving Bratwurst. Don’t worry, I will not eat my dog.

I have more things to share with you. I am already preparing the third part, with more fascinating facts about Switzerland. So stay tuned. You know where you will find me.

If you are living in Switzerland, don’t hesitate to suggest your favorite fun facts. You can reply to this tweet.

Adieu 👋

Fun Facts About Switzerland - Part I

Wed, 27 Oct 2021 22:12:00 GMT

What makes Swiss transportation so good? Why is driving in Switzerland so boring? How does the Swiss army land aircraft?

Let’s discover some of the funniest facts about Switzerland, mixed with my personal experiences and tips. Normally, I write technical articles about software engineering on this blog. This time, I’m going to try something completely different.

But first, we need a proper introduction.

Cookie? 🍪

For the last 4 years, I have lived and worked in Zurich. I have had so many nice experiences in this country. The nature, the people, the places, the life quality and the list goes on. I was originally born in Thessaloniki. This is the first time I live abroad. In fact, I haven’t even visited Switzerland before moving. It was a completely new experience for me.

Many people are asking me about the life here. Is it worth it? I am usually trying to avoid all these questions, since it’s a very personal decision at the end, whether a place is good or not for you. This is not what I’m trying to achieve with this article.

This article contains fun facts about Switzerland. Things I found interesting and unusual. I tried to stay away from stereotypes, although it’s not always the easiest thing when you write an article with this topic.

The idea for this post came from my recent participation in the Zed Conference. We worked with my colleague Laszlo Markert to make a very funny presentation about Living and Working in Switzerland. This was a good opportunity for me to put together some words and create this post. Many thanks to Laszlo and his wife for their contribution.

While I was writing this post, I discovered that I have too much to write. I started splitting them on multiple posts. I thought it would be easier for me to write and for you to read. This is the first part of the series. I will try to post a new one every week.

OK let’s leave these disclaimers aside. It’s time for the actual facts. Let’s start with the most obvious. Nature.

Switzerland has over 48 mountains and 7000 lakes. It has plenty of activities for everyone. It really feels that you don’t have the time to visit and do everything.

Growing up in Greece, I was convinced there was no other place as beautiful. Switzerland changed my mind. In the winter, the snow covers the tops of the mountains, which blend magnetically in the lake waters. In the summer, the whole country is transformed into an endless green land.

While you’re enjoying your trekking on a mountain, it is very likely to meet a cow. You can hear them far away from the ringing bells they carry. You will also sense the smell.

Credit: Wolfgang Hasselmann

Especially if you live in a village, it will be difficult to stay with the windows open while it is summer. This can also be a practical way for you to quit smoking.

I mean seriously, take a look at this house. It’s like a dream!

My previous apartment had a very important feature. A device that circulates the air, without having to keep your windows open. My landlord advertised this feature a lot when I was viewing his apartment. Back then, I couldn’t understand the reason. You see, in Greece without an air conditioner, you will most probably be paralyzed every summer. My mind changed when I discovered the smell. Since then, I am very grateful for this masterpiece of machinery.

But enough with this cr@p. It’s time to talk about something more adventurous.

To say that the Swiss transportation system is great, would be an understatement. It’s so good that people who grew up here don’t really understand how good it is.

You can conveniently go anywhere. To the most infamous village. To the tallest mountain and beyond. It’s just possible. In many places around the world, this is unheard of.

But where the Swiss transportation system really shines is not the flexibility, it’s the punctuality.

Credit: Eric Weber

Imagine a world in which every bus, every tram, every train arrives on time. You can conveniently know the exact time you will arrive in your destination. Google Maps departure estimates simply make sense.

To put this in the appropriate context for everyone to understand, in the Zurich central station, if the train has a 30 second delay, everybody is in a panic. They are checking their watches. They are moving nervously. They are under stress.

And the best part of it is we already know when there is a delay. The digital signage software is one of the best in the market. The official application also provides useful information about every possible inconvenience.

Of course, nothing comes for free. And I’m not talking about the cost of the tickets here. Although, now that I’m thinking, I really should, because they are extremely expensive. But that’s another topic for another time. I’m talking about the side-effects of having everything running on time.

In Zurich, tram and bus drivers can control the traffic lights. They simply stop all the cars.

What I hate the most is when you realize that your tram is on the other side of the road. You wait for the appropriate moment to cross the street and then you run a marathon to catch it. And right at the moment that you reach its doors, the doors shut in front of you. Now you have to wait for another 15 minutes.

There were cases where the bus stayed there, with the doors closed, for 1-2 minutes, even if there was a red light in front of it. The driver will completely ignore the people who are yelling and knocking on the doors.

Credit: Alexis Fauvet

But what’s their problem, you may ask? Well, as it turns out, the drivers are stressed about being on time. If they are delayed, the system will be notified and this will have a negative impact on their performance. Which may give their manager a reason to write a negative review. At least that’s what they think.

If you visit Switzerland, make sure to get a ticket for your dog or your bike.

What did you say? You are arriving by car? Well, keep reading. The next section is dedicated to you.

Driving in Switzerland can be boring.

You see, most people are driving ridiculously expensive super cars. And yet, the speed limits are some of the lowest you will find in Europe.

On top of that, you have sneaky cameras everywhere. The police are actually moving them to catch you by surprise. And they are working pretty well. In Switzerland, most drivers respect the speed limits. Because they don’t have another option. The law is very strict.

Credit: Nigel Tadyanehondo

To some extent, I believe the police intentionally set the speed limits that low, in order to collect more money. Otherwise, I’m not sure why there is a limit of 80 km/h (50 mph) on certain highways. In comparison with other countries, Switzerland has the best roads in terms of construction. On top of that, our neighbors in Germany have highways with no speed limits. And in Italy on the other side, the speed limits are just for decoration.

OK, you didn’t read this from me. Speed limits are actually helping us. Switzerland is one of the safest countries to drive worldwide.

Credit: Andreas Gücklhorn

On another note, I have observed that people have the tendency to lease their cars, instead of purchasing them. Nobody wants to maintain the running costs of having a car. As a trend, there are a lot of people who don’t even keep a car in their garage. Why do you need a car if you can just get the train to go anywhere you want?

Interestingly, other people prefer to use services like Mobility. You locate one of their cars using their app, you enter with your Swiss transportation card, and you basically rent the car for a couple of hours. Once you finish, you can return it to its original location. You may consider this as an option if you don’t use your car on a daily basis.

I have also observed green buildings, that prevent car owners from renting apartments.

We are approaching the end of this first part of our Swiss special. Before I let you go, there is one more story I would like to share with you. It is somehow related to the transportation topic.

Flight 702 departs from Addis Ababa Bole International Airport in Addis Ababa, Ethiopia, at 00:30 EAT on 17 February 2014. During the flight, the aircraft’s transponder begins to emit squawk 7500 — the international code for an aircraft hijacking — while flying north over Sudan.

When the pilot exited the cockpit to use the restroom, the co-pilot locked the cockpit door and continued to fly the aircraft.

Credit: Devam Jhabak. Please note that Swiss Air has nothing to do with this story.

The flight was originally scheduled to arrive at Leonardo da Vinci–Fiumicino Airport in Rome, Italy, at 04:40 CET, before continuing to Malpensa Airport in Milan, Italy. Instead, the aircraft was flown to Geneva, Switzerland.

The co-pilot makes several circles while communicating with air traffic control at Geneva International Airport. He is trying to negotiate political asylum for himself and an assurance that he would not be extradited to Ethiopia.

At 06:02 CET, the airplane lands at Geneva International Airport with about 10 minutes of fuel remaining. One of its engines had suffered a flameout.

The co-pilot exits the aircraft by scaling down a rope that he throws out of the cockpit window, before walking over to police. He surrendered after identifying himself as the hijacker, and was taken into custody. The airport was briefly shut down during the incident. No passengers or crew were injured.

Now you will ask, how do all these relate to our topic? Keep reading, now the good part starts.

While flying through their respective airspaces, the flight was escorted by Italian Eurofighter and French Mirage fighter jets. The Swiss Air Force did not respond because the incident occurred outside normal office hours, which are 08:00–12:00 and 13:30–17:00 Monday to Friday.

Credit: Ellen Jenni

A Swiss Air Force spokesman stated: “Switzerland cannot intervene because its airbases are closed at night and on the weekend. It’s a question of budget and staffing.” Switzerland relies on neighboring countries to police its airspace outside of regular business hours. The French and Italian Air Forces have permission to escort suspicious flights into Swiss airspace, but do not have authority to shoot down an aircraft over Switzerland.

Let me share with you a personal photo. What kind of a personal blog would this be without such a photo, right?

This is me hang gliding above Interlaken.

Hang gliding is the closest thing you can get to flying like a bird, and Interlaken is one of the best places in the world to do it!

This is one of the moments you question your friendship with panos.tech. After some days he texted me the following video. Thankfully, he lives far away.

Well, I don’t want this to discourage you. It’s really worth a try.

That’s all, folks! I hope you found these facts entertaining as much as we did. I have already started writing the second part.

Uf Wiederluege! 👋

Cover Credit: Alain Rieder

I built a Twitter clone to learn React

Thu, 06 May 2021 23:46:37 GMT

My goal with this article is to help you learn React. We will create a small twitter clone. I will guide you on how to build your own app step-by-step and I will try to teach you all the little details you need to get started.

If you never tried React before in your life, this will be a good starting point for you. If you know already the basics of React, you may find this article boring at best.

You can fork my GitHub repo: @nicotsou/react-twitter.

Found something strange? You can suggest changes by creating issues. Pull requests are also welcomed. This tutorial is also available in my blog repo.

To follow this guide you must have Node.js installed. Any version above v10 will work just fine.

One last thing. For making my tutorials easier to read, I always remove the ; semicolons in my code snippets. In spite of the fact that they are not really needed, you will find them in the actual project.

Ready to write some code? OK, let’s go! 🐤 🤩

Create a React application

Open your terminal, move to your development directory and run the following command:

npx create-react-app my-twitter-clone

The following prompt will appear. Accept the installation and take a small ☕️ break. The installation will take some time, especially if you don’t have any React projects in your system.

This will create a subfolder with all the files we need to run our newly created React application:

Let’s have a closer look at the initial folder structure:

/node_modules: This hosts all third-party npm packages that are needed in order to run and deploy our application. This folder is ignored from git. Sometimes it makes sense to delete it and run npm install. re-create it.
/public: This folder hosts public static files. The best place to put favicons, iOS icons or any other complementary file.
/src: This holds the source code of our application. We will work here to build our application.

How to run the application

Give it a try! The application is pretty functional.

At first you have to navigate inside the application folder:

cd my-twitter-clone

The only thing you have to do is to run the following command:

npm start

Now wait a bit. Your JavaScript application is building. Since our app is pretty small, this will not take much time.

If your firewall prompts you about allowing this application to access networks, press accept.

In seconds you will notice a new browser tab with the following page. If not, try to visit http://localhost:3000/.

The application is running successfully and you can interact with it. Well, there’s nothing to interact with at the moment, but we’re gonna change that soon.

Now try this one. Edit /src/App.js file. Change some of its text and save it. Notice that as you save the file, the changes are being reflected to your browser window automatically. That’s the best way to test our application in real time.

Stop the application by running Ctrl+C on the terminal window.

I want you to delete all the files inside the /src folder. We will recreate them one-by-one in the following section.

Now it’s time to write some code. 👨‍💻

Render the React application

In this section we will write all the elements that are needed in order to run our app. It’s better to spend some time to understand what is happening under the hood.

I want to give you an overview of how React works. Unfortunately in this article we can’t explain everything in detail. But I have selected a bunch of nice articles you can read at the end of this experiment.

In our public folder you will find an index.html. Search for the following div element:

<div id="root"></div>

This is basically where we are planning to render our React application. The root element.

React gives us an easy api to place React applications in our existing html elements. You just register them and you forget about them. React will manage all DOM changes for you inside those elements, but it will not touch anything outside.

The part of the React library that is handling DOM is called react-dom. Let’s see how we can use it.

By the way. If you are thinking now to change the favicon with the one from twitter, I would not judge.

To render a React element, create a new file /src/index.js:

// index.js
import ReactDOM from 'react-dom'

ReactDOM.render('no more hello worlds please', document.getElementById('root'))

Go ahead and run the application. You should see our friendly message.

Note that changes specifically to this index.js are not being automatically transferred to your browser window. You will have to manually refresh the page every time to see the changes.

The method ReactDOM.render() takes the following parameters:

The React component we want to render.
a DOM element in which we are planning to render the markup (render output).

ReactDOM is the one who will take care of updating the DOM as we dynamically make changes. At the moment it will display the following message:

We haven’t defined a React component yet. Let’s do so:

import React from 'react'import ReactDOM from 'react-dom'

// This is our first React component
function App() {  return <div className="App">no more hello worlds please</div>}
// We use <App /> as the root React component to render
ReactDOM.render(<App />, document.getElementById('root'))

Here we imported the core react library. This one allows you to create and manipulate React components. It hosts all the core react features, except everything DOM or mobile related.

You have to import this library, otherwise your JS runtime will not be smart enough to understand the syntax inside the function App().

That’s JSX. It basically allows us to write HTML inside JS. It has almost the same syntax, with some minor differences.

Our first component is named App and it will be the root component of our application. React allows you to write components in the form of JS functions. Simply use the return statement to return what you want this component to display on screen.

Every React component renders something on screen. If you don’t want to render something, then you can use a plain JS function instead of a React component.

You can create as many components as you want. You can nest components within other components to declaratively express your UI. Similar to how you write HTML.

In the next section we will do exactly that. We are building a twitter clone, so we will definitely need some React components to display its UI.

But first let’s fix some minor issues.

There’s nothing cool with Times New Roman or whatever the default serif font is in your OS.

Let’s make it nicer by adding the following file under /src/index.css:

body {
  margin: 0;
  font-family: sans-serif;
}

Ok now it’s more UIsh… We also removed the default margin in body.

To see the changes we will have to import this css file in our main index.js:

import './index.css'

Now you will be wondering, what the hell? We import a css file inside a JS file? How this is even legal?

Well, it is working perfectly if you refresh your browser. And that’s because your react application is using a bundle loader called webpack. Pretty awesome isn’t it?

If you managed to do everything your codebase will look like this: https://github.com/nicotsou/react-twitter/tree/step-1.

Now let’s implement that 🐤 twitter app.

Display some tweets

It’s time to show those tweets! Now it will get more interesting. 😁

Since this will be a very simple app without any api integration, I have prepared some initial data for you. It’s basically a json file with a list of tweets in it. To make things easier, copy its contents in a new file src/tweets.json.

Now we can move the implementation of the <App /> component to a new file. In general, it’s a good practice to keep every React component in its own file.

As a first step, we will update the index.js as follows:

import React from 'react'
import ReactDOM from 'react-dom'
import App from './components/App.jsx'

import './index.css'

ReactDOM.render(<App />, document.getElementById('root'))

Now, let’s create another file /src/components/App.jsx. Type the following code in it:

// App.jsx
import tweets from '../tweets.json'

function App() {
  return (
    <div>
      {tweets.map((tweet) => (
        <span>tweet.content</span>
      ))}
    </div>
  )
}

export default App

Here we are leveraging the map() function to loop through all the tweets. That’s how you loop elements in JS. Which brings us to an important observation.

React is just JS. There’s no pseudo code for us to remember. React basically embraces you to learn JS.

We imported the list of the tweets from a json file. Similar to css, Webpack can handle other filetypes too. One of these filetypes is the .jsx. This is a common pattern to name React components. It’s not mandatory though. You can use .js.

Note that a React component must always return a single root element. In our case this is a <div>. Try to remove it, it will fail. Try to return more elements at the same level, it will again fail. One React element at the root level. Simple rule right?

You may ask why this is a React element and not an HTML element. Well, it looks alike because they both use the same tag name <div>. But don’t let it fool you.

React has one React element for every HTML element that is available. When you return <div>text</div>; you are not returning an DOM element. You are returning a React element.

The react-dom library (the one we declared before in index.js) will take all these React elements, render them and this will produce the corresponding DOM tree. Another important thing to have in mind. A small detail, but it makes a lot of difference.

There’s another thing that is missing.

If you check the console in DevTools you will see the following warning message:

Warning: Each child in a list should have a unique "key" prop.

React also provides you a link to the associated article in their documentation.

Basically, React internally creates an auto generated key for every element. This key is being used in order to associate the actual DOM elements with the React elements. When you are dynamically rendering a list of items, React isn’t able to generate keys automatically. It simply cannot distinguish those elements because there’s no common attribute.

In order to help React recognize what is being rendered, we need to manually add a key attribute:

function App() {
  return (
    <div>
      {tweets.map((tweet) => (
        <span key={tweet.id}>tweet.content</span>      ))}
    </div>
  )
}

This key is a reserved prop for every React component. The key has to be unique, otherwise React will not be able to update the DOM correctly.

Now let’s add some structure:

import tweets from '../tweets.json'

function App() {
  return (
    <div className="timeline">
      {tweets.map(({ id, user, created_on, content }) => (        <div key={id} className="tweet">          <div className="tweet-header">            <span className="tweet-user">@{user}</span> ·{' '}            <span className="tweet-created-on">{created_on}</span>          </div>          <div className="tweet-content">{content}</div>        </div>      ))}    </div>
  )
}

export default App

Here I used classes to differentiate the divs. We will add the corresponding styles later.

Take a look at how we retrieve the data from tweets. We use a cool new syntax called Destructuring Assignment. That makes the code shorter and easier to follow. Of course it gets some time to practice it.

Note that even in the map loop, we are only allowed to return a single root element. If we don’t want any DOM element to be rendered as a wrapper we can use an empty <>. This is a syntactic sugar for React.Fragment.

Now that we learned how to create React components, let’s create more. Our goal is to separate the concern of the tweet from the actual application. Then we can add some styling.

Displaying our tweets

Let’s create a new component src/components/Tweet.jsx with the following code:

function Tweet(props) {
  const { user, createdOn, children } = props

  return (
    <div className="tweet">
      <div className="tweet-header">
        <span className="tweet-user">@{user}</span> ·{' '}
        <span className="tweet-created-on">{createdOn}</span>
      </div>
      <div className="tweet-content">{children}</div>
    </div>
  )
}

export default Tweet

Our newly created <Tweet /> component is only responsible to render tweets. Now it is time for some theory lessons. It will help us understand what is actually happening here.

I suppose you are familiar with HTML attributes. For example an anchor tag has an attribute to set the href:

<a href="/">Home</a>

Similar to HTML elements, React components can have their own attributes. For example our Tweet component has an attribute <Tweet name="nicotsou" /> which can be used from consumers to set the handle name for this tweet. It also has another attribute for the creation date.

There’s a reserved attribute called children. React uses this name convention for all the elements that you render inside this element.

This means that you are free to decide how to implement the api of your component. If you want your component to accept children, just use this prop.

In React there is also an easy way to do type checking. You can use a package called prop-types:

import PropTypes from 'prop-types'
function Tweet(props) {
  const { user, createdOn, children } = props

  return (
    <div className="tweet">
      <div className="tweet-header">
        <span className="tweet-user">@{user}</span> ·{' '}
        <span className="tweet-created-on">{createdOn}</span>
      </div>
      <div className="tweet-content">{children}</div>
    </div>
  )
}

Tweet.propTypes = {  user: PropTypes.string,  createdOn: PropTypes.string,}
export default Tweet

React will now check whether the types of the values match with the types you declared in your component implementation.

Note that we do not need to set a type for children, because we allow the consumers of our component to put anything they like.

Now here’s the good thing about this type checking system. It will only happen during development. This means while you are running your app locally. This part of the code will not be included in the actual application. That’s good right?

Of course nowadays we have some more sophisticated tools for type checking, like TypeScript or Flow. Since React is just a JS library, you can integrate it with any tool you like.

Another small note from my side. Notice that I’m using className instead of class. I guess you’ve read this JSX article I referenced before. No? Well, it looks like jsx has some tiny minor differences compared to HTML. Since class is a reserved word in JS, they had to come up with a different naming convention for classes that have to do with styling.

Ok that’s it! We made our first reusable React component.

To render our new component we have to modify /src/components/App.jsx as follows:

import tweets from '../tweets.json'
import Tweet from './Tweet'

function App() {
  return (
    <div className="timeline">
      {tweets.map(({ id, user, created_on, content }) => (
        <Tweet key={id} user={user} createdOn={created_on}>          {content}        </Tweet>      ))}
    </div>
  )
}

export default App

Notice the difference in the api. The json property created_on has been renamed to camelCase. Well that’s not a strict rule. You can name your attributes however you like. But, please don’t! Be a good person. Nobody uses kebab_case in HTML. 🙈

Also notice that the key attribute is only needed in the parent component and it doesn’t even appear in the <Tweet /> component.

Remember: Only when you render multiple React elements dynamically you have to provide a key. The key is not meant to be used inside the children component.

Our app is finally ready, but it looks like the famous emoji (sic). We will deal with this in the following section.

Adding styles

When it comes to styling we have plenty of options in React. The simplest one is to use a style attribute:

<div className="tweet" style={{ marginBottom: '20px' }}>
  ...
</div>

In certain situations this can be useful. Especially when we have dynamic styles. Instead I will use the same pattern we used in the index.js file.

Next to our Tweets component, let’s add a new stylesheet file called /src/components/Tweet.css:

.tweet {
  padding: 10px;
}

.tweet-header {
  display: flex;
  justify-content: space-between;
  margin-bottom: 5px;
}

.tweet-user {
  font-weight: bold;
  color: rgb(29, 161, 242);
  padding-right: 5px;
}

.tweet-created-on {
  flex-grow: 1;
  padding-left: 5px;
  color: rgb(110, 118, 125);
}

.tweet-content {
  padding-left: 16px;
  padding-bottom: 20px;
}

Of course in order to make it work we would need to import this file in our Tweet.jsx:

import './Tweet.css';

Not bad isn’t it? I would not call it art. At least not yet. But we are getting there… 🎨

![images/react-twitter-clone first draft.png](images/react-twitter-clone first draft.png)

If you followed everything until this point, your codebase will look like this: https://github.com/nicotsou/react-twitter/tree/step-2.

Next step: refactoring! 🧑‍🎨

Adding more components

I’m not 100% satisfied with the current version of our <App /> component. I am thinking to separate the logic of the timeline with the app itself. I take my notepad and after some thinking, I came up with the following sketch:

We have the following components:

ComposeForm, is just an input to post a new tweet.
Timeline, is a list of tweets.
Tweet, is a tweet that’s being tweeted by tweeters.
Avatar, will be used to display profile photo circles.
App, is the one that contains the compose form and the timeline.

Let’s transfer it in code. Before we start I want you to stop the project and install the following npm package:

npm install react-icons --save

We want icons to make our app look awesome. Instead of downloading manually those svg files and importing them to our project, we are using a third-part package called react-icons.

We used to say “There’s an app for that” for mobile applications. Similarly, in React/JS you will find a lot of open source projects for everything you can imagine. It’s the perfect way to create a beautiful prototype for your app.

I’m now going to paste here the final version of my files. With the knowledge you gained so far, you can follow without me.

You know what? Let’s go with dark mode. We only need to change some styles in index.css:

body {
  margin: 0;
  font-family: sans-serif;
  background: black;  color: white;}

* {  box-sizing: border-box;}

We will begin with the /src/components/Timeline.jsx, which is very similar to our App component:

// Timeline.jsx
import PropTypes from 'prop-types'
import Tweet from './Tweet.jsx'
import './Timeline.css'

function Timeline({ tweets }) {
  return (
    <ul className="timeline">
      {tweets.map(({ id, user, created_on, content }) => (
        <li key={id} className="timeline-item">
          <Tweet user={user} createdOn={created_on}>
            {content}
          </Tweet>
        </li>
      ))}
    </ul>
  )
}

Timeline.propTypes = {
  tweets: PropTypes.array,
}

export default Timeline

This component now receives as a prop the tweets collection. For the sake of semantics, I have converted the div to an unordered list. Again, notice how we now use a key for every <li>.

Another thing to note here is how we access the tweets variable from the Timeline() function. Notice the {}. The following syntax is equivalent:

function Timeline(props) {
	const tweets = props.tweets;
}

function Timeline(props) {
	const { tweets } = props;
	...
}

function Timeline({ props }) {
	...
}

And here is its associated stylesheet /src/components/Timeline.css:

/* Timeline.css */
.timeline {
  margin: 0;
  padding: 0;
  border: 1px solid rgb(47, 51, 54);
}

.timeline-item {
  list-style: none;
  border-bottom: 1px solid rgb(47, 51, 54);
}

.timeline-item:last-child {
  border-bottom: none;
}

Now let’s add the Avatar component in /src/components/Avatar.jsx:

// Avatar.jsx
import PropTypes from 'prop-types'
import './Avatar.css'

function Avatar({ name = '' }) {
  return <div className="avatar">{name.charAt(0)}</div>
}

Avatar.propTypes = {
  name: PropTypes.string,
}

export default Avatar

This basically doesn’t display the image of the user, but it just renders the first letter of their username. Having access to profile images requires access to the X developer api. I thought this project is already too much for people who start with React and I didn’t want to introduce extra complexity. In a future post we will learn how to consume apis, by implementing more complex React applications.

Here’s the associated stylesheet /src/components/Avatar.css:

/* Avatar.css */
.avatar {
  border-radius: 50%;
  background-color: rgb(29, 161, 242);
  width: 50px;
  height: 50px;
  margin-right: 10px;
  flex: 0 0 auto;
  text-align: center;
  line-height: 50px;
  font-size: 1.3em;
  font-weight: 200;
  text-transform: uppercase;
}

We will now consume the Avatar component in /src/components/Tweet.jsx:

// Tweet.jsx
import PropTypes from 'prop-types'
import Avatar from './Avatar'
import './Tweet.css'

function Tweet(props) {
  const { user, createdOn, children } = props

  return (
    <div className="tweet">
      <Avatar name={user} />
      <div>
        <div className="tweet-header">
          <span className="tweet-user">@{user}</span>·
          <span className="tweet-created-on">{createdOn}</span>
        </div>
        <div className="tweet-content">{children}</div>
      </div>
    </div>
  )
}

Tweet.propTypes = {
  user: PropTypes.string,
  createdOn: PropTypes.string,
}

export default Tweet

And its associated stylesheet /src/components/Tweet.css:

/* Tweet.css */
.tweet {
  display: flex;
  ...;
}
... .tweet-content {
  padding-left: 3px;
  ...;
}

Now let’s create the compose form component in /src/components/ComposeForm.jsx:

// ComposeForm.jsx
import Avatar from './Avatar'
import './ComposeForm.css'

function ComposeForm() {
  return (
    <form className="compose-form">
      <div className="compose-form-container">
        <Avatar />
        <textarea
          className="compose-form-textarea"
          placeholder="What's happening?"
        />
      </div>
      <button className="compose-form-submit">Tweet</button>
    </form>
  )
}

export default ComposeForm

We haven’t implemented yet the functionality to tweet, but we are going to add some extra code in the following section. For now it helps to put all the layout together.

Here’s its associated stylesheet /src/components/ComposeForm.css:

/* ComposeForm.css */
.compose-form {
  display: flex;
  flex-direction: column;
  align-items: flex-end;
  padding: 10px;
  border: 1px solid rgb(47, 51, 54);
}

.compose-form-container {
  display: flex;
  width: 100%;
}

.compose-form-textarea {
  background: none;
  border: 0;
  outline: none;
  width: 100%;
  min-height: 70px;
  font-family: sans-serif;
  font-size: 1.2em;
  color: white;
}

.compose-form-submit {
  flex: 0 0 auto;
  padding: 5px 18px;
  width: auto;
  line-height: 28px;
  background-color: rgb(29, 161, 242);
  color: white;
  border-radius: 50px;
  border: 0;
  font-size: 0.9em;
  font-weight: bold;
}

Let’s put everything together into /src/components/App.jsx:

// App.jsx
import ComposeForm from './ComposeForm'
import Timeline from './Timeline'
import { FaX } from 'react-icons/fa'
import './App.css'

import tweets from '../tweets.json'

function App() {
  return (
    <div className="app">
      <FaX className="app-logo" size="2em" />
      <ComposeForm />
      <div className="separator"></div>
      <Timeline tweets={tweets} />
    </div>
  )
}

export default App

And its associated stylesheet /src/components/App.css:

/* App.css */
.app {
  max-width: 600px;
  margin: 0 auto;
  margin-top: 20px;
}

.app-logo {
  margin-bottom: 18px;
}

.separator {
  background-color: rgb(21, 24, 28);
  border: 1px solid rgb(47, 51, 54);
  border-top: 0;
  border-bottom: 0;
  height: 10px;
}

That was it. Here’s the result UI:

![images/react-twitter-clone ui.png](images/react-twitter-clone ui.png)

And your codebase will look like this: https://github.com/nicotsou/react-twitter/tree/step-3.

This is basically an idea of how we build React apps. We start from a basic structure that makes more sense at that specific moment. We give it a try for a while. Later on, new requirements will come and we may want to restructure our app. Or our app stays forever like this, which is also fine.

Don’t think too much about how to break your app in components. It’s so easy to refactor your code. Go with what you think it makes more sense. This is an art you will learn as the time goes.

In the next session we will add interactivity to our UI elements.

Adding interactivity

So far we were dealing with the layout, by breaking our application in reusable components. We managed to display a list of tweets and a form that allows the user to post a new tweet. Learning how to deal with UI elements is the half side of the story.

Now we will go a step further. We will make those components interactive. At the moment, nothing is happening when you press the tweet button. And this is exactly where we will start from.

Let’s revisit our <ComposeForm /> component. To make an input interactive in React you have to actually store its value somewhere. The library provides an api for us. It’s called state.

We can add state to any React component with a function that React provides for us. It’s called useState() and here’s how you can use it:

// useState is a part of the React library - mind the {}
import { useState } from 'react'

function SomeComponent() {
  // We define a state variable called day.
  // useState() returns a pair of getter & setter within an array.
  // We use destructuring to assing them in variables of our choice.
  // useState() accepts the initial value as a parameter.
  const [day, setDay] = useState('Monday')  //       ^  ^                   ^
  // [getter, setter]             initial value (optional)
}

This is basically a hook. It’s a kinda complicated topic that you can read more about it in the official documentation. We will come back to this topic in more detail. I have another post for you. For now, learn its api and understand how React manages state.

Ok, it’s time for a small experiment. Take a look at the following example:

// ComposeForm.jsx
import { useState } from 'react'import Avatar from './Avatar'
import './ComposeForm.css'

function ComposeForm() {
  // As we've seen before, useState() returns an array
  // of [getter, setter] that we can name as we want.
  // We set the initial value of editorValue to an empty string.
  const [editorValue, setEditorValue] = useState('')
  // Before we return anything, we log the current value
  console.log(editorValue)
  // We define a handler for the onChange event of our textarea
  const handleEditorValueChange = (e) => {    setEditorValue(e.target.value)  }
  return (
    <form className="compose-form">
      <div className="compose-form-container">
        <Avatar />
        <textarea
          value={editorValue}          onChange={handleEditorValueChange}          className="compose-form-textarea"
          placeholder="What's happening?"
        />
      </div>
      <button className="compose-form-submit">Tweet</button>
    </form>
  )
}

export default ComposeForm

Here notice that the onChange attribute of our <textarea> is assigned to the handleEditorValueChange function without calling it. In case you are not familiar with this syntax, this is a feature of JS that allows you to pass functions as plain variables.

Remember this console.log() that we put in our component? I want to show you something. Try to type a message in the textarea and check the console output:

Let’s break down what exactly is happening here:

Our component will be initially rendered. In the very beginning the value of our state element is an empty "" string.
The user interacts with the textarea. In every keystroke, the onChange event is being triggered, which is handled by the function handleEditorValueChange(e).
Inside the implementation of this handler function, we call setEditorValue(newValue) to update the state variable.
React re-renders the current component. Every time we update a state variable, the component gets re-rendered. That’s why you need the useState() hook.
In this second render of the <ComposeForm /> component, the value of our state variable editorValue will now contain the newly saved value.
The user presses another key and the process repeats from step 2.

Every time the onChange event of the textarea is being triggered, our component is being re-rendered. That’s how React works.

At first we describe our UI with pure JS functions. Then for every event that occurs inside our component, we update the state. This causes the component tree from that point and below, to be re-rendered.

In our example above, the <ComposeForm /> component was updating its own state. But state can live in a parent component, if you pass the state variable as a prop to a children component. The state can live in the same level or above, but never below.

That’s exactly what we want to achieve with our tweets. When the user adds a new tweet, we want to append it to the list of tweets we are currently displaying on screen. But the <ComposeForm /> component doesn’t know anything about tweets. The <App /> component does. We would need to lift the state up.

But first let’s take a pause.

To implement this functionality we have to automatically generate unique ids for our tweets. This usually happens on the server, but for simplicity we are going to dynamically generate an id every time the user adds a new tweet.

There’s a very nice library for that. Stop the project and install it:

npm install nanoid --save

Ok, now back to /src/components/App.jsx:

// App.jsx
import { useState } from 'react'import { nanoid } from 'nanoid'import ComposeForm from './ComposeForm'
import Timeline from './Timeline'
import { FaX } from 'react-icons/fa'
import './App.css'

import initialTweets from '../tweets.json'
// this is a way to store the current user name
const CURRENT_USER = 'nicotsou'
function App() {
  // We now store the tweets in the state of our component
  const [tweets, setTweets] = useState(initialTweets)
  // This handler will be called when we want to post a new tweet**
  const handlePostTweet = (content) => {    const newTweet = {      content,      id: nanoid(),      created_on: Date(Date.now()),      user: CURRENT_USER,      comments_count: 0,      retweets_count: 0,      favorites_count: 0,    }    // The new tweets array is being created from the values of the    // existing one + the newly created tweet    setTweets([...tweets, newTweet])  }
  return (
    <div className="app">
      <FaX className="app-logo" size="2em" />
      <ComposeForm onSubmit={handlePostTweet} />      <div className="separator"></div>
      <Timeline tweets={tweets} />
    </div>
  )
}

export default App

Here we declared a state variable tweets and we stored the contents of the tweets.json as the initial value for our array. Previously, our tweets collection was a constant value. Now it is possible to modify its contents.

We have created the handlePostTweet() function which can append a given tweet content to the tweets array. Who is triggering this function? The tweet button of course. But this button lives in the <ComposeForm /> component.

We need a way to connect this component with this function. To deal with that, we introduced a new prop onSubmit which accepts a function. The function will be called with the new tweet content.

We will take a moment here to understand what [...tweets, newTweet] does. It’s basically generating a new array, with the contents of the existing tweets array, by appending the new tweet object. Now you may ask me, why can’t we just use the .push() method to add another item to our array? Well, my friends, this is because we try to avoid mutation.

Mutation is a common side-effect in programming. When you touch existing objects to modify their values, you are mutating them. What you have to do instead is to return a copy of your array or object.

When you work with JS objects and arrays (which are also objects), you should avoid mutations. This makes your app run slower and it can also cause some state inconsistencies. Something that was supposed to be displayed, it simply doesn’t, although its value seems to be updated.

In JS there are several array methods that can cause mutations. Always check the implementation of these methods, before you use them.

Let’s add this implementation to ComposeForm.jsx:

import PropTypes from 'prop-types'import { useState } from 'react'
import Avatar from './Avatar'
import './ComposeForm.css'

function ComposeForm({ onSubmit }) {
  const [editorValue, setEditorValue] = useState('')

  const handleEditorValueChange = (e) => {
    setEditorValue(e.target.value)
  }

  const handleSubmit = (e) => {
    // Prevent the default behavior of the form submission
    // which usually triggers a page reload
    e.preventDefault()    // Call the onSubmit function with the latest textarea value
    onSubmit(editorValue)    // Reset the textarea content
    // the user may wants to write another tweet
    setEditorValue('')  }

  return (
    <form className="compose-form" onSubmit={handleSubmit}>      <div className="compose-form-container">
        <Avatar />
        <textarea
          value={editorValue}
          onChange={handleEditorValueChange}
          className="compose-form-textarea"
          placeholder="What's happening?"
        />
      </div>
      <button className="compose-form-submit">Tweet</button>
    </form>
  )
}

ComposeForm.propTypes = {  // Mind the isRequired flag,
  // if we don't provide any function it will trhow an error
  onSubmit: PropTypes.func.isRequired,}

export default ComposeForm

We made it! Here’s how this works:

Every time we submit the form (click on the Tweet button), the <ComposeForm /> component will trigger the onSubmit() event.
This will be handled by the handlePostTweet() handler inside the <App /> component, which will update the list of tweets.
What will happen next? Well, the <App /> component will be re-rendered, because its state has changed. Of course this applies to all the components below it.
The <Timeline /> component will now display the all new tweets list, which of course, includes the tweet that was posted.

Well, there’s a catch here. We implemented the functionality to add a new tweet. But the UX is kinda annoying:

We don’t see the newly added tweet on top of the list, but we have to scroll all the way down to find it. That’s because our list of tweets is not ordered by date. We display the tweets in the same order we received them from the json file.

Here’s how you can quickly sort those tweets:

// Timeline.jsx
<ul className="timeline">
  {tweets
    .sort((a, b) => new Date(b.created_on) - new Date(a.created_on))    .map(({ id, user, created_on, content }) => (
      <li key={id} className="timeline-item">
        <Tweet user={user} createdOn={created_on}>
          {content}
        </Tweet>
      </li>
    ))}
</ul>

Another issue that we have is the fact that the dates aren’t really readable. We want something closer to how X displays the dates.

To deal with this issue, we will have to install another npm package:

npm install moment --save

I think JS folks know this one pretty well. There’s no better library to deal with dates other than moment. Here’s what we can do with it:

// Tweet.jsx
import moment from 'moment'import PropTypes from 'prop-types'
import Avatar from './Avatar'
import './Tweet.css'

function Tweet(props) {
  const { user, createdOn, children } = props

  return (
    <div className="tweet">
      <Avatar name={user} />
      <div>
        <div className="tweet-header">
          <span className="tweet-user">@{user}</span>·
          <span className="tweet-created-on">
            {moment(createdOn).fromNow()}          </span>
        </div>
        <div className="tweet-content">{children}</div>
      </div>
    </div>
  )
}

Tweet.propTypes = {
  user: PropTypes.string,
  createdOn: PropTypes.string,
}

export default Tweet

Moment reads the dates and converts them to a very readable text. Now our newly created tweet goes on top of the list:

And that, ladies and gentlemen, was the implementation of the compose tweet form. I know, it can be trickier than you initially anticipated. React can be a little hard to get in the beginning. But once you understand this reactive nature of the library, you’re gonna fall in love with its simplicity.

Your codebase will look like this after applying all the changes: https://github.com/nicotsou/react-twitter/tree/step-4.

Exercises

We are approaching the end of this post, but the fun has just started. 🤩

I have prepared a couple of simple features you can implement to our twitter clone. Most of them are easy, others may require some extra effort from your side, especially if you are a beginner in JS and Node.js. But definitely it’s a good start.

I have committed the solutions as separate branches. I encourage you to spend some time trying to implement those features, without looking on my solutions. Partially because your solution could be much better than mine. And of course, because you have to practice what you’ve learned.

Here’s what you can work on:

Display counters for comments, retweets, favorites and the share button. The last one doesn’t have any counter. You can use the icon library we have already installed. I don’t want to give you more instructions. You can place the buttons wherever you think they fit better.
Implement share button functionality. For the sake of simplicity, we can just copy the tweet on clipboard. You can also include the name of the user who posted it, for example: @nicotsou: "Tweet content".
Implement retweet button functionality. Similar to the previous one, we copy the contents of the tweet, but this time we post them as a new tweet. You can have a message like Retweeted from @nicotsou: "Tweet content".
Implement favorites: The goal here is to store when the tweet is favorite or not. If the tweet is favorited you can change the color of the icon to red and you can increase its counter by 1. When we click on the favorite button again, restore the color and the counter. To keep the implementation simple, we will only implement this in the button and not involve the tweets object. Of course if you refresh your browser window, no favorites will be kept. Not the best UX, but enough for us to get started.

Ah and it doesn’t have to finish today. Nobody is chasing you. 🥸 Take a break and come back to this post tomorrow or some other day. Try to apply what you’ve learned. It’s the best way to learn.

Deploying our app

Ok I hear you. You want to show your creation with your friends and family. Or let’s just pretend this is a final product that you eventually want to sell.

Please don’t, we don’t have the copyrights for this social media platform. 🤑 Well, do what you want. Just when they will ask you, you didn’t find this tutorial from me, ok?

To prepare our app for production we have to run the following command:

npm run build

This will keep your processor busy for a while. Once it is ready, you will find a new /build folder in your repo.

After building your app, you can serve it in your local network by running the following command:

npx serve -s build

This will serve the build folder on http://localhost:5000/.

You can find more information about hosting your app in the official create-react-app documentation.

Resources

Here are the solutions for the exercises: 1, 2, 3, 4
The official repo on GitHub.
Read everything about React in the official documentation.
We used create-react-app to build this app, which has its own documentation.

Cover Credit: Chris J. Davis

The DOM isn't scary. You just never learned it.

Wed, 28 Apr 2021 23:46:37 GMT

When you think about websites, think about trees.

The Document Object Model is a tree your browser produces to represent the UI of a website.

Every browser provides a JavaScript api for DOM operations. These are called mutations.

DOM mutations are costly and occasionally inconsistent across browsers. Furthermore, its imperative api produces perplexed code, which is difficult to scale.

That’s why there is a need for UI libraries like React, Angular and Vue.js. These modern JS technologies provide solutions to write declarative code that looks and behaves like plain HTML, by managing DOM mutations in the background.

Dealing with the DOM has troubled me a lot in the beginning of my career. I hope this article will help you understand these complicated parts. You can also use it as a refresher before joining a technical interview.

🤵🏼‍♂️ Challenge accepted? Ok, here we go…

DOM Basics

The birth of the Web. This was the first website ever created. (Source: CERN)

The Document Object Model represents a web page, which is currently loaded in a browser window.

In other words when you visit a website, your browser constructs a large JavaScript structure, which represents the contents of a website.

The DOM has a form of a family tree, with parent, children and sibling nodes.

article
|-- p
`-- ul
    |-- li
    |   `-- "text"
    `-- li

A node can be an HTML element, plain text, attribute and pretty much everything you will find in your markup.

You can navigate to the available options using the browser console. Give it a try on this website! Right click on some text and select Inspect Element.

DOM is available only on web browsers. For example, in Node.js you will not even find the object window, the outer container of the DOM. That’s why testing environments mobilize libraries that simulate DOM.

In addition to the DOM, the browser window object provides access to the following:

CSSOM, which as you guessed it represents the CSS styles and stylesheets that are attached to a website.
BOM, which hosts various helpful apis your browser provides, such as navigator, location, history, XMLHttpRequest, and the (in)famous alert() function.

What’s wrong with the api?

Ah that’s a good one, interacting with DOM elements can sometimes hurt your brain cells.

Writing code that performs low-level DOM manipulations is like opening the Pandora’s box. Operations that are simple and repetitive, take a lot of code to be implemented.

Your junior colleagues are starting hating you, your senior colleagues are starting yelling at you, your codebase is becoming more complex than your favorite Italian pasta, changes are taking more time than your promotion, debugging is as painful as the loneliness of Britney Spears, and the fact you can’t reason about your code makes you lose your sleep.

Let’s see how we can interact with DOM elements.

Consider the following HTML somewhere in <body>:

<nav>
  <ul id="navigationList">
    <li>
      <a href="/">Home</a>
    </li>
    <li>
      <a href="/contact">Contact</a>
    </li>
  </ul>
</nav>

Now let’s assume we would like to add another list item in the middle because the user has logged in. Here’s a way of approaching this task by using the DOM api:

// create a li element
const li = document.createElement('li')

// create an anchor element and set its attributes
const anchor = document.createElement('a')
anchor.setAttribute('target', '_blank')
anchor.setAttribute('href', '/settings')
anchor.appendChild(document.createTextNode('User Settings'))

// append the anchor to li
li.appendChild(anchor)

// append the li to our list (DOM mutation)
document.getElementById('my-list').lastElementChild.prepend(li)

You can run the example by yourself in Codepen.

As you can see the api is imperative which makes the developer experience to suffer. It is difficult to read the code and to perform changes.

But there is another major problem with the DOM.

What about cross-browser compatibility?

Ah yes, browsers used to have different DOM implementations and certain APIs are not available everywhere, especially the newest ones.

The story goes back to the Browser wars. For many years DOM was inadequate. The provided apis were not enough to support the complexity of our web applications. You see, it was never created to support applications in the first place. The web was about delivering content.

Mosaic was one of the first web browsers. The Evolution of the Web is a great website to learn about web history.

Many big corporations tried to force their own solutions to make the web interactive, which led to a tremendous confusion for web developers. You see, every api was different. Developing an app for Mozilla would not work for Internet Explorer.

The W3C organization was founded in 1994 to standardize browser behaviors and language features. I have to mention here that Microsoft was not willing to support this alliance for years, making Internet Explorer the most hated software, after Java applets of course.

Although things are getting better nowadays, there are still a few traps. Quite often certain apis become deprecated in favor of newer ones. There are also cases where companies refuse to implement apis, because it gets in their monopoly plans.

Chrome is a good example. Developers have access to a superset of web apis that are not available elsewhere, creating a new wave of Chrome developers. On the other side companies which are more desktop-centric like Apple, refrain from supporting those features at first place. They influence developers to write native apps for their platform, using the language and tools provided by them.

But how can you be sure if you are supposed to use an api or not?

To avoid unexpected surprises, you should always consult online references like MDN, or caniuse. In this way you can quickly distinguish any incompatibilities.

In most of the cases there is a way to use modern browser features using a Polyfill. These js scripts provide an identical api, making it easier to switch to native.

Using feature detection techniques you can distinguish whether or not to load these extra scripts.

But wait, there is another problem with the DOM.

What about performance?

Ah I almost forgot, DOM operations can be really slow.

I’m pretty sure you ran into websites with sluggy animations that destroyed the smoothness of your user experience. Compare a gif animation to a Netflix series and you’ll get what I’m trying to explain here.

The Horse In Motion was the first movie ever created and here you can see all of its frames.

An animation is performant enough when it reaches at least 60 frames per second. That’s because a common monitor has usually a refresh rate of 60Hz[^In Europe the common refresh rate is 50Hz. There are devices in the market nowadays (like the iPad Pro) which have 120Hz or even more.].

But how can we reach those 60fps? To answer this question we will have to understand how browsers are rendering a website. How they translate an HTML script to actual pixels on your monitor.

Here’s where the interesting part begins.

To render a single frame, your browser follows the steps below:

👓 Parsing: Everything starts with a GET request to the server. The server responds back, by sending the HTML, which is then being parsed to produce the DOM and CSSOM trees.
🧮 Style Recalculation: By combining those two trees, your browser produces the Rendering Tree. This is quite similar to the DOM, but it includes only what will be rendered on screen, at this specific frame.
📐 Reflow: It then builds the Layout, by converting those elements in box containers and calculating how much space they take on screen. Elements can affect others, for example the width of the body element often affects the width of its children, and so on.
🖌 Paint: Then for any of these boxes, it renders vectors and then it rasterizes them to create a pixel-friendly view.
🏞 If there are images, they need to be decoded according to their format and then resized.
🎼 Composition: Sometimes a website has different layers that are simultaneously evaluated (For example you may have a fixed <div> element). To optimize the performance, these layers are being transferred to the GPU.

Now, as we change the DOM (for example hiding an element, or setting a new background image), the browser follows most of the steps above, for every single frame. And sometimes it drops frames to ensure the app will remain responsive.

Modern browsers include Profiling tools to help you identify performance related issues.

To understand the performance of your application and how it’s affected by your changes, you can use the profiling tools.

Keeping a web application responsive at any given moment, and especially performing a fast initial load, is critical for reaching an acceptable user experience.

Ok that was it. Now you know why technologies like React exist. Now let’s see how Virtual DOM fixes those issues.

And the fun starts

Well, now you know.

For example, React utilizes plain render() functions that describe how the UI looks like, at any given state. When the state changes, the function will be invoked again and its associated UI will be re-rendered.

To automate this process, React keeps a clone of the DOM in memory. They call it Virtual DOM. It’s way smaller than the actual DOM.

React performs DOM mutations in memory, as an intermediate step. Then, it frequently updates the real DOM only in the parts that have actually changed.

To ensure this is performant enough (60fps), a pretty sophisticated “diffing” algorithm is used. The DOM updates are also being batched, to avoid expensive page repaints, which are forcing the browser to re-evaluate the styles of the page for every single frame.

Virtual DOM makes React extremely performant, while providing an incredible developer experience.

This is not a React exclusive feature. Vue.js and Ember.js have their own implementations.

Angular on the other side introduced a concept called Incremental DOM. Compared to Virtual DOM, it has a low memory footprint and it is tree-shakeable. This makes it ideal for mobile application development. Although it’s considered slower, it can outperform the Virtual DOM in certain cases.

That’s all folks

We reviewed how DOM works under the hood and we explained why mutations are making a web application slow. Then we discovered how React handles DOM mutations with Virtual DOM.

As a JavaScript developer who cares about your craft, you should be familiar with those topics. Learn the DOM api. Stop using your favorite framework or library for a while and focus on building an app with plain vanilla JS. This experiment will make you more confident using those tools.

🏅 Achievement unlocked.

Cover Credit: @matthew_t_rader

The playlist that writes my code

Tue, 20 Apr 2021 23:46:37 GMT

There are several people, including myself, who enjoy listening to music while working. If you also belong to this group, keep reading. I have something for you.

Since music accompanies me for many hours per day, I get easily bored listening to the same tracks again and again. Radio is playing the same playlists every day. And you can’t escape from these tracks anyway. They play everywhere.

Discovering good music is a difficult process. There are times streaming services suggest nice tracks, because the AI works as advertised. But most of the times the playlists they produce are monotonous and boring.

In the last couple of years I collect the tracks that I like in Spotify. I curate songs that help me concentrate, that have something to say, that don’t distract you from working on your craft. New sounds from electronic, indie, soul, jazz and various other scenes.

My series is called “Cherry pick” and I try to publish a new playlist every month, when time permits. Here’s a sneak preview of what to expect:

Sounds interesting? Make sure you follow me on X so that you get notified when I release a new playlist.

Do you have any good music to suggest? DM me the song or create your own public playlist. I would be really happy to listen to something new.

Stay tuned for more. 🤗

Cover Credit: @blocks

Why I became a software engineer

Sun, 21 Mar 2021 22:12:00 GMT

No, seriously now, why did you become a software engineer?

Was it the beauty of the algorithms? The intelligence of the design patterns? The mysteriously blinking lights in server rooms? The revolution of technology and how it improves our lives? The happiness to see other people react to your creations? The agile manifest? The money they promised you? The feeling you helped the world become a better place? The need to have a job? The dirty hacks you invent to deal with something you don’t know? The fact you will never be without a job? The coffee you drink in your breaks? The dream to become the cockiest boss alive? Was it your mom?

Can you easily tell what your main driver was? Do you think it still drives you today or was there something you lost in the process?

I have a story to share. It’s gonna take some time. I will let you prepare a beverage first. Today’s special hot chocolate with whipped cream. Ready? Ok, here we go…

My midlife crisis started earlier than usual. One day I woke up and all of a sudden various philosophical questions besieged my brain.

Who am I? What am I good at? What I am not good at? How can I contribute to this world and how far am I to make my dreams come true? Am I doing the right job? Am I gonna be successful? What is success anyway? Are we gonna be friends again?

I felt like something was missing from my life. Something I wanted so badly and I didn’t know what. Nothing was giving me joy anymore. The same job. The same place. The same people. The same routine.

In the beginning, I thought, it wasn’t really necessary to put myself in this trouble. I believed this wasn’t a healthy habit for me. I tried to escape these dark thoughts. Why do you have to feel bad when you are living like a king? You are a software engineer, you have a very nice job, you are working on high-scale projects and the list goes on. Why don’t you just post another selfie to tell the world how happy this burger makes you feel? You can find multiple ways to distract your brain. But can you escape these feelings?

No, you can’t! The more you try to ignore a feeling, the stronger it gets. And you find yourself drowning in this endless feed, that never gives you any satisfaction anymore. I knew I had to deal with it. I knew I had to change something.

So I did what everybody else does. I opened YouTube and I watched every self-improvement video ever created. You know this feeling when you are not motivated to do anything but you waste your time watching videos about motivation. We’ve all been there. It took me plenty of time to actually try the practices I was watching. And this is when the fun starts.

I want to share with you what worked best for me. It’s an easy exercise you can try at home. Spoiler alert: It turned out these thoughts I had from the very beginning were really healthy. I feel very thankful I had to go through all this. In fact, this blog would never be created otherwise.

Credit: Alec Favale

Another day was about to end. I was home. Everybody was. The city was empty because of the pandemic. I had the windows closed because I was afraid of the zombies. Better to be prepared for anything. You can’t play games with 2020. I was bored and lost in self-improvement blogs. Suddenly I read about this mind-blowing idea.

I opened a portal through time and I asked my young self how he feels watching me in this moment of my life. Was he happy with my progress so far? Was this the future he was dreaming about?

It worked! I was able to see my teenage self. He was studying math in my green-painted room. My first thought was pretty obvious. Damn my hair needed an extreme makeover. Later on, I started talking to him.

At first, he was scared. Not because I was able to communicate with him in the future, he was actually thrilled this is possible. He was shocked as I was giving him an update about his future. I will never forget the words he used to describe it.

“Man what the f*ck are you doing? Are you f*cking crazy?”

The guy had a point, so I let him speak. I listened very carefully to the things he had to say. In order to transfer his message, I have to go back to where all this started.

“Oh great, I know where this is going. He will write the story of his life again.”

“It’s a personal blog, of course, I have to write about my life, what else should I write about?”

“Please make it quick. It’s hard to keep my eyes open with all this drama.”

“I will if you let me write. I thought I’m done with you when I stopped writing my previous blog. How the hell you have survived all these years?”

“I thought you’d stopped writing blogs that nobody is willing to read, but I lost my faith the moment you started opening portals and talking to yourself.”

“Ok mister, you got it. I will write the story of my whole life with all the unnecessary details I can think of. I will use as many words as I can. And you know what, you can’t escape reading it, because you are a part of me. In fact, you will read it multiple times until I am happy publishing it.”

”…”

“Yeah, remember this day the next time you will think to interrupt me again.”

Credit: JD X

When I was a kid, I had an obsession with electronic devices and especially those that had screens. SONY Trinitron TVs, VHS, calculators, CRT monitors, LCD panels and retina displays.

I was observing UI interfaces in every possible format. When everybody was watching a trailer for a movie, I was checking the motion graphics. When everyone was refusing to switch from MS DOS to Windows, I was extremely excited with the user interface and the endless possibilities that came along with it. When everyone was bored waiting for a game to load on PlayStation, my mind was running on how they made this loading screen look so nice. It was just so cool!

School years were lazy. All I wanted to do was to go back home and turn on my PC. I loved video games. I wanted to play every video game ever created. It was fascinating to watch technology evolve so rapidly. From text-based adventures to Myst and Syberia. From green console terminals to 3dfx. Video games were pushing metal to the maximum. Plus, it was really a pleasure, to save the universe with your friends.

I had an interesting hobby back then. I used to buy textbooks, flip their cover and create albums by cutting off pictures from magazines. Later on I started making my own fake computer magazines. Yes, as an only child, I did have plenty of time to spend. Other kids had imaginary friends, I had imaginary magazines!

And then the web arrives and changes everything.

It was very slow to connect and files were taking hours to download. Images were considered a luxury. Platforms like Blogspot and WordPress were getting popular. It was easy for someone without any technical skills, like myself, to create their precious website.

I started a personal blog about video games and technology using Yahoo! Geocities. For the first time, someone could read my articles. It wasn’t a successful one, depending on the traffic, but it helped me to expose myself to many activities.

I had to play many roles. Coding, storytelling, video editing, graphic design and the list goes on. I was constantly searching for ways to improve my craft. Reading people’s comments and adapting my work according to their feedback. I learned programming by myself before I started my IT studies. Or at least something I was calling programming.

I also made some good friends in the process. People I never met in person until today. We had a lot of interests in common. You see, I couldn’t find schoolmates with the same curiosity about computers. And vice versa. It was strange to me that nobody was excited as I was.

But I was still captivated by user interfaces. This time on the web. Something inside me was making that click again.

It’s those pixels you can’t take your eyes off. All these little details that fit together perfectly.

It’s like a living piece of art. You start with an empty canvas. You combine different elements together to construct a composition. You choose the tools, and the language and basically you make decisions about every single element. You deal with the technical limitations and any other problems you may face along the way. You try to keep it modern and easy to navigate.

I can’t explain what was keeping me up endless hours working on my blog, without getting anything in return. I didn’t care about money or fame. I didn’t care how many visitors I will reach. It was just my creative space. I was feeling good. I was myself.

Credit: Florian Krumm

My career as a software developer was a nice continuation of this story. It combines many of the things I like to do. It’s not only a job to me, it’s my hobby too. And I was lucky. Very lucky. It proved to be one of the best in-demand jobs.

But trust me, it wasn’t easy to stay in this path. I made plenty of risky choices in my life to retain my ambition. You see, back then IT wasn’t the hottest place to work. Computers were neither cool nor popular as today. Today if you are a software engineer it’s considered kinda cool, back then it was the hobby of the geeks.

This desire to make my hobby a profession forced me to take risky decisions in my life. I refused to work for our family business. I resigned from jobs in profitable companies, for positions that were closer to what I wanted to work on. There was a period I was working 12 hours a day, coding personal projects right after my regular job. For almost two years I was working (almost) without getting paid. But I didn’t care back then.

I wanted to earn some experience. I knew this would be the best deal for me. I would never have to work anymore.

Going for what you love is the best decision you will ever make in your life. It pays a lot.

Now I know what was missing from my life. The reason I was not satisfied, even though I gained a lot. I lost my creativity.

It took me 3 years to build this website. I had already the design in Sketch and it was just a matter of a weekend or two to write the code. Every time I was pushing myself to work on it, something was distracting me. I tried different technologies, different ways to organize myself, different hardware, and different writing styles. But I never managed to publish it. In the end, I was always giving up. I wasn’t satisfied with anything I was producing.

It wasn’t a project a kid was making with love, persuading to become a successful developer. It was a project a “successful” developer was making with fear, persuading not to be perceived as a kid. And guess what. He was constantly failing.

Now let’s take some lessons from my young self.

Find what you love to do. Put your heart and soul into it. Make it your profession. You need a job that embodies who you are. Expose yourself to new ideas, learn new things, meet people who share the same passion, and take more risks.

If you haven’t found yet what drives you, I have a tip for you. Take an empty piece of paper. Write down what drives you, what are you curious about. What makes you lose the sense of time? What are the tasks you are willing to do that everybody else doesn’t?

Now you have to find the courage and the time to work on it.

Start simple. Schedule the time that you’ll spend working on your craft, without any interruptions. No internet, no phones, no messages and no people around you. One hour at a time is enough. Don’t set any goals. Just let yourself free.

You will see your motivation will increase as time goes on. You will find more interesting things to work on. You will meet inspiring people and at the same time, you will inspire others. You will leave your comfort zone.

Working on what you love will give you the courage to carry on. You will be confident to take risks you weren’t able to take before. To quit this boring job. To start a business. To produce something good. To be you.

Scary isn’t it? Just give it a try. You don’t have anything to lose.

The opposite of love is fear, not hate.

Cover Credit: Luca Bravo

TLTR; Declarative UI

Sat, 20 Mar 2021 23:46:37 GMT

Declarative programming makes your code more concise, easier to read and reason about and reduces side effects.

JavaScript has function scope, meaning that any variable you declare inside a function is not accessible outside this function:

Procedural and object-oriented are forms of imperative programming, which implement algorithms in explicit steps. React embraces functional programming which is a form of declarative programming.

You describe what the program must accomplish for solving a problem, rather than describing how to accomplish it.

Practical tips for writing declarative code:

Avoid loops, use array methods instead
Avoid variables, try to compose functions instead
Avoid mutating state, create new instances instead
Avoid side effects, and ensure your functions are pure
Work with the state, don’t manipulate DOM directly

Programming declarative UI is difficult. It requires abstract DOM updates because touching the DOM is a side-effect.

React is a declarative way of writing UIs. It gives you all the tools to write your markup in plain JavaScript functions. You care only about the application state and how this changes when certain events occur. Then it updates the DOM for you in an easy and predictable way.

Introduction

When you start your programming studies the first thing they teach you is variables, logical expressions and loops. Then you begin with procedural and then object-oriented programming. In other words, you learn how to imperatively write code.

This is not necessarily a bad thing. You must get familiar with how computers understand our world. In fact, declarative approaches have some sort of imperative abstraction layer underneath.

Once you start building commercial applications though things get more complex. Simplicity is king. It is essential for every developer in a team to follow the code and reason about. Our goal is to leave these machine instructions behind as much as we can and focus on writing code more perceivable by humans.

In this article, I will explain what declarative programming is and how it applies to web applications. We will see some real-life examples to help you recognize the difference between imperative.

Learning how to write declarative code completely changed my mind about programming. I hope the techniques in this article will help you as much as they helped me.

Excited? So grab a cup of ☕ coffee and come back. I will be waiting.

Humans think declaratively

At the beginning of this chapter, I gave you the following instruction:

> Grab a cup of coffee and come back

This is a declarative approach.

The imperative approach would be something like this:

> Go to the kitchen
> Turn on the coffee machine
> Create an instance of a cup
> Put the cup under the coffee machine
> Press the Espresso button
> Wait for the process to finish
> Turn off the machine
> Take the cup of coffee
> Come back to this screen

We can put this algorithm to a makeCoffee() function or create a fancy Coffee.makeCoffee() method, but the result will be the same. My life would be much easier if I just told you what to do instead of instructing you in the steps above.

Now let’s have a look at how this translates to coding.

A declarative code example

We have the following array of months:

const months = ['January', 'February', 'March', ...]

Let’s imagine that we have to create a calendar similar to the one we find in iOS:

Our first step is to modify our array to have only the first three letters of the month’s name.

Here’s a comparison between the two approaches:

// Imperative code
function getMonths(months) {
  let shortMonths = []

  for (const i = 0; i < months.length; i++) {
    shortMonths.push(months[i].slice(0, 2))
  }

  return shortMonths
}

// Declarative code
function getMonths(months) {
  return months.map((month) => month.slice(0, 2))
}

In this second approach, we leverage the map() array method and thus we avoid looping over the array items.

We avoid unnecessary variable declarations, which means less code to work with and this makes the overall approach easier to read.

We avoid touching the DOM, which means our function has no side-effects. It is also pure, with the same input it will always return the same output.

Finally, we avoid using the array.push() method which mutates our array.

It seems we’ve accomplished quite a lot in such a simple task, right? Imagine how easier our programs would be once we start applying these simple practices as much as we can.

Now let’s see how this affects the UI.

Declarative UIs

HTML is declarative by design. Consider the following markup:

<ul class="months">
  <li><button>01</button></li>
  <li><button>02</button></li>
  <li><button>03</button></li>
  ...
</ul>

You don’t need to explicitly describe step by step how the browser will be rendering this list on the screen.

CSS works similarly, the style of the class .months will be applied automatically to all the matching DOM elements which have this class.

The problem starts when you add interactivity.

The Airbnb calendar allows you to select a date period

Consider this Airbnb calendar. Two things happen when you click on a day. At first, we indicate the selected days with a black circle. Also the check in/out field gets updated with the new date range.

Below is an example of this in modern JavaScript. For the sake of simplicity, we use the class .selected to indicate one selected day at a time.

class Calendar {
  constructor(domId) {
    this.renderCalendar(domId)    this.addEventListeners(domId)  }

  handleCalendarClick(selectedDay) {
    event.preventDefault()
    this.updateView(selectedDay)
    this.updateInput(selectedDay)
  }

  addEventListeners(domId) {
    document
      .getElementById(domId)
      .querySelectorAll('li button')
      .forEach((button) => {
        const selectedDay = button.dataset.day
        button.addEventListener('click', () => {
          this.handleCalendarClick(selectedDay)
        })
      })
  }

  updateView(selectedDay) {
    const selector = `button[data-day="${selectedDay}"]`
    document.querySelector().classList.toggle('selected')
  }

  updateInput(selectedDay) {
    document.getElementById('selectedDate').value = selectedDay
  }

  renderCalendar(domId) {
    document.getElementById(domId).innerHTML = `
			<input id="selectedDate" />
				<ul>
					<li>
						<button data-day="01">01</button>
					</li>
					<li>
						<button data-day="02">02</button>
					</li>
					...
				</ul>
			`
  }
}

Try this example by yourself in JSFiddle.

As you can see this approach is imperative:

A big part of the Calendar class explicitly modifies DOM elements.
We depend on the data-day attribute to get the selected button
We no longer give the browser what to render, we instructively tell the browser how to modify the DOM.

What if we could write our application like this:

<SearchFilters>
  <DateRangeInput value={dateRange} />
  <Calendar value={dateRange} onChange={setDateRange} />
</SearchFields>

Here’s how it works:

<Calendar> displays a calendar and uses dateRange to mark the selected days. It also allows the user to modify their selection. This happens by calling the onChange() function with the updated dateRange value.
<DateRangeInput> is a special kind of input that displays the selected date range. Similar to the calendar component it can also modify the selection as the user types.
<SearchFilters> is the container div that applies the layout.

Modern UI libraries let you do exactly

React

React went popular because it lets you work with the state of your UI and it abstracts all DOM updates in a fast and predictable way. In fact, the development experience is so good that people like to write CSS in JS as well.

Think of it as a simple function:

render(state)

You are responsible to describe how your UI is being rendered to the DOM by a given state input. This object contains properties or methods that let your UI function inform you about certain events, for example, a mouse click.

For every event that occurs we update the state and this forces the application to render again:

event => state update => render

This unidirectional data flow helps you build incredibly simple applications that are easy to test and maintain.

Remember this

Your aim as a React developer is to write declarative code as much as you can. It’s like learning how to drive a supercar.

But how can we declaratively change the DOM and maintain good performance? What did you say? What is the DOM? OK this will take another coffee.

Hello World, Again!

Sun, 14 Feb 2021 22:12:00 GMT

Welcome to my world. A place where anti-patterns and dirty code create an unprecedented experience. A leap forward in boring engineering blogs, mixed with buzzwords and glossy images. This is how my narcissistic instincts come together in harmony. Yeah, you’ll be fine!

This editorial is basically a celebration of my motivation. It took me 4 years to design this website. I’m not proud of my procrastination but I’m very happy it’s finally published. A part of me feels a relief. It’s like, I hear a voice in my head screaming “No way! He finally did it!“.

I have no clue what to write as an introduction but I have a lot to share with you in the following posts. Sometimes I wake up in the middle of the night thinking about things. It always starts as a short paragraph and it ends up writing the story of my life. Lucky you!

Since I’m a software engineer this blog will host technical articles, mostly related to the technologies I’m using on a daily basis. It’s also a collection of thoughts, step-by-step tutorials and references.

I am curious how these articles will speak to you. If you have any questions or something to add, Twitter is the best way to reach out to me.

Nicotsou RSS Feed

Autocomplete is my best colleague now

The money problem

The skill atrophy trap

The pleasing machine

Agent-to-agent culture

The end of privacy

AI slop is killing the vibe

The emotional outlet nobody talks about

The validation loop

So what actually survives?

AI is Web 3.0

The broken promise of Web 3.0

AI features that nobody asked for

The $236 billion agent economy

The last app you’ll ever download

You don’t need the f*ing manual anymore

You own nothing

Your notes are the new software

The real Web 3.0

The code is fine—You are not

The Paradox We Don’t Talk About

Where This Comes From

How It Shows Up Every Day

How it can lead to burnout

The Day I Missed the News

How to reflect

A Personal Note

Most AI never ships. Here's what does.

1. Most AI product pilots fail. And fail hard.

2. AI replaces tasks, not jobs

3. There’s always a chance to hallucinate

4. Any software is prone to bugs.

5. AI is not inherently ethical.

6. Everyone is a hacker now

Finding your balance

Your LLM is generic until you make it yours

Prompt Engineering: The Art of Asking the Right Questions 📇

RAG: Bridging Knowledge Gaps 📚

Fine-tuning: Teaching the Model New Tricks 🎚️

Training Your Own LLM: The Ultimate Customization 🐉

That’s all folks! 🙌

The advanced prompting techniques worth learning

Iterative prompt evaluation 🧪

Chain-of-Thought (CoT)

Prompt Chaining

Reasoning & Acting (ReAct)

Tree of thoughts

X-Shot Prompting

That’s all folks! 🙌

Five prompt tweaks that actually make a difference

Tip #1 — Allow the model to fail. 🤷‍♀️

Tip #2 — Use leading words. 🚏

Tip #3 — Ask the model to evaluate a prompt and suggest changes 👩‍💻

Tip #4 — Use a mix of hard and soft prompts 🍬

Tip #5 — Always keep the dynamic part of a prompt at the end 💾

That’s all folks! 🙌

Structure your prompts or get noise

Step #1 — Start with a verb

Step #2 — Assign a role, job, or function

Step #3 — Provide examples

Step #4 — Describe the desired output format

Step #5 — Provide detailed guidelines

Putting everything together

That’s all folks! 🙌

Prompting has rules. Most people ignore them.

Rule #1 — Provide clear and specific instructions.

Rule #2 — Always evaluate your output.

Rule #3 — Context is king!

Rule #4 — Keep your instructions relatively short.

Rule #5 — Using references reduces guesswork

Rule #6 — Keep the conversation context consistent

Rule #7 — Be mindful of the conversation memory.

Rule #8 — Choose your words wisely.

Rule #9 — Eliminate biased language

Rule #10 — Use special syntax to express your ideas.

That’s all folks! 🙌

The art of Prompt Engineering

Your AI needs a better wingman

The Art of Talking to Machines

Tip #1 — **Allow the model to fail.** 🤷‍♀️

Tip #2 — **Use leading words.** 🚏

Tip #4 — **Use a mix of hard and soft prompts 🍬**

Rule #1 — **Provide clear and specific instructions.**

Rule #2 — **Always evaluate your output.**

Rule #4 — **Keep your instructions relatively short.**

Rule #5 — **Using references reduces guesswork**

Rule #6 — **Keep the conversation context consistent**

Rule #7 — **Be mindful of the conversation memory.**

Rule #8 — **Choose your words wisely.**

Rule #9 — **Eliminate biased language**

Rule #10 — **Use special syntax to express your ideas.**