
If you’re interested in GraphQL but haven’t had the chance to explore it directly, it's time to take action.
[Apollo Odyssey](https://www.apollographql.com/tutorials/) is the perfect solution to help you understand how it all
fits together!

<Image alt="Apollo Graph Developer - Associate certificate. Serhii Shramko" src="graphql-certificate.png" priority={true} />

## Apollo Odyssey: Free Learning Platform

The learning platform features a variety of paths, combining video tutorials with written guides that include quizzes
and code challenges for reinforcement.

<Image alt="Apollo Odyssey: Learning Platform video" src="graphql-apollo-odyssey.png" />


To earn
the [Apollo Graph Developer - Associate certification](https://www.apollographql.com/tutorials/certifications/apollo-graph-associate),
you must complete the first four paths:

- [Basics](https://www.apollographql.com/tutorials/lift-off-part1)
- [Resolvers](https://www.apollographql.com/tutorials/lift-off-part2)
- [Arguments](https://www.apollographql.com/tutorials/lift-off-part3)
- [Mutations](https://www.apollographql.com/tutorials/lift-off-part4)

> Developers who obtain this certification possess a solid foundational knowledge of GraphQL and the Apollo tool suite
> to design a schema, run an Apollo Server 4, and perform queries with Apollo Client 3 on the frontend.

I absolutely love this platform! It features fantastic videos, clear explanations, and some really good jokes that
always make me smile. 😀

## Apollo Graph Developer - Associate

As you work your way through the four required tutorials, you will be creating a real-world application called
`Catstronauts`.

<Image alt="Catstronauts project. React & GraphQL application" src="catstronauts.png" />

This project consists of a frontend client built with _TypeScript_ and _React_, alongside a backend server that utilizes
_Node.js_ as its runtime environment and [Apollo Server](https://www.apollographql.com/docs/apollo-server) as a
standalone, spec-compliant GraphQL server.

## Certification exam

- 31 multiple choice questions
- 25 correct answers required to pass

I achieved success in my test, making only a single error.

This outcome highlights the effectiveness of the course, which comprehensively addresses all relevant material,
equipping me with the confidence to approach the exam calmly.

## Graph Developer - Professional

Well, now the next step is to gain a deeper knowledge of GraphQL and
get [Graph Developer - Professional](https://www.apollographql.com/tutorials/certifications/apollo-graph-professional)
certification.

> Developers who obtain this certification demonstrate strong familiarity with Apollo Federation concepts. They can
> apply those concepts to build a federated supergraph or move an existing monolithic graph to federation.

I really commend the [Raphael Terrier](https://www.linkedin.com/in/raphaelterrier/)
and [Michelle Mabuyo](https://www.linkedin.com/in/michellemabuyo/) for developing such an excellent learning course.


Astro is a new Javascript framework, so discover what makes it special and what are its core features.

GraphQL Certified – How I earned my ‘Apollo Graph Developer - Associate’ certification for free


<Image src="linktree.jpeg" alt="My linktree" priority />

**1 hour** of work and I have my own link tree website with Astro.js and Vercel on my own subdomain.

Check out the final result: [links.shramko.dev](https://links.shramko.dev/)

## Why Astro.js?

I [wrote about Astro.js](/blog/astro), and I was impressed by its performance and ease of use.
<abbr title='In my humble opinion'>IMHO</abbr>, Astro one of the most promising and fast-growing static site generators out there.

<Image src="astro-chart.jpg" alt="Astro Framework chart on State of JS" />

### Speed and Performance

Try to check my website on [PageSpeed Insights](https://pagespeed.web.dev/analysis/https-links-shramko-dev/uemqqap32n?form_factor=mobile) and you will see that it is fast and efficient.

<Image src="lighthouse.png" alt="My webstite metrics on Google lighthouse" />


## Setting Up the Project

I started by creating a new Astro project:

```bash
pnpm create astro@latest
```

You can read small article about why I use [pnpm](/blog/pnpm) 🤘.

## Data for the Link Tree

First of all I created a data file with my links. I used a simple JSON structure:

```json:data/user.json
{
  "name": "Serhii Shramko",
  "profession": "Senior Software Engineer",
  "links": [
    {
      "url": "https://shramko.dev/",
      "icon": "url",
      "title": "Personal Portfolio",
      "description": "All my latest news and blog posts"
    },
    {
      "url": "https://github.com/Shramkoweb",
      "icon": "github",
      "title": "Github Profile",
      "description": "My Github"
    }
  ]
}
```

This approach allows me to easily add, remove, or update links without changing the HTML structure.

## Layout and File Structure

Astro.js allow use simple file structure. And for this project I don't need complex structure. I created an index page:

```jsx:pages/index.astro
---
import Layout from '../layouts/Layout.astro';
import Profile from '../components/Profile.astro';
import List from '../components/List.astro';
// Simple component that renders the main layout, the profile, and the list of links.
---

<Layout title="Link tree | Serhii Shramko">
    <main class="container" id="container">
        <Profile />
        <List />
    </main>
</Layout>
```

```jsx:components/Link.astro
---
import Instagram from "./icons/instagram.astro";
import Linkedin from "./icons/linkedin.astro";
import Url from "./icons/url.astro";
import Youtube from "./icons/youtube.astro";
import Pdf from "./icons/pdf.astro";
import Github from "./icons/github.astro";

interface Props {
    icon: string;
    title: string;
    description: string;
    url: string;
}

const { icon, title, description, url } = Astro.props;
---

<a href={url} class="link" target="_blank">
    <span class="link__icon">
        {icon === 'instagram' && <Instagram />}
        {icon === 'linkedin' && <Linkedin />}
        {icon === 'url' && <Url />}
        {icon === 'youtube' && <Youtube />}
        {icon === 'github' && <Github />}
        {icon === 'pdf' && <Pdf />}
    </span>

    <div class="link__content">
        <h2 class="link__title">{title}</h2>
        <p class="link__description">{description}</p>
    </div>
</a>
```

Astro.js allows you to create components from svg code. I created a separate component for each icon:

```jsx:components/icons/github.astro
<svg xmlns="http://www.w3.org/2000/svg" width="800" height="800" viewBox="0 0 20 20"></svg>
```

## Analytics

Almost done. Just add Vercel Analytics to the project.

<Image src="astro-analytics.jpg" alt="Analytics on vercel" />

```bash
pnpm add @astrojs/vercel
pnpm add @vercel/analytics
```

```js:astro.config.mjs
import { defineConfig } from 'astro/config';
import vercel from '@astrojs/vercel/serverless';

// https://astro.build/config
export default defineConfig({
    output: 'server',
    adapter: vercel({
        webAnalytics: { enabled: true }
    }),
});
```

## Deploying to Vercel

[Vercel makes deploying](https://vercel.com/docs/frameworks/astro) Astro projects a breeze. Here's how I did it:

1. I pushed my project to a GitHub repository.
2. I connected my Vercel account to my GitHub account.
3. In the Vercel dashboard, I clicked "New Project" and selected my link tree repository.
4. Vercel automatically detected that it was an Astro project and suggested the correct build settings.
5. I clicked "Deploy" and waited for the magic to happen!

## Custom Domain with Vercel Subdomains

<Image src="vercel-domain.jpg" alt="Domain on vercel" />


To use my custom domain with Vercel, I followed these steps:

1. In the Vercel project settings, I navigated to the "Domains" section.
2. I added my custom domain: `links.shramko.dev`.
3. Done! Vercel automatically set up the necessary DNS records for me.

## Conclusion

Building a link tree with Astro.js and deploying it on Vercel was a smooth and enjoyable process. I spent no more than
an hour and got a fast, efficient, and visually appealing website that and try new technologies.

Sounds great, right? 🌲


Learn how to build a fast, efficient link tree website using Astro.js, deploy it with Vercel, set up a custom subdomain, and implement Vercel Analytics for performance insights.

Building a Link Tree with Astro.js and Vercel: A Step-by-Step Guide


## ❌ Problem

In my opinion, one of the most important tasks when writing code is to make it as simple and understandable as possible.
There are even principles in programming aimed at this - [KISS](https://en.wikipedia.org/wiki/KISS_principle).

You can often see such code with a lot of `if`, and `switch` statements in tutorials or answers on StackOverflow:

```js
function handleUserMove(direction) {
  if (direction === 'north') {
    movePlayerTo("north");
  } else if (direction === 'east') {
    movePlayerTo("east");
  } else if (direction === 'south') {
    movePlayerTo("south");
  } else if (direction === 'west') {
    movePlayerTo("west");
  } else {
    console.error("Unknown direction");
  }
}
```

If we had more conditionals who know how long this `if/else` statement could get 🤯, and it's not very dynamic.

We can use a `switch` statement:

```js
function handleUserMove(direction) {
  switch (direction) {
    case "north":
      movePlayerTo("north");
      break;
    case "east":
      movePlayerTo("east");
      break;
    case "south":
      movePlayerTo("south");
      break;
    case "west":
      movePlayerTo("west");
      break;
    default:
      console.error("Unknown direction");
  }
}
```

Although there is a little more code, `switch` itself describes the dispatching process more explicitly, but we write a
lot of static (control) code, and we must not forget about `break`. Too complicated for such a simple task.

## ✅ Solution

So what can we do to simplify it?

```js
const userInputToDirection = {
  north: movePlayer("north"),
  east: movePlayer("east"),
  south: movePlayer("south"),
  west: movePlayer("west")
}

function handleUserMove(direction) {
  userInputToDirection[direction]();
}
```

This option is better than the previous two for several reasons:

- It is shorter
- It is more flexible. Conditional constructs are static code that cannot be changed without rewriting the program
  itself.
- With
  the [Single Responsibility Principle (SRP)](https://www.freecodecamp.org/news/solid-principles-single-responsibility-principle-explained)
  , we have separated the execution function of our `handleUserMove` business logic from the direction determination
  logic.

Conditional constructs are static code that cannot be changed without rewriting the program itself.
But data is a completely different matter.
With this approach, it is easy to add new behavior without changing the application code `handleUserMove` itself.

## Real example

For example, in Next.js applications, you can
configure [next.config.js](https://nextjs.org/docs/pages/api-reference/config/next-config-js) and the code there looks
like this:

```js
const nextConfig = {
  /* Next.js config options here */
}

let resultConfig;

if (process.env.NODE_ENV === 'development') {
  resultConfig = withBundleAnalyzer(nextConfig);
} else if (process.env.NODE_ENV === 'production') {
  resultConfig = withSentryConfig(nextConfig);
} else if (process.env.NODE_ENV === 'test') {
  resultConfig = nextConfig;
}

module.exports = resultConfig;
```

With new knowledge, we can rewrite it like this:

```js
const nextConfigByEnv = {
  development: withBundleAnalyzer(nextConfig),
  production: withSentryConfig(nextConfig),
  test: nextConfig,
};

module.exports = nextConfigByEnv[process.env.NODE_ENV];
```

Will it look and read much better? I use [dispatch tables](/blog/introducing-the-new-shramko.dev#monitoring-with-sentry) in my projects, and I can say that it is a very convenient.

## Useful links

- [Example in CLI parser app](https://github.com/Shramkoweb/CLI-diff-generator/blob/develop/src/parsers.js#L31)
- [Naming Conventions for Key-Value Maps](https://softwareas.com/naming-conventions-for-key-value-maps/)
- [Dispatch table](https://en.wikipedia.org/wiki/Dispatch_table)


Dispatch Tables in JavaScript: A Clean Code Approach


Let’s talk about version numbers in your `package.json`. You’ve probably seen versions like `1.2.3` or `^4.5.0`—but what
do they *actually* mean?

<Image src="semver.jpg" alt="but it works on *my* machine  joke" />

---

## **SemVer: The Three-Number System That Keeps Everyone Sane**

Semantic Versioning (SemVer) is just a fancy way of saying:  
**“Hey, let’s use version numbers to tell people what *kind* of changes we made.”**

Versions look like `x.y.z`:

- **Major (x)**: Big changes that might break your code. *Example:* Removing a feature your app relies on.
- **Minor (y)**: New stuff that won’t wreck existing code. *Example:* Adding a cool new function.
- **Patch (z)**: Quiet fixes for bugs or security holes. *Example:* Fixing a crash when you type `null`.

Think of it like home renovations:

- **Major** = Tearing down a wall (big impact).
- **Minor** = Adding a new room (no harm done).
- **Patch** = Fixing a leaky faucet (everyone’s happy).

---

## **Why Should You Care?**

Because npm uses these numbers to decide which updates are safe to install automatically. If everyone follows SemVer,
your app won’t suddenly break when you run `npm update`.

---

## **The Secret Symbols in Your package.json**

Those weird characters like `^` and `~` in your dependencies? They’re just rules for npm. Here’s what they *really*
mean:

- **`^1.2.3`** = “New features and fixes are okay, but don’t change anything big!”  
  *(Updates to 1.3.0 or 1.2.4 are fine. Won’t jump to 2.0.0.)*

- **`~1.2.3`** = “Only tiny fixes, please.”  
  *(Updates to 1.2.4 are okay. Won’t go to 1.3.0.)*

- **`>` or `>=`** = “Give me anything newer than this.”
- **`<` or `<=`** = “Nothing newer than this, thanks.”
- **`1.2.3` - `1.5.0`** = “I’ll take any version between these two.”
- **`||`** = “Either version A *or* version B works.”

**No symbol?** Example: `"lodash": "4.17.21"` means *“Only this exact version. Don’t change a thing!”*

---

## **Real-World Tips for Humans**

1. **Start with `^`** for most dependencies. It’s the safest way to get bug fixes and new features without surprises.
2. **Use exact versions** for critical packages (like React or Vue) where unexpected changes could ruin your day.
3. **Check `npm outdated` weekly** to see which packages have updates. It’s like a to-do list for your app’s health.
4. **Commit `package-lock.json`** to avoid “but it works on *my* machine” moments. This file locks down every tiny
   detail.

<Image src="ops.jpg" alt="but it works on *my* machine  joke" />

## **When Things Go Sideways**

- **Broke after an update?** Check if a major version sneaked in. Temporarily pin the version <br/>`"package": "1.2.3"`
  until you fix things.
- **Confused by symbols?** Use [semver.npmjs.com](https://semver.npmjs.com/) to test what versions your rules allow.

---

## **Quick Cheat Sheet**

| Symbol   | What It Means                             |  
|----------|-------------------------------------------|  
| `^1.2.3` | “Keep me up to date, but no big changes!” |  
| `~1.2.3` | “Only bug fixes, please.”                 |  
| `1.2.x`  | “Any patch version for 1.2.”              |  

---

## **Wrapping Up**

SemVer isn’t about memorizing rules—it’s about communicating changes clearly. Use `^` for flexibility, `~` for caution,
and exact versions when stability matters. <br/>And always, *always* check your `package-lock.json` into Git.

**Try this now:**

```bash  
npm outdated  
```  

See what updates are waiting? Update one with `npm update package-name` and see if your app still works. You’ve got
this! 🛠️

---  

*P.S. Sharing is caring. Forward this to a teammate who still edits `package.json` versions by hand. 😉*


A friendly, practical guide to SemVer in npm. Learn versioning rules, avoid dependency chaos, and manage updates with confidence.

Mastering npm and Semantic Versioning for Smarter Development


Writing clean, maintainable JavaScript isn't just about making your code work - it's about making it understandable. In
this comprehensive guide, we'll explore the essential naming conventions that can transform your JavaScript code from
merely functional to professionally polished.

## Why Naming Matters in JavaScript

Every time you write code, you're not just writing it for the computer - you're writing it for other developers (
**including your future self** ). Good naming conventions serve as a form of documentation, making your code self-explanatory
and reducing the cognitive load required to understand it.

## Core Principles of JavaScript Naming

### 1. Consistency Is Key

The most fundamental rule of naming in JavaScript is maintaining consistency throughout your project. Whether you choose
camelCase or snake_case, stick to it. Here's why:

- Reduces cognitive overhead for developers
- Makes code more predictable
- Simplifies maintenance and refactoring
- Improves team collaboration

### 2. Language Matters

While JavaScript is flexible enough to allow variable names in any language, stick to English. This ensures:

- Universal code readability
- Easier collaboration with international teams
- Better integration with existing codebases

### 3. The Case for Different Cases

JavaScript uses multiple naming conventions depending on the context:

- `camelCase` for variables, functions, and methods
- `PascalCase` for classes and constructor functions
- `UPPER_SNAKE_CASE` for constants
- `kebab-case` typically for CSS classes and HTML attributes

JavaScript’s built-in APIs use camelCase (e.g., getElementById), PascalCase for classes (e.g., Date), and UPPER_SNAKE_CASE for constants (e.g., Math.PI). Align your code with these patterns.

## Practical Naming Guidelines

### Variables and Functions

#### Boolean Variables

Boolean variables should start with an affirmative prefix, typically 'is' or 'has':

```javascript
// Bad ❌
const active = true;
const notAllowed = !user.checkAccess();

// Good ✅
const isActive = true;
const hasPermission = user.checkAccess();
```

> Another thing to remember at the conference is that the affirmative prefix shouldn't include a negation. This is because the negation operator (!) is most commonly used with Boolean values. So, a value named something like 'isNotAllowed' with the negation applied to it, '!isNotAllowed', can be quite misleading.

Naming recommendations for Boolean from [W3C](https://w3ctag.github.io/design-principles/#naming-booleans).

#### Functions and Methods

Function names should be verbs that clearly describe their action:

```javascript
// Bad ❌
function userData() {}

function total() {}

// Good ✅
function getUserData() {}

function calculateTotal() {}
```

### Collections and Arrays

Use plural nouns for arrays and collections:

```javascript
// Bad ❌
const userRoleList = ['admin', 'editor', 'viewer'];
const activeUserArr = new Set();

// Good ✅
const userRoles = ['admin', 'editor', 'viewer'];
const activeUsers = new Set();
```

### Classes and Objects

#### Class Names

Classes should use PascalCase and be noun phrases:

```javascript
// Bad ❌
class userService {
  constructor() {}
}

// Good ✅
class UserService {
  constructor() {}
}
```

#### Class Members

Avoid repeating the class name in member names:

```javascript
// Bad ❌
class UserProfile {
  updateUserProfile() {}

  deleteUserProfile() {}
}

// Good ✅
class UserProfile {
  update() {}

  delete() {}
}
```

### Constants and Enums

#### Constants

Use UPPER_SNAKE_CASE for true constants:

```javascript
// Bad ❌
const maxRetryAttempts = 3;
const apiBaseUrl = 'https://api.example.com';

// Good ✅
const MAX_RETRY_ATTEMPTS = 3;
const API_BASE_URL = 'https://api.example.com';
```

#### Enums

Use PascalCase for enum names and UPPER_SNAKE_CASE for enum values:

```javascript
// Bad ❌
const userRoles = {
  admin: 'admin',
  editor: 'editor',
  viewer: 'viewer'
};

// Good ✅
const UserRole = {
  ADMIN: 'admin',
  EDITOR: 'editor',
  VIEWER: 'viewer'
};
```

#### Maps
Also known as a dictionary data structure. This data structure is used for mapping one value to another.

```javascript
// Bad ❌
const userRole = {
  [AccountType.SUPERVISOR]: 'Supervisor',
  [AccountType.VISITOR]: 'Visitor',
}

const REDIRECTING = {
  '/teams': '/supervisor-panel',
  '/account': '/authenticate',
}

const UserPermissions = {
  [AccountType.SUPERVISOR]: [AccessLevel.USER_ADMINISTRATION, AccessLevel.TEAM_ADMINISTRATION],
  [AccountType.VISITOR]: [AccessLevel.PROFILE_MANAGEMENT],
}

// Good ✅
const userRoleToReadable = {
  [AccountType.SUPERVISOR]: 'Supervisor',
  [AccountType.VISITOR]: 'Visitor',
}

const pagePathToRedirectPath = {
  '/teams': '/supervisor-panel',
  '/account': '/authenticate',
}

const userRoleToPermissions = {
  [AccountType.SUPERVISOR]: [AccessLevel.USER_ADMINISTRATION, AccessLevel.TEAM_ADMINISTRATION],
  [AccountType.VISITOR]: [AccessLevel.PROFILE_MANAGEMENT],
}
```

## Common Pitfalls to Avoid

### 1. Including Types in Names

```javascript
// Bad ❌
const userArray = ['John', 'Jane'];
const nameString = 'John';

// Good ✅
const users = ['John', 'Jane'];
const name = 'John';
```

### 2. Ambiguous Abbreviations

```javascript
// Bad ❌
const usr = getUser();
const pwd = 'secret';

// Good ✅
const user = getUser();
const password = 'secret';
```

### 3. Inconsistent Naming Patterns

```javascript
// Bad ❌
const get_user = () => {};
const fetchData = () => {};
const retrieve_info = () => {};

// Good ✅
const getUser = () => {};
const fetchData = () => {};
const retrieveInfo = () => {};
```

### 4. Different Languages
```javascript
// Bad ❌
const ユーザー名 = "John";

// Good ✅
const userName = "John";
```

## Types & Interfaces

Names of types and interfaces should be written in `PascalCase` notation.

```typescript
// Bad  ❌
type TUser = {
  firstName: string
  lastName: string
}

interface userServiceInterface {
  findByEmail: (email: string) => User
}

// Good ✅
type User = {
  firstName: string
  lastName: string
}

interface UserServiceContract {
  findByEmail: (email: string) => User
}

interface IUserService {
  findByEmail: (email: string) => User
}
```

> When engineering teams choose to leverage both class-based types and abstract definitions within the same project, best practices suggest adding a distinguishing marker to the abstract definitions. Common prefix choices include `T` and `Contract`.

## Tools for Maintaining Naming Conventions

To help maintain consistent naming conventions, consider using:

1. [ESLint](https://eslint.org/) with naming convention rules
2. [Prettier](https://prettier.io/) for consistent formatting
3. IDE extensions for code style enforcement
4. Team code review guidelines focused on naming

## Time Tested Naming Naming Conventions
- [Google TypeScript Style Guide](https://google.github.io/styleguide/tsguide.html#naming)
- [Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript?tab=readme-ov-file#naming-conventions) 

## Conclusion

Good naming conventions are more than just style preferences - they're a fundamental aspect of writing maintainable,
professional JavaScript code. By following these conventions consistently and thoughtfully, you'll create code that's
easier to understand, maintain, and debug.

Remember, the goal isn't to follow these rules blindly, but to use them as guidelines to write more readable and
maintainable code. The best naming convention is one that your entire team understands and follows consistently.


Master JavaScript naming conventions with this comprehensive guide. Learn best practices for naming variables, functions, classes, and more to write cleaner, more maintainable code.

JavaScript Naming Conventions: A Complete Guide for Clean Code


Hey there, TypeScript fans!

Ever found yourself wrestling with complex types and wishing there was a better way? Well,
buckle up, because we're about to dive into the world of discriminated unions. 🚀

## What Are Discriminated Unions?

Okay, so `discriminated unions` sounds like some fancy computer science term (and yeah, it kind of is), but don't let
that scare you off. Think of them as TypeScript's way of saying, "Hey, this thing can be one of these specific types,
and here's an easy way to figure out which one it is."

It's like having a box of assorted candies, but each candy has a little flag sticking out of it telling you what flavor
it is 🍭. That flag? That's our discriminant. Neat, right?

## How to Create a Discriminated Union

Let's break it down into easy steps:

1. Come up with the different "flavors" your type can be.
2. Give each flavor a special property (our little flag) that says what it is.
3. Throw them all together into one super-type.

Here's what it looks like in action:

```typescript
interface Taco {
  kind: "taco";
  shells: number;
}

interface Burrito {
  kind: "burrito";
  length: number;
}

interface Nachos {
  kind: "nachos";
  toppings: string[];
}

type MexicanFood = Taco | Burrito | Nachos;
```

In this tasty example, `kind` is our special flag (discriminant), and `MexicanFood` is our super-type. Each specific
type
(`Taco`, `Burrito`, `Nachos`) has its own `kind` property that tells TypeScript what it is.

## Why Discriminated Unions Are Awesome

1. **TypeScript becomes psychic**: It can magically figure out which specific type you're dealing with. No more guessing
   games!

2. **Your code tells a story**: Anyone reading your code can quickly understand what's going on. It's like leaving good
   comments, but better.

3. **Catch mistakes before they happen**: TypeScript can warn you if you forget to handle a case. It's like having a
   really attentive proofreader.

4. **Your IDE becomes smarter**: Better autocomplete suggestions? Yes, please!

## Discriminated Unions in Action

Let's see how we can use our `MexicanFood` type:

```typescript
function getCalories(food: MexicanFood): number {
  switch (food.kind) {
    case "taco":
      return food.shells * 200; // TypeScript knows it's a Taco!
    case "burrito":
      return food.length * 100; // It's definitely a Burrito here
    case "nachos":
      return food.toppings.length * 50; // Nacho time!
  }
}
```

TypeScript's got your back here. It knows exactly what properties are available in each case. Pretty cool, huh?

## Pro Tip: Don't Forget Any Cases!

Want to make sure you've covered all your ? Here's a neat trick:

```typescript
function assertNever(x: never): never {
  throw new Error("Unexpected food: " + x);
}

function getCalories(food: MexicanFood): number {
  switch (food.kind) {
    case "taco":
      return food.shells * 200;
    case "burrito":
      return food.length * 100;
    case "nachos":
      return food.toppings.length * 50;
    default:
      return assertNever(food); // TypeScript will complain if you miss a case
  }
}
```

> We will discuss the `assertNever` function in a future post.

If you add a new type of food but forget to update `getCalories`, TypeScript will give you a heads-up. It's like having
a friendly reminder bot!

## Discriminated Unions of Tuples

Sometimes, you might want to use a discriminated union with tuples. Here's how you can do it:

```typescript
type User = { id: number, name: string }; // User type
type APIResponse = [success: true, data: User] | [success: false, error: string]; // Tuple type

function handleResponse(response: APIResponse): void {
  const [success, data] = response;

  if (success) {
    const { id, name } = data; // TypeScript knows it's a User!
    console.log(`User ${name} with ID ${id} found!`);
  } else {
    //  TypeScript knows it's an error string!
    console.error(`Error: ${data}`);
  }
}
````


## Discriminated Unions and Destructuring
Discriminated unions are awesome, but they're not perfect. One of the main drawbacks is that you can't use them with destructuring.

```typescript
function getCalories({ kind, shells, length, toppings }: MexicanFood): number {
  // Error: Property 'shells' does not exist on type 'MexicanFood'.
  // Error: Property 'length' does not exist on type 'MexicanFood'.
  // Error: Property 'toppings' does not exist on type 'MexicanFood'.
}
```

So, if you need to destructure your object, you'll have to do it the more explicit way:

```typescript
function getCalories(food: MexicanFood): number {
  switch (food.kind) {
    case "taco":
      const { shells } = food; // TypeScript knows it's a Taco! And you can destructure here
      return shells * 200;
    case "burrito":
      const { length } = food;
      return length * 100;
    case "nachos":
      const { toppings } = food;
      return toppings.length * 50;
  }
}
```

## Wrapping Up

[Discriminated unions](https://www.typescriptlang.org/docs/handbook/unions-and-intersections.html#discriminating-unions) in TypeScript are like the Swiss Army knife of type management. They help you write code that's
easier to understand, harder to mess up, and just plain cooler.

Next time you're dealing with a bunch of related but different types, give discriminated unions a shot. Your future
self (and your teammates) will thank you!

Happy coding, and may your types always be discriminated! 🚀✨


Discover how discriminated unions in TypeScript can help you write cleaner, safer, and more expressive code. Learn what they are, how to use them, and why they're awesome!

Serhii Shramko

Senior Software Engineer

Featured Posts

GraphQL Certified – How I earned my certification

My personal Linktree with Astro.js and Vercel

Dispatch table in javascript

Projects

Quizlet QuickList

Udemy Reset Progress

Latest posts

Semantic Versioning in npm

Why Are JavaScript Naming Conventions Important?

Discriminated Unions in TypeScript