
<Image src="exit.jpg" alt="Early return pattern in JavaScript — an exit sign representing how guard clauses let functions exit early" />

**The early return pattern** (also called guard clauses or the bouncer pattern) is a technique where you exit a function as soon as a precondition fails, instead of wrapping your main logic in nested `if` blocks. It reduces nesting, lowers cognitive load, and makes your functions dramatically easier to read.

## What Is the Early Return Pattern?

Today, while wrestling with some code, I caught myself smiling at something small but powerful. I was deep in a function that was starting to look like a staircase of if statements. Halfway through, I stopped and thought: _why am I dragging all these checks down the page when I could just step out early_?

That's when it clicked — again 🥳. Early return isn't just a coding pattern; it's a way of freeing your own brain. You handle the simplest, most obvious cases first and politely bow out of the function. Then the rest of the logic can flow without carrying the weight of those initial conditions.

```javascript
function processUser(user) {
  if (!user) return;          // nothing to process
  if (!user.isActive) return; // skip inactive users

  sendWelcomeEmail(user);
  updateAnalytics(user);
}
```

Each of those `if` lines is a **guard clause** — a check that says "if this condition isn't right, leave now." Some people call this the **fail-fast approach**: deal with the problems up front, then focus on the happy path. Others use the term **bouncer pattern** — like a bouncer checking IDs before letting you into a club.

## Before and After: Nested If vs Guard Clauses

Before I got into this habit, my functions often looked like a pile of _stacked boxes — each_ if wrapped inside another. It worked, but it forced every reader (including future me) to carry all those checks in their head all the way down.

```javascript
// ❌ Nested approach
function processUser(user) {
  if (user) {
    if (user.isActive) {
      if (user.hasProfile) {
        sendWelcomeEmail(user);
        updateAnalytics(user);
      }
    }
  }
}
```

This still runs fine, but it makes you think about conditions long after you should've moved on. Now compare:

```javascript
// ✅ Early return approach
function processUser(user) {
  if (!user) return;
  if (!user.isActive) return;
  if (!user.hasProfile) return;

  sendWelcomeEmail(user);
  updateAnalytics(user);
}
```

Once those guard clauses are in place, I don't have to `mentally juggle` those "what ifs" anymore. They're dealt with. The rest of the code reads like a straight road.

> You make the easy decisions first, exit where needed, and leave the interesting logic standing in the light. It's not just about fewer braces — it's about respecting your own attention span.

## The Arrow Anti-Pattern and the Pyramid of Doom

When nested if statements stack up, the code starts forming a visual arrow pointing to the right — this is called the **arrow anti-pattern** (or the **pyramid of doom**). Here's an extreme but not unrealistic example:

```javascript
// ❌ Arrow anti-pattern
function handlePayment(order) {
  if (order) {
    if (order.items.length > 0) {
      if (order.paymentMethod) {
        if (order.paymentMethod.isValid) {
          if (order.shippingAddress) {
            processPayment(order);
            sendConfirmation(order);
          }
        }
      }
    }
  }
}
```

Every condition pushes the real logic further to the right. By the time you reach `processPayment`, you're five levels deep. Early return flattens this completely:

```javascript
// ✅ Flat with guard clauses
function handlePayment(order) {
  if (!order) return;
  if (order.items.length === 0) return;
  if (!order.paymentMethod) return;
  if (!order.paymentMethod.isValid) return;
  if (!order.shippingAddress) return;

  processPayment(order);
  sendConfirmation(order);
}
```

Same logic, zero nesting. The intent is immediately clear: handle the edge cases, then do the work.

## Guard Clauses in Real-World JavaScript

Trivial examples are easy to agree with. Where early return really shines is in production code.

### Express.js API Handler

```javascript
app.post('/api/orders', async (req, res) => {
  if (!req.body.items?.length) {
    return res.status(400).json({ error: 'Cart is empty' });
  }

  if (!req.user) {
    return res.status(401).json({ error: 'Not authenticated' });
  }

  if (!req.user.hasPermission('create_order')) {
    return res.status(403).json({ error: 'Forbidden' });
  }

  const order = await createOrder(req.body, req.user);
  return res.status(201).json(order);
});
```

Notice the `return` before each `res.status(...)`. This is critical in Express — without it, the function keeps executing and you'll get "headers already sent" errors. More on this in the [common mistakes](#common-mistakes-with-early-return) section below.

### Form Validation

```javascript
function validateForm(data) {
  if (!data.email) return { valid: false, error: 'Email is required' };
  if (!data.email.includes('@')) return { valid: false, error: 'Invalid email' };
  if (!data.password) return { valid: false, error: 'Password is required' };
  if (data.password.length < 8) return { valid: false, error: 'Password too short' };

  return { valid: true, error: null };
}
```

Each guard returns a clear error. No nested if-else chains, no accumulated error variables.

### React Component

```jsx
function UserProfile({ user, isLoading, error }) {
  if (isLoading) return <Spinner />;
  if (error) return <ErrorMessage message={error} />;
  if (!user) return <EmptyState />;

  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.bio}</p>
    </div>
  );
}
```

React developers use this pattern constantly. Each guard clause handles a specific UI state, keeping the main render clean.

## Early Return in TypeScript

Guard clauses in TypeScript do more than improve readability — they **narrow types**. TypeScript understands that after a guard, the remaining code can assume a more specific type.

```typescript
function formatUserName(user: User | null | undefined): string {
  if (!user) return 'Anonymous';
  if (!user.firstName) return user.email;

  // TypeScript knows user is non-null and firstName exists here
  return `${user.firstName} ${user.lastName ?? ''}`.trim();
}
```

This is especially useful with [discriminated unions](/blog/discriminated-unions):

```typescript
type Result =
  | { status: 'success'; data: Order }
  | { status: 'error'; message: string }
  | { status: 'loading' };

function renderResult(result: Result) {
  if (result.status === 'loading') return <Spinner />;
  if (result.status === 'error') return <Error message={result.message} />;

  // TypeScript narrows to { status: 'success'; data: Order }
  return <OrderDetails order={result.data} />;
}
```

No type assertions needed. The guard clauses do the narrowing for you. For reusable checks, you can extract them into [type predicates](/snippets/type-predicates) — custom type guards that make the narrowing explicit.

## Early Return with Async/Await

Early return works just as well in async functions. This is an area where surprisingly few articles give concrete examples, but it's where I find guard clauses most valuable — async code is already hard enough to read without adding nesting.

```javascript
async function fetchUserOrders(userId) {
  if (!userId) return [];

  const user = await getUser(userId);
  if (!user) return [];
  if (!user.isActive) return [];

  const orders = await getOrders(user.id);
  if (!orders.length) return [];

  return orders.map(formatOrder);
}
```

Each guard prevents unnecessary `await` calls. If the user doesn't exist, we skip the orders fetch entirely. This matters for performance — not just readability.

You can combine early returns with `try/catch` as well:

```javascript
async function processWebhook(payload) {
  if (!payload?.event) return { status: 'ignored' };
  if (!isValidSignature(payload)) return { status: 'unauthorized' };

  try {
    const result = await handleEvent(payload.event, payload.data);
    return { status: 'processed', result };
  } catch (error) {
    return { status: 'failed', error: error.message };
  }
}
```

The guard clauses stay clean and outside the `try/catch` — no need to catch errors for validations that won't throw.

## Early Return vs Nested If Statements

Some developers argue that early return "splits" the function into multiple exit points, making it harder to trace. Let me address that honestly.

Nested if statements have **one** exit point — the end of the function. Early return can have **many**. So which is better?

In practice, **multiple early exits are easier to reason about** because each one is self-contained. When you see `if (!user) return;`, you know exactly what happens for that case. With nested ifs, you have to trace through the entire tree to understand every path.

That said, if your function has only one or two conditions, nesting is perfectly fine:

```javascript
// This is perfectly readable as-is
function greet(name) {
  if (name) {
    return `Hello, ${name}!`;
  }
  return 'Hello, stranger!';
}
```

Early return shines most when you have **three or more preconditions** to check.

## When NOT to Use Early Return

Early return isn't always the answer. Here are cases where I'd think twice.

**Single-expression functions.** If your function is a one-liner, a ternary or null coalesce is simpler:

```javascript
// A guard clause would be overkill here
const getDisplayName = (user) => user?.name ?? 'Anonymous';
```

**Functions with required cleanup.** If you need to release a resource — close a file handle, release a lock, clear a timer — multiple return points make it easy to forget the cleanup. Use `try/finally` to guarantee it runs:

```javascript
function readConfig(path) {
  const handle = openFile(path);
  if (!handle) return null;

  try {
    return parseFile(handle);
  } finally {
    closeFile(handle); // Always runs, even after early return
  }
}
```

**Complex state machines.** When a function has many interacting states rather than simple preconditions, a `switch` statement or a [dispatch table](/blog/dispatch-tables) is often clearer than a chain of early returns.

## Common Mistakes with Early Return

### Forgetting `return` in Express.js

This is the #1 gotcha I see in code reviews:

```javascript
// ❌ Bug: missing return
app.get('/user', async (req, res) => {
  if (!req.user) {
    res.status(401).json({ error: 'Unauthorized' });
    // Execution continues! 💥
  }

  const profile = await getProfile(req.user.id); // Crashes
  res.json(profile);
});
```

`res.json()` does **not** stop function execution. You must add `return`:

```javascript
// ✅ Fixed
if (!req.user) {
  return res.status(401).json({ error: 'Unauthorized' });
}
```

### Over-Guarding

Don't guard against things that can't happen:

```javascript
// ❌ Unnecessary — array.map always returns an array
function formatItems(items) {
  if (!items) return [];
  return items.map(format);
}
```

Only validate at system boundaries (user input, external APIs). Trust your internal code.

## Enforcing Guard Clauses with ESLint

You can configure ESLint to encourage early returns automatically:

```json
{
  "rules": {
    "no-else-return": "warn",
    "max-depth": ["warn", 3]
  }
}
```

`no-else-return` flags unnecessary `else` blocks after a `return`. `max-depth` warns when nesting exceeds 3 levels — a good nudge toward flattening your code with guard clauses.

It's funny how these little patterns sneak up on you. Today's code reminded me that writing for humans — including future me — is just as important as writing for the machine.

## Related

- [Expressions vs Statements](/blog/expressions-statements) - understand the building blocks behind guard clauses and control flow
- [Check if a URL is absolute](/snippets/is-absolute-url) - a concise example of early return for URL validation


Learn the early return pattern (guard clauses) in JavaScript and TypeScript. Reduce nesting, improve readability, and write cleaner functions with real-world examples.

Early Return Pattern in JavaScript — Guard Clauses Guide


<Image alt="A hand-drawn diagram showing Generic Type Parameters on the left and a browser window with TypeScript code for a generic identity function on the right, plus two boxes labeled U and V" src="generic.jpg" priority={true} />

When you first encounter TypeScript generics, you'll likely see something
like [this](https://www.typescriptlang.org/docs/handbook/2/generics.html#hello-world-of-generics):

```typescript
function identity<T>(arg: T): T {
  return arg;
}
```

That lonely **T** sitting there might seem mysterious.

Why T? What if you need more than one? And when should you graduate from single letters to something more descriptive?
Let's dive into the world of generic naming conventions and figure out what actually makes sense.

## The Classic Lineup: T, U, V, W

The **T** convention comes from mathematics and early programming languages. It simply stands for "Type" – nothing
fancy.
When you need multiple generic parameters, the tradition is to march through the alphabet:

```typescript
// Two types? Add U
function pair<T, U>(first: T, second: U): [T, U] {
  return [first, second];
}

// Three types? Bring in V
function triple<T, U, V>(first: T, second: U, third: V): [T, U, V] {
  return [first, second, third];
}
```

This alphabetical progression isn't arbitrary – it creates a clear, predictable pattern that developers can follow
easily. Plus, these single letters are visually distinct and don't clutter your code.

> This naming convention is common in different languages,
> like [Java](https://docs.oracle.com/javase/tutorial/java/generics/types.html) and others.

## When Single Letters Work Perfectly

For simple, general-purpose functions and utilities, single letters are your best friend:

```typescript
// Array mapping - crystal clear what T and U represent
function map<T, U>(items: T[], transform: (item: T) => U): U[] {
  return items.map(transform);
}

// Key-value pairs - K and V are intuitive
interface Dictionary<K, V> {
  [key: K]: V;
}
```

> Notice how TypeScript's own built-in utilities follow this pattern. `Pick<T, K>`, `Omit<T, K>`, `Record<K, V>` – they
> stick with meaningful single letters because the context makes their purpose obvious.

## The Case for Descriptive Names

Sometimes, though, single letters leave your future self (and your teammates) scratching their heads. That's when
descriptive names shine:

```typescript
// What are T and U supposed to represent here?
interface ApiClient<T, U> {
  get(endpoint: string): Promise<T>;
  handleError(error: U): void;
}

// Much clearer!
interface ApiClient<ResponseData, ErrorType> {
  get(endpoint: string): Promise<ResponseData>;
  handleError(error: ErrorType): void;
}
```

This is especially valuable in domain - specific code where the generic types have special meaning in your business logic.

## The Repository Pattern Example

Here's where descriptive naming really pays off:

```typescript

interface Repository<Entity, Key> {
  findById(id: Key): Promise<Entity | null>;
  save(entity: Entity): Promise<Key>;
  delete(id: Key): Promise<void>;
  findAll(): Promise<Entity[]>;
}


class UserRepository implements Repository<User, string> {
  // Implementation details...
}
```

Anyone reading this code immediately understands what **Entity** and **Key** represent.
Compare that to `Repository<T, U>` – you'd need to dig into the implementation to figure out which is which.

## The T Prefix Debate

You'll sometimes see generic parameters prefixed with T:

```typescript
interface Repository<TEntity, TKey> {
  findById(id: TKey): Promise<TEntity>;
}
```

This convention comes from [C#](https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic?view=net-9.0) and serves a purpose – it clearly marks something as a **type parameter** rather than a
**regular variable**. But it's not universally loved.

TypeScript's own standard library doesn't use the T prefix.
React components rarely use it. Many JavaScript and TypeScript projects skip it entirely:

```typescript
// Both are perfectly valid
interface Props<User, Settings> {}
interface Props<TUser, TSettings> {}
```

The choice often comes down to team preference and consistency with your existing codebase. Pick one style and stick
with it.

## Practical Guidelines

Here's what I've learned from years of writing TypeScript:

### Use single letters when:

- Writing utility functions that work with any type 
- The generic's role is obvious from context 
- You're following established patterns (like `map<T, U>`)

### Use descriptive names when:

- The generics have a specific domain meaning 
- You have multiple related type parameters 
- Code clarity would suffer with single letters

### Stay consistent:

- Whatever convention your team chooses, apply it everywhere 
- Don't mix T prefixes with non-prefixed names randomly 
- Document your team's preferred style

## Common Single-Letter Conventions

```typescript
T // Primary type parameter
U, V, W // Additional type parameters (alphabetical order)
K // Key type (in mappings, records)
V // Value type (in key-value structures)
E // Element type (in collections)
R // Return type
P // Properties/Props type
```

## Wrapping Up

- **Consistency beats perfection** – pick a style and stick with it 
- **Context is king – choose names** that make sense for your specific use case 
- **When in doubt, be descriptive** – clarity trumps brevity in complex code 
- **Follow your team's conventions** – consistency across the codebase matters most

> I love conventions and wrote a lot of articles about them.
> Check out about [conventional commits](/blog/conventional-commits) and [JavaScript Naming](/blog/javascript-naming-conventions) for more.

## Related

- [Template Literal Types](/snippets/template-literal-types) - template literal types leverage generics for powerful string patterns
- [The satisfies Operator](/snippets/satisfies-operator) - satisfies uses type inference alongside generics
- [Discriminated Unions](/blog/discriminated-unions) - combine unions with generics for type-safe patterns


Learn TypeScript generic type parameter naming conventions. Understand when to use T, K, V and when descriptive names like TKey make your code more readable.

What is a generic type parameter T in TypeScript?


### Understanding the Hidden Pitfalls of Custom Hooks in React

In a previous post we covered [How React Rerenders Works](/blog/react-rerender). But today, we'll take a closer look at
the hidden pitfalls of custom hooks in React.

<Image alt="Hand-drawn diagram showing 'Custom React Hooks' as the main title with small hook illustrations, 'useEffect ( )' written in blue text on the left, and the React logo (atomic symbol) in blue on the bottom right." src="hooks.jpg" priority={true} />

When we handle state, component re-renders, and application performance in React, custom hooks are a powerful tool that
help us keep our components clean and manageable. However, this simplicity can sometimes hide performance issues that we
may not immediately notice.

Consider a basic custom hook for managing a dropdown menu:

```jsx
const useDropdown = () => {
  const [isOpen, setIsOpen] = useState(false);

  return {
    isOpen,
    open: () => setIsOpen(true),
    close: () => setIsOpen(false),
    toggle: () => setIsOpen(prev => !prev),
  };
};
```

Using this hook in a component might look neat and clean:

```jsx
const App = () => {
  const { isOpen, toggle, close } = useDropdown();

  return (
    <div className="app-container">
      <button onClick={toggle}>Menu</button>
      {isOpen && <DropdownMenu onSelect={close} />}
      <ExpensiveChart />
      <DataGrid rows={1000} />
    </div>
  );
};
```

At first glance, this setup appears elegant—state logic neatly wrapped in the `useDropdown` hook. However, this
approach hides a subtle performance issue: whenever the dropdown visibility state changes, React re-renders the entire
`App` component, despite the state being limited to a small interaction.

> Why? You can read more about react rerenders [here](/blog/react-rerender).

### Hidden States and Re-rendering Pitfalls

Let's extend our custom hook to listen for window resize events:

```jsx
const useDropdown = () => {
  const [windowWidth, setWindowWidth] = useState(window.innerWidth);

  useEffect(() => {
    const handleResize = () => setWindowWidth(window.innerWidth);
    window.addEventListener('resize', handleResize);

    return () => window.removeEventListener('resize', handleResize);
  }, []);

  return {
    // For example, this part of the code was simplified
    isOpen: false,
    open: () => {},
    close: () => {},
    toggle: () => {},
  };
};
```

Now, every time the user resizes the window, this hook updates the state internally. Even though the window width isn't
returned or directly used, it **triggers state changes**, causing the entire `App` to re-render unnecessarily.

### Nested Hooks Can Multiply Issues

The problem worsens when custom hooks depend on other hooks indirectly. For example, consider another hook for tracking
keyboard input:

```jsx
const useKeyboardListener = () => {
  const [lastKey, setLastKey] = useState(null);

  useEffect(() => {
    const handleKeyDown = (e) => setLastKey(e.key);
    window.addEventListener('keydown', handleKeyDown);

    return () => window.removeEventListener('keydown', handleKeyDown);
  }, []);

  return lastKey;
};

const useDropdown = () => {
  useKeyboardListener();

  return {
    // For example, this part of the code was simplified
    isOpen: false,
    open: () => {},
    close: () => {},
    toggle: () => {},
  };
};
```

Even if `useDropdown` does not directly use the last key pressed, the `App` component still re-renders each time
a key is pressed, since the state is updated inside the nested hook.

> Hiding stateful logic within hooks doesn't remove their performance impact. The
> solution isn’t hiding complexity but smartly managing and isolating the state.

### How to Solve This

To avoid such issues, encapsulate state logic in smaller components:

```jsx
const Dropdown = () => {
  const { isOpen, toggle, close } = useDropdown();

  return (
    <>
      <button onClick={toggle}>Menu</button>
      {isOpen && <DropdownMenu onSelect={close} />}
    </>
  );
};
```

This ensures that the minimal required area re-renders, preventing unnecessary updates across the entire app.

> In this solution, the `Dropdown` logic moved down from `App` to its own component. I described this approach in
> [this article](/blog/react-rerender#moving-state-down).

### Key Takeaway

The key lesson: carefully handle state encapsulation within custom hooks. Keep state management local and focused to
optimize your React application's performance and responsiveness.

> P.S Memoization and other performance optimizations will be covered in future posts. Meanwhile, you can read about [Elements, Children as Props, and Re-Renders](/blog/react-elements-children).

## Related

- [useClickOutside Hook](/snippets/use-click-outside) - a practical custom hook example that applies the patterns discussed above
- [useMediaQuery Hook](/snippets/use-media-query) - another commonly used custom hook with proper cleanup


Learn about performance risks in React custom hooks, how they cause unexpected re-renders, and strategies to manage state efficiently.

Understanding the Hidden Pitfalls of Custom Hooks in React


<Image alt="React Re-Renders article cover illustration" src="react-rerender.png" priority={true} />

Hi, react [Andy](https://en.wiktionary.org/wiki/react_Andy)!

I’ve used React for over six years. I’ve noticed that even skilled programmers often struggle to grasp how React
operates behind the scenes. This can lead to inefficiencies. It affects code quality, speed, and user experience.

The documentation is great for starting with React. Many [books](https://www.roadtoreact.com/), courses, and blogs focus
on beginners. But what comes next? How can you dive deeper and really understand how it works? If you’ve been writing
React for a while, basic or
even intermediate courses may not be enough. Sadly, resources for advanced learning are limited.

That’s why I’m launching a [series of articles](/blog/category/advanced-react) to fill this knowledge gap.

## Intro to re-renders

Understanding re-renders in React is crucial for performance. You need to understand what triggers them. Know how they
move through the app. Learn what happens during a re-render and why it matters.

<Image alt="Meme about React re-renders" src="react-meme.png" />

## The problem

Imagine you're an intern at a FAANG company. Your first task is to create a new React component. You're asked to add a
simple `button` that opens a `settings panel` at the top of the dashboard.

```jsx
const Dashboard = () => {
  // Some code here
  return <div className="container">
    {/* The trigger should go somewhere here */}
    <ExpensiveDataGrid />
    <AnalyticsWidget />
    <ActivityFeed />
  </div>;
};
```

Then you implement it. The task seems straightforward. We've all done it countless times:

```jsx
const Dashboard = () => {
  // Add state
  const [isExpanded, setIsExpanded] = useState(false);

  // Everything that is returned here will be re-rendered when the state is updated
  return <div>
    {/* Add the trigger */}
    <IconButton onClick={() => setIsExpanded(true)}>
      Show settings
    </IconButton>

    {/* Add the panel */}
    {isExpanded && <SettingsPanel onDismiss={() => setIsExpanded(false)} />}

    <ExpensiveDataGrid />
    <AnalyticsWidget />
    <ActivityFeed />
  </div>;
};
```

You add [state](https://react.dev/learn/state-a-components-memory) to track if the panel is expanded or collapsed. You include
a button to change the state and render the panel
based on this state.

When you run the app, there's a noticeable delay ⏰, **almost a second** — before the panel appears.

Experienced React developers might quickly suggest.

> "You’re re-rendering the whole app. Just wrap everything in [React.memo](https://react.dev/reference/react/memo) and
> use [useCallback](https://react.dev/reference/react/useCallback) to avoid unnecessary renders."

This advice has its place, but it’s wise to pause before jumping in. In this case, memoization isn’t needed and could
hurt performance.

First, let’s take a closer look at what exactly is happening and why this delay occurs.

<Image alt="Diagram showing React component tree re-rendering when state updates" src="rerender.png" />

When we click the button, we trigger the `setIsExpanded` setter function, which updates the `isExpanded` state from `false` to
`true`. As a result, the `Dashboard` component that holds this state re-renders itself.

After the state updates and the `App` component re-renders, React must pass the new data to other dependent components.
It automatically re-renders all components that the first component shows. It keeps going down the tree until it reaches
the end.

If you visualize a typical React app as a tree structure, you will find that everything beneath the point where the
state update was initiated will be re-rendered.

> Re-rendering is crucial to understand in React.

The key point to remember is that React never re-renders components "up" the render tree. If a state update occurs in
the middle of the component tree, only the components "down" the tree will be re-rendered.

<Image alt="Diagram showing re-renders propagating down the component tree from state update" src="rerender-state.png" />

When a component is wrapped in `React.memo`, `React` will interrupt its default re-rendering process and first evaluate
whether the `props` have changed. If there are no changes to the `props`, re-renders will be halted. However, if even a
single `prop` is modified, the re-rendering will proceed as usual.

It's important to note that effectively preventing re-renders through memoization is a nuanced topic with various
considerations. For a deeper understanding, it is advisable to explore these concepts further in new articles. (Coming soon... or read about [Elements, Children as Props, and Re-Renders](/blog/react-elements-children))

<Image alt="Diagram showing how React.memo prevents unnecessary re-renders" src="react-memo.png" />


Wrapping components with `React.memo` can indeed help prevent unnecessary re-renders in certain scenarios. However, it's
important to note that using `React.memo` comes with its own set of complexities and caveats, which will be discussed in
future articles. A more effective approach is to isolate the components that rely on specific state and encapsulate both
the state and those components into a smaller, dedicated component. This can lead to improved performance and a clearer
component structure.

## Moving state down

Let's move our logic in separated component.

```jsx
const SettingsToggle = () => {
  const [isExpanded, setIsExpanded] = useState(false);

  return <>
    <IconButton onClick={() => setIsExpanded(true)}>
      Show settings
    </IconButton>

    {isExpanded && <SettingsPanel onDismiss={() => setIsExpanded(false)} />}
  </>;
};
```

And then render this new component in the `Dashboard`:

```jsx
const Dashboard = () => {
  return <div>
    {/* Our new component */}
    <SettingsToggle />

    <ExpensiveDataGrid />
    <AnalyticsWidget />
    <ActivityFeed />
  </div>;
};
```

<Image alt="Diagram showing performance improvement after moving state to a separate component" src="rerender-performance-fix.png" />

Consequently, the settings panel appears immediately. We resolved a significant performance issue using a straightforward
composition technique!


Dive into the mechanics of React re-renders — learn what causes them, how they impact performance, and how to manage them effectively.

React Re-Renders: What Triggers Them and Why


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 (e.g., when you need to [capitalize the first letter of a string](/snippets/how-to-capitalize-first-letter-of-string-in-javascript), the function name follows camelCase)
- `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.

## Related

- [CSS Class Naming Conventions](/blog/class-naming-conventions) - BEM methodology for HTML/CSS
- [Common CSS Class Names](/snippets/common-css-classes) - practical BEM class name examples


Master JavaScript naming conventions with this guide. Learn best practices for naming variables, functions, and classes to write cleaner 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! 🚀✨

## Related

- [Branded Types in TypeScript](/snippets/branded-types) - another pattern for type-safe identifiers
- [Type Predicates](/snippets/type-predicates) - use type predicates to narrow discriminated unions at runtime
- [Generic Type Parameters](/blog/generic-type-parameters) - combine generics with unions for flexible APIs


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

Discriminated Unions in TypeScript: Write Safer Code


<Image src="conventional-commits.jpg" alt="Conventional Commits. A close up of a text description on a computer screen." />

I first came across Conventional Commits during my time at [MacPaw](/about), but initially, I didn't give much thought
to these unique commit messages.
It wasn't until recently that I took a closer look and realized how much more efficient and organized they make the
development process.

Here’s why you might want to give them a try too! 😃

## What Are Conventional Commits?

Conventional Commits is a specification that provides a simple, structured convention for commit messages.
It allows to write messages that are easy to read and maintain, and which convey the specific intent behind each
change.

The conventional commit message format is straightforward. It starts with a **type**, optionally followed by a **scope
**, and a
short **description**. For example:

```bash
feat(login): add authentication with JWT
```

In this example:

- `feat` is the type of the commit, indicating a new feature.
- `login` is the scope, specifying the part of the project that is affected.
- `add authentication with JWT` is the short description of the change.

## Why Use Conventional Commits?

Using Conventional Commits offers several key benefits:

- `Consistency`: Standardized commit messages ensure that everyone on the team follows the same format, which enhances
  readability and reduces ambiguity.
- `Automation`: Tools can automatically generate change logs, version numbers, and releases based on the structured
  commit messages.
- `Collaboration`: Clear and descriptive commit messages help team members understand the history and context of
  changes, improving collaboration.
- `Compliance`: Adhering to a standardized format helps in meeting the guidelines and best practices of many open-source
  projects.

## Types of Conventional Commits

There are several predefined types of Conventional Commits that help categorize the nature of each change. Each type
indicates a specific kind of modification, making it easier to understand the impact of the commit. Here are the most
commonly used types:

- **feat**: A new feature for the user.
- **fix**: A bug fix for the user.
- **chore**: Changes that don't modify src or test files, such as updating build tasks.
- **docs**: Documentation-only changes.
- **style**: Changes that do not affect the meaning of the code (e.g., formatting, missing semicolons, etc.).
- **refactor**: A code change that neither fixes a bug nor adds a feature.
- **perf**: A code change that improves performance.
- **test**: Adding or updating tests.
- **build**: Changes that affect the build system or external dependencies (e.g., gulp, npm).
- **ci**: Changes to CI configuration files and scripts (e.g., CircleCI, Travis).
- **revert**: Reverts a previous commit.

## Cheat Sheet for Conventional Commits

<Image src="conventional-commits-cheatsheet.png" alt="Conventional Commits Cheatsheet" />

| Type     | Description                | Example                          |
|:---------|:---------------------------|:---------------------------------|
| feat     | New feature                | feat(ui): add dark mode          |
| fix      | Bug fix                    | fix(api): resolve login issue    |
| docs     | Documentation only changes | docs(readme): update setup guide |
| style    | Code style changes only    | style(css): format CSS classes   |
| refactor | Code refactoring           | refactor(auth): optimize logic   |
| perf     | Performance improvement    | perf(database): optimize queries |
| test     | Adding tests               | test(routes): add unit tests     |
| chore    | Build tool/config changes  | chore(deps): bump dependencies   |
| ci       | Continuous Integration     | ci(travis): update config        |
| revert   | Revert previous commit     | revert: rollback last change     |

## Leveraging AI with Conventional Commits

AI-powered IDEs like **JetBrains'** suite of tools enhances your workflow by intelligently suggesting commit messages
that
adhere to Conventional Commits standards. These suggestions are contextually generated based on changes you've made,
significantly streamlining the process and reducing the cognitive load of writing detailed commit messages.

### AI-Powered IDEs and Conventional Commits

JetBrains IDEs, such as IntelliJ IDEA and WebStorm, integrate [AI tools](https://www.jetbrains.com/ai-assistant/) that:

- Automatically suggest precise commit messages.
- Detect commit types (feat, fix, docs, etc.) based on changes.
- Recommend appropriate scopes, improving accuracy and efficiency.

## Examples of Conventional Commits

Understanding the theory behind Conventional Commits is one thing, but seeing how they are applied in real-world
scenarios can be extremely helpful. Below are some examples illustrating how to write effective, clear, and standardized
commit messages.

> Here example of commits from [my GitHub](https://github.com/Shramkoweb/Portfolio/commits/develop/)

### Example 1: Adding a New Feature

**Commit Message**:

```bash
feat(auth): add OAuth 2.0 authentication
```

**Explanation**:

**Type**: `feat` (indicates a new feature). <br/>
**Scope**: `auth` (specifies that the change is related to authentication). <br/>
**Description**: `add OAuth 2.0 authentication` (brief summary of the change).

### Example 2: Fixing a Bug

**Commit Message**:

```bash
fix(profile): resolve issue with avatar upload
```

**Explanation**:

**Type**: `fix` (indicates a bug fix). <br/>
**Scope**: `profile` (specifies that the change affects the profile feature). <br/>
**Description**: `resolve issue with avatar upload` (briefly describes the problem and solution).

### Example 3: Updating Documentation

**Commit Message**:

```bash
docs(readme): update installation instructions
```

**Explanation**:

**Type**: `docs` (indicates a documentation change). <br/>
**Scope**: `readme` (specifies the README file). <br/>
**Description**: `update installation instructions` (details the specific update).

### Example 4: Refactoring Code

**Commit Message**:

```bash
refactor(utils): simplify the date parsing logic
```

**Explanation**:

**Type**: `refactor` (indicates a code change that neither fixes a bug nor adds a feature). <br/>
**Scope**: `utils` (specifies that the change pertains to utility functions). <br/>
**Description**: `simplify the date parsing logic` (briefly describes the refactoring).

### Example 5: Performance Improvement

**Commit Message**:

```bash
perf(db): optimize query execution time
```

**Explanation**:

**Type**: `perf` (indicates a performance improvement). <br/>
**Scope**: `db` (specifies that the change affects the database). <br/>
**Description**: `optimize query execution time` (summarizes the performance enhancement).

### Example 6: Adding or Updating Tests

**Commit Message**:

```bash
test(router): add unit tests for routing module
```

**Explanation**:

**Type**: `test` (indicates test-related changes). <br/>
**Scope**: `router` (specifies the routing module). <br/>
**Description**: `add unit tests for routing module` (briefly describes the tests added).

### Example 7: Maintenance or Chore

**Commit Message**:

```bash
chore(deps): upgrade lodash to version 4.17.21
```

**Explanation**:

**Type**: `chore` (indicates maintenance or chores). <br/>
**Scope**: `deps` (specifies that the change pertains to dependencies). <br/>
**Description**: `upgrade lodash to version 4.17.21` (details the specific update).

### Example 8: Continuous Integration Configuration

**Commit Message**:

```bash
ci(circleci): add build step for linting
```

**Explanation**:

**Type**: `ci` (indicates changes to CI configuration). <br/>
**Scope**: `circleci` (specifies the CI service being configured). <br/>
**Description**: `add build step for linting` (briefly describes the new CI step).

### Example 9: Reverting a Previous Commit

**Commit Message**:

```bash
revert: remove OAuth 2.0 authentication

This reverts commit abc123.
```

**Explanation**:

**Type**: `revert` (indicates the commit is a revert). <br/>
**Scope**: None (reverts don't usually need a scope). <br/>
**Description**: `remove OAuth 2.0 authentication` (describes what is being reverted).
Body: This reverts commit abc123. (provides context by specifying the commit being reverted).

## Using Conventional Commits in Projects

Incorporating Conventional Commits into your projects can significantly improve code quality and team collaboration.
Here’s a step-by-step guide on how to start using Conventional Commits in your projects.

### Step 1: Educate Your Team

Before adopting Conventional Commits, ensure that everyone on your team understands its benefits and guidelines. Share
resources, conduct workshops, or organize short training sessions to help everyone get up to speed.

### Step 2: Set Up Commit Message Linting

To enforce the Conventional Commits standard, you can use tools
like [commitlint](https://github.com/conventional-changelog/commitlint) and [husky](https://typicode.github.io/husky/).
These tools help ensure that
all commit messages adhere to the predefined format.

Example Configuration:

#### Install Dependencies:

```bash
npm install --save-dev @commitlint/config-conventional @commitlint/cli husky
```

#### Configure Commitlint:

Create a new file named `commitlint.config.js` in the root of your project and add the following content:

```js
module.exports = {
  extends: ['@commitlint/config-conventional'],
};
```

#### Set Up Husky Hooks:

The `init` command simplifies setting up husky in a project. It creates a `pre-commit` script in `.husky/` and updates
the prepare script in `package.json`. Modifications can be made later to suit your workflow.

```bash
npx husky init
```

### Step 3: Use Tools and Libraries

Conventional commits can be parsed by tools, and a very nice use-case is that of generating release changelogs.

<Image src="changelog.png" alt="Changelog created from Conventional commits on GitHub page" />

#### Semantic Release:

- Automates the whole package release workflow including determining the next version number, generating the release
  notes, and publishing the package.
- [Semantic Release Documentation](https://semantic-release.gitbook.io/semantic-release)

#### Commitizen:

- A tool that prompts you to fill out the commit message with a CLI, ensuring you follow the Conventional Commits
  standard.
- [Commitizen Documentation](https://github.com/commitizen/cz-cli)

### Step 4: Continuous Integration and Continuous Deployment (CI/CD)

Integrate Conventional Commits with your `CI/CD` pipeline to automate tasks such as generating changelogs and
versioning.

Here’s how you can do it:

#### Changelog Generation:

- Use tools like standard-version to generate changelogs automatically.
- [Standard Version Documentation](https://github.com/conventional-changelog/standard-version)

#### Versioning and Releasing:

- Automate versioning and releasing using tools like Semantic Release.
- Define release steps in your CI configuration (e.g., GitHub Actions, Travis CI).

Example GitHub Actions Configuration for Semantic Release:

```yaml
name: Release
on:
  push:
    branches:
      - main
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v2
      - name: Install Node.js
        uses: actions/setup-node@v2
        with:
          node-version: 14
      - name: Install Dependencies
        run: npm install
      - name: Run Semantic Release
        run: npx semantic-release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```

## Conclusion

I hope this blog post has inspired you to delve into conventional commits.

Initially, conventional commits might seem a bit odd, and you might find yourself questioning the format as you make
commits. However, they soon become second nature, and you'll appreciate their impact on your software engineering
practices.

> Conventional commits pair well with [Semantic Versioning](/blog/npm-semantic-versioning) for automated package
> releases.

Looking for more productivity wins? I also wrote about why you should [unsubscribe from email newsletters immediately](/blog/unsubscribe-immediately) to stay focused.


Master Conventional Commits to write clear, structured commit messages. Learn the format, types like feat and fix, and how to automate changelog generation.

Conventional Commits enhance your coding practices


## Introduction

<Image src="pnpm-logo.png" alt="pnpm logo on gay background" />

I found article from Vercel
about [Projects using pnpm can now be deployed with zero configuration](https://vercel.com/changelog/projects-using-pnpm-can-now-be-deployed-with-zero-configuration)
and I wanted to try it.

## Why Migrate to pnpm?

Before diving into the migration process, it’s important to understand why pnpm is beneficial:

1. **Speed** 🚀: pnpm installs dependencies faster than npm by using a unique package linking mechanism.
2. **Disk Space** 🔎: It saves disk space by using a global store and hard links.
3. **Consistency** 💡: pnpm ensures that dependencies are installed in a way that is more consistent with the version
   specified in your `package.json`.

## Installation of pnpm

First, you need to install pnpm globally. Make sure you have the right Node.js version installed — if you manage multiple versions, [NVM](/blog/nvm) makes switching between them effortless. Then run:

```bash
brew install pnpm
```

## Migration Steps

### 1. Clean the Project

Remove the `node_modules` directory and the `package-lock.json` file. This step is crucial to ensure that there are no
leftover artifacts from npm that might interfere with pnpm.

```bash
rm -rf node_modules package-lock.json
```

### 2. Initialize pnpm

Run the following command to initialize pnpm in your project directory:

```bash
pnpm install
```

This command will create a `pnpm-lock.yaml` file and install all the dependencies listed in your `package.json`.
Understanding [how semantic versioning works in npm](/blog/npm-semantic-versioning) will help you predict exactly what gets installed.

### 3. Verify Dependency Installation

Check that all dependencies have been installed correctly by running:

```bash
pnpm list
```

This command lists all the installed dependencies and their versions. Make sure that there are no missing or outdated
packages.

<Image src="pnpm-list.png" alt="pnpm list command result in terminal" />

## Updating Scripts

### 1. Update npm Scripts

In your `package.json`, update any npm scripts to use pnpm where necessary. For example, if you have a script for
installing dependencies, change it from:

```json
"scripts": {
"install": "npm install"
}
```

to:

```json
"scripts": {
"install": "pnpm install"
}
```

### 2. Update CI/CD Pipelines

If your project uses CI/CD pipelines, ensure that the build scripts and installation commands are updated to use pnpm.
For example, in a [GitHub Actions  with pnpm](https://pnpm.io/continuous-integration) workflow, you might update the
step as follows:

```yaml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
        with:
          version: 9
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'pnpm'
      - name: Install
        run: pnpm i
      - name: Run Tests // All your CI commands
        run: pnpm run test
```

## Handling Issues and Troubleshooting

During the migration, you might encounter some issues.

> Error: Unable to locate executable file: pnpm. Please verify either the file path exists or the file can be found
> within a directory specified by the PATH environment variable. Also check the file mode to verify the file is
> executable.

I stuck with this error when I tried to run the `pnpm` command in GitHub Actions.

The solution was to use the `pnpm/action-setup@v4` before `actions/setup-node@v4`.
So simply just copy the [above code](#2-update-cicd-pipelines) and paste it in your `.yml` file.

## Conclusion

This migration helped me to reduce the time of deployment by **44%** and the size of `node_modules` by **5%**.

<Image src="vercel-deployment.png" alt="Deployment time on vercel dashboard. Around 1 seccond" />

More info how my blog works you can find there [How my site works under the hood](/blog/introducing-the-new-shramko.dev)


Migrate from npm to pnpm and cut your deployment time by 44%. Step-by-step guide covering installation, lockfile conversion, and CI/CD configuration.

Migrate from npm to pnpm – Save Time with This Guide

<Image src="astro.jpg" alt="Astro Framework Logo" />

**Astro is a web framework that ships zero JavaScript by default, delivering lightning-fast websites through its Islands Architecture.** This Astro framework guide covers everything you need to build content-driven sites — blogs, marketing pages, docs, and e-commerce storefronts. Astro renders HTML at build time and hydrates only the interactive components you choose.

As of 2026, Astro 6.x powers over 1.3 million weekly npm downloads and holds 57K+ GitHub stars. It ranked **#1 in satisfaction** among meta-frameworks in the [State of JS 2025](https://2025.stateofjs.com/en-US/libraries/meta-frameworks/) survey — with a 39% gap over Next.js. In January 2026, [Cloudflare acquired Astro](https://blog.cloudflare.com/astro-joins-cloudflare/), signaling long-term investment in the framework's future.

> **Why Astro over Next.js?** If your site is primarily content (blogs, docs, landing pages), Astro delivers smaller bundles and faster page loads — no React runtime ships unless you need it. Next.js excels for highly interactive apps. Choose the right tool for the job.

## TL;DR

- **Zero JS by default** — Astro renders static HTML; no JavaScript ships unless you opt in
- **Islands Architecture** — hydrate only interactive components, not the entire page
- **UI-agnostic** — use React, Vue, Svelte, Solid, or plain HTML in the same project
- **Content Collections** — type-safe content management with schema validation
- **View Transitions** — native page transitions without a SPA framework
- **Server Islands** — defer server-rendered components with `server:defer`

## Islands Architecture

Astro pioneered the [Islands Architecture](https://docs.astro.build/en/concepts/islands/) for the web. Think of your page as an ocean of static HTML with small "islands" of interactivity.

```md:src/pages/index.astro
---
// Static content — ships as HTML, zero JS
import Header from '../components/Header.astro';
import Newsletter from '../components/Newsletter.tsx';
import Footer from '../components/Footer.astro';
---

<Header />

<main>
  <h1>Welcome to my site</h1>
  <p>This paragraph is static HTML. No JavaScript needed.</p>

  
  <Newsletter client:visible />
</main>

<Footer />
```

The `Header`, `Footer`, and all HTML ship as plain markup. Only the `Newsletter` component loads JavaScript — and only when it scrolls into view. This is why Astro sites score 90+ on Lighthouse by default.

## Content Collections and the Content Layer API

[Content Collections](https://docs.astro.build/en/guides/content-collections/) give you type-safe access to Markdown, MDX, JSON, and YAML content. Define a schema, and Astro validates your frontmatter at build time.

```ts:src/content.config.ts
import { defineCollection, z } from 'astro:content';
import { glob } from 'astro/loaders';

const blog = defineCollection({
  loader: glob({ pattern: '**/*.md', base: './src/data/blog' }),
  schema: z.object({
    title: z.string(),
    description: z.string(),
    pubDate: z.coerce.date(),
    tags: z.array(z.string()).default([]),
    draft: z.boolean().default(false),
  }),
});

export const collections = { blog };
// Output: type-safe collection with validated frontmatter
```

Query your content with full [TypeScript](/blog/discriminated-unions) autocompletion:

```md:src/pages/blog/index.astro
---
import { getCollection } from 'astro:content';

const posts = await getCollection('blog', ({ data }) => !data.draft);
// Output: Array of type-safe blog post objects
---

<ul>
  {posts.map(post => (
    <li>
      <a href={`/blog/${post.id}`}>{post.data.title}</a>
    </li>
  ))}
</ul>
```

The Content Layer API (Astro 5+) extends this to external sources — CMS platforms, databases, or APIs — using the same type-safe interface. See the [Content Layer docs](https://docs.astro.build/en/guides/content-collections/#the-content-layer) for details.

## View Transitions

Astro provides native [View Transitions](https://docs.astro.build/en/guides/view-transitions/) that create smooth page navigation without client-side routing.

```md:src/layouts/Base.astro
---
import { ViewTransitions } from 'astro:transitions';
---

<html>
  <head>
    <ViewTransitions />
  </head>
  <body>
    <slot />
  </body>
</html>
```

Add per-element animations with the `transition:animate` directive:

```md
<h1 transition:animate="slide">Page Title</h1>
<article transition:animate="fade">Content here</article>
```

> **Gotcha:** Scripts run only on initial page load by default. If you need code to run on every navigation, listen for the `astro:page-load` event:

```html
<script>
  document.addEventListener('astro:page-load', () => {
    // Runs on every page navigation
    console.log('Page loaded');
  });
</script>
```

## Server Islands

[Server Islands](https://docs.astro.build/en/guides/server-islands/) (Astro 5+) let you defer specific components to render on the server at request time while the rest of the page is statically cached.

```md:src/pages/product.astro
---
import ProductInfo from '../components/ProductInfo.astro';
import UserCart from '../components/UserCart.astro';
---


<ProductInfo />


<UserCart server:defer>
  <p slot="fallback">Loading cart...</p>
</UserCart>
```

This is perfect for personalized content (user carts, dashboards) on otherwise static pages. The static parts serve instantly from the CDN while the dynamic island streams in.

## Creating Your First Project

```shell
# Create a new Astro 6.x project
npm create astro@latest

# Start the dev server
npm run dev
```

<Image src="astro-dev.jpeg" alt="Astro welcome screen on localhost" />

Astro scaffolds a project with file-based routing, TypeScript support, and zero configuration. Add integrations like React, Tailwind, or MDX with one command:

```shell
npx astro add react mdx
```

## File-Based Routing

Astro uses [file-based routing](https://docs.astro.build/en/guides/routing/). Files in `src/pages/` become pages on your site:

```shell
# Static routes
src/pages/index.astro        → site.com/
src/pages/about.astro         → site.com/about
src/pages/blog/first-post.md  → site.com/blog/first-post
```

Dynamic routes use bracket syntax with `getStaticPaths()`:

```md:src/pages/blog/[slug].astro
---
import { getCollection } from 'astro:content';

export async function getStaticPaths() {
  const posts = await getCollection('blog');
  return posts.map(post => ({
    params: { slug: post.id },
    props: { post },
  }));
}

const { post } = Astro.props;
// Output: renders a page for each blog post
---

<h1>{post.data.title}</h1>
```

## Astro Component Structure

Every `.astro` component has two parts: the Component Script (frontmatter) and the Component Template.

```md:src/components/Greeting.astro
---
// Component Script — runs at build time
const { name } = Astro.props;
const greeting = `Hello, ${name}!`;
---


<h1>{greeting}</h1>

<style>
  h1 { color: navy; }
</style>
```

Use [slots](https://docs.astro.build/en/basics/astro-components/#slots) to pass child content into components:

```md:src/components/Wrapper.astro
---
const { title } = Astro.props;
---

<div class="wrapper">
  <h1>{title}</h1>
  <slot />  
</div>
```

## Client Directives (Hydration)

By default, UI framework components render as static HTML with **no JavaScript**. Use `client:*` directives to hydrate interactive [islands](https://docs.astro.build/en/concepts/islands/).

| Directive | Priority | When It Loads | Use Case |
|-----------|----------|---------------|----------|
| `client:load` | High | Immediately on page load | Buttons, modals, forms |
| `client:idle` | Medium | After page finishes loading | Analytics, non-critical widgets |
| `client:visible` | Low | When scrolled into viewport | Below-fold carousels, comments |
| `client:media` | Low | When CSS media query matches | Mobile-only sidebars |
| `client:only` | — | Client-only, no SSR HTML | Components needing `window` |

### The #1 Beginner Mistake

"Why isn't my `onClick` working?" — Because you forgot the client directive.

```jsx
// ❌ Wrong — renders as static HTML, no JavaScript runs
<Counter />
```

```jsx
// ✅ Correct — hydrates the component on page load
<Counter client:load />
```

Without a `client:*` directive, your React/Vue/Svelte component renders HTML only. Event handlers, state, and effects won't work. See the [client directives reference](https://docs.astro.build/en/reference/directives-reference/#client-directives).

Use `client:only="react"` when a component has no meaningful server-rendered HTML or depends on browser-only APIs like `window` or `localStorage`.

## Data Fetching

Astro supports two primary data fetching patterns.

**Content Collections** (recommended for local content):

```md
---
import { getCollection } from 'astro:content';

const posts = await getCollection('blog');
// Output: type-safe array of blog posts
---
```

**Global `fetch()`** for external APIs:

```md:src/pages/users.astro
---
const response = await fetch('https://api.github.com/users/octocat');
const user = await response.json();
// Output: { login: "octocat", name: "The Octocat", ... }
---

<h1>{user.name}</h1>
<p>{user.bio}</p>
```

> Before using React components for fetched data, add the [React integration](https://docs.astro.build/en/guides/integrations-guide/react/).

<Image src="astro-dev.gif" alt="Data fetching in Astro" />

**Build-time vs runtime:** In static mode (default), `fetch()` runs at build time. With [SSR enabled](https://docs.astro.build/en/guides/on-demand-rendering/), it runs on each request. Read more in the [data fetching docs](https://docs.astro.build/en/guides/data-fetching/).

## Styles & CSS

Astro scopes `<style>` blocks to their component by default — no CSS leaks:

```md:src/components/Card.astro
<style>
  /* Only applies to <h2> inside this component */
  h2 { color: navy; }
</style>

<h2>Scoped heading</h2>
```

**Tailwind CSS v4** setup uses the Vite plugin (the `@astrojs/tailwind` integration is deprecated in Astro 5+):

```shell
npm install tailwindcss @tailwindcss/vite
```

```ts:astro.config.mjs
import { defineConfig } from 'astro/config';
import tailwindcss from '@tailwindcss/vite';

export default defineConfig({
  vite: {
    plugins: [tailwindcss()],
  },
});
```

```css:src/styles/global.css
@import 'tailwindcss';
```

Astro also supports [Sass, Less, and CSS Modules](https://docs.astro.build/en/guides/styling/) out of the box.

> **Gotcha:** Styles inside `<style>` blocks cannot target elements inside `<astro-island>` wrappers. Use `:global()` or Tailwind utility classes for hydrated framework components.

## Astro vs Next.js: When to Use Each

Both are excellent frameworks, but they solve different problems.

| | Astro | Next.js |
|---|---|---|
| **Best for** | Content sites, blogs, docs, marketing | Interactive apps, dashboards, SaaS |
| **Default JS** | Zero | Full React runtime |
| **Rendering** | Static-first, opt-in SSR | SSR-first, opt-in static |
| **UI framework** | Any (or none) | React only |
| **Learning curve** | Low (HTML-first) | Medium (React required) |

**Choose Astro** when your site is mostly content with pockets of interactivity. **Choose Next.js** when every page needs heavy client-side state and routing. You can always use React components in Astro for the interactive parts — get the best of both worlds.

## Common Mistakes

### Forgetting `client:*` directives

```jsx
// ❌ No interactivity — renders as static HTML
<ReactForm />
```

```jsx
// ✅ Hydrated — event handlers and state work
<ReactForm client:load />
```

### Using the deprecated Tailwind integration

```shell
# ❌ Deprecated in Astro 5+
npx astro add tailwind
```

```shell
# ✅ Use the Vite plugin instead
npm install tailwindcss @tailwindcss/vite
```

### Ignoring `astro:page-load` with View Transitions

```html

<script>
  document.querySelector('.menu').addEventListener('click', toggle);
</script>
```

```html

<script>
  document.addEventListener('astro:page-load', () => {
    document.querySelector('.menu').addEventListener('click', toggle);
  });
</script>
```

### Fetching content without Content Collections

```md
---
// ❌ Manual glob — no type safety, no validation
const posts = await Astro.glob('../content/blog/*.md');
---
```

```md
---
// ✅ Type-safe with schema validation (Astro 5+)
import { getCollection } from 'astro:content';
const posts = await getCollection('blog');
---
```

## Why Learn Astro in 2026?

Astro ranked **#1 in satisfaction** among meta-frameworks in the [State of JS 2025](https://2025.stateofjs.com/en-US/libraries/meta-frameworks/) survey — a 39% gap over Next.js. With ~1.3M weekly npm downloads and 57K+ GitHub stars, it's one of the fastest-growing web frameworks.

In January 2026, [Cloudflare acquired Astro](https://blog.cloudflare.com/astro-joins-cloudflare/), bringing enterprise backing and deeper edge computing integration. The ecosystem continues to grow with [Starlight](https://starlight.astro.build/) (documentation framework) powering docs for Cloudflare, Sentry, and Stripe.

Whether you're building a personal blog, a [link tree](/blog/linktree), or deploying [images on Vercel](/blog/astro-image-on-vercel), Astro keeps your sites fast by default.

## Useful Links

- [Astro home page](https://astro.build/)
- [Astro documentation](https://docs.astro.build/en/getting-started/)
- [Astro GitHub repository](https://github.com/withastro/astro)
- [Astro integrations directory](https://astro.build/integrations/)
- [Starlight — documentation framework built on Astro](https://starlight.astro.build/)
- [State of JS 2025 — meta-frameworks](https://2025.stateofjs.com/en-US/libraries/meta-frameworks/)
- [Are SPAs better than MPAs? | HTTP 203](https://www.youtube.com/watch?v=ivLhf3hq7eM)

## My Astro Projects

- [Building a Link Tree](/blog/linktree) — my personal linktree with Astro and Vercel
- [Astro Image Component on Vercel](/blog/astro-image-on-vercel) — fixing image optimization for Vercel deployments

Master the Astro framework with this hands-on guide. Islands Architecture, Content Collections, View Transitions, and client directives with code examples.

Astro Framework Guide: Build Faster Sites in 2026


## Intro

Formatting is one of several issues to consider when writing clean code. There are many other things we have to worry
about as well, but formatting is one of those things that we can adjust right away and set the standard for our project.

## ESLint and TSLint

[ESLint](https://eslint.org/) is statically analyzes your code to quickly find problems. It looks at your code, and
tells you when you're not following the standard that you set in place.

## Installation and setup

```shell
npm install --save-dev eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin
```

If you're using PhpStorm or another JetBrains IDE, you may also need to [allow network connections on startup](/blog/phpstorm-allow-network) to avoid repeated prompts.

Next, add the `.eslintrc.json` configuration file to the project root.

```shell
touch .eslintrc
```

In it, use the following start configuration.

```json
{
  "root": true,
  "parser": "@typescript-eslint/parser",
  "plugins": [
    "@typescript-eslint"
  ],
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/eslint-recommended",
    "plugin:@typescript-eslint/recommended"
  ]
}
```

## Ignoring files we don't want to lint

```shell
touch .eslintignore
```

Then add the things we want to ignore. In the following code sample, we're ignoring the dist/ folder that contains the
compiled TypeScript code.

```ini
node_modules
dist
```

## Adding a script to package

```json
{
  "scripts": {
    "lint": "eslint . --ext .ts"
  }
}
```

Let's run the following command.

```ini
npm run lint
```

## Eslint Rules

ESLint comes with a large number of built-in rules, and you can add more rules through plugins. You can modify which
rules your project uses either using configuration comments or configuration files. To change a rule setting, you must
set the rule ID equal to one of these values:

- "off" or 0 - turn the rule off
- "warn" or 1 - turn the rule on as a warning (doesn’t affect exit code)
- "error" or 2 - turn the rule on as an error (exit code is 1 when triggered)

### Adding a rule

To configure rules inside a configuration file, use the rules key along with an error level and any options you want
to use. For example:

```json
{
  "rules": {
    "curly": "error",
    "quotes": [
      "error",
      "double"
    ]
  }
}
```

Rules are added as keys to this rules attribute, and you can usually find basic eslint rules here on their website in
the
[rules' documentation](https://eslint.org/docs/latest/use/configure/rules).

## Conclusion

That's all 🎉.

It's very easy to start using `ESlint`, but its contribution to code formatting and saving time is
huge. Therefore, I recommend always using it.

- [Create-React-App with TypeScript, ESLint, Prettier, and Github Actions](https://brygrill.medium.com/create-react-app-with-typescript-eslint-prettier-and-github-actions-f3ce6a571c97)
- [What is ESLint?](https://hackernoon.com/what-is-eslint-how-do-i-set-it-up-on-atom-70f270f57296)

## Related

- [The satisfies Operator](/snippets/satisfies-operator) - a TypeScript operator that works well alongside strict ESLint rules
- [Fix "__dirname Not Defined" in ES Modules](/blog/dirname-error) - a common Node.js pitfall when configuring TypeScript projects


Step-by-step guide to configuring ESLint with TypeScript. Set up linting rules, integrate with your IDE, and catch errors before they reach production.

ESLint with TypeScript: Setup and Configuration Guide

Level up your TypeScript skills with guides on types, generics, and advanced patterns. Build type-safe applications with confidence.

TS10 articles

Articles

The early return pattern in JavaScript

Generic Type Parameters in TypeScript

Custom Hooks Pitfalls

React Re-Renders

Why Are JavaScript Naming Conventions Important?

Discriminated Unions in TypeScript

Conventional Commits

How to decrease deployment time by 44% with pnpm

What Is Astro? The Complete Framework Guide for 2026

How to use ESLint with TypeScript