
<Image src="exit.jpg" alt="black and green led light" />

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 (or guard clauses, if you like fancy names) isn’t just a coding pattern;
it’s a way of freeing your own brain. You handle the simplest, most obvious stuff 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);
}
```

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.

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
function processUser(user) {
  if (user) {
    if (user.isActive) {
      sendWelcomeEmail(user);
      updateAnalytics(user);
    }
  }
}
```

This still runs fine, but it makes you think about conditions long after you should’ve moved on.

The beauty of early return is that it clears `mental space`.

> 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.

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.


Discover how early return and guard clauses can simplify your JavaScript functions, reduce nesting, and free your mind to focus on the real logic.

Why Early Return Makes Your JavaScript Easier to Read


### 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 toggling the visibility of a tooltip:

```jsx
const useTooltipToggle = () => {
  const [visible, setVisible] = useState(false);

  return {
    visible,
    show: () => setVisible(true),
    hide: () => setVisible(false),
  };
};
```

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

```jsx
const App = () => {
  const {
    visible,
    show,
    hide
  } = useTooltipToggle();

  return (
    <div className="app-container">
      <button onMouseEnter={show} onMouseLeave={hide}>Hover me!</button>
      {visible && <Tooltip text="Hello, Tooltip!" />}
      <HeavyComputationComponent />
      <AnotherIntensiveComponent />
    </div>
  );
};
```

At first glance, this setup appears elegant—state logic neatly wrapped in the `useTooltipToggle` hook. However, this
approach hides a subtle performance issue: whenever the tooltip 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 a scroll event:

```jsx
const useTooltipToggle = () => {
  const [scrollPosition, setScrollPosition] = useState(window.scrollY);

  useEffect(() => {
    const handleScroll = () => setScrollPosition(window.scrollY);
    window.addEventListener('scroll', handleScroll);

    return () => window.removeEventListener('scroll', handleScroll);
  }, []);

  return {
    // For example, this part of the code was simplified
    visible: false,
    show: () => {},
    hide: () => {},
  };
};
```

Now, every time the user scrolls, this hook updates the state internally. Even though the scrolling position 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
mouse movement:

```jsx
const useMouseTracker = () => {
  const [mousePosition, setMousePosition] = useState({
    x: 0,
    y: 0
  });

  useEffect(() => {
    const updateMousePosition = (e) => setMousePosition({
      x: e.clientX,
      y: e.clientY
    });
    window.addEventListener('mousemove', updateMousePosition);

    return () => window.removeEventListener('mousemove', updateMousePosition);
  }, []);

  return null;
};

const useTooltipToggle = () => {
  useMouseTracker();

  return {
    // For example, this part of the code was simplified
    visible: false,
    show: () => {},
    hide: () => {},
  };
};
```

Even if `useTooltipToggle` does not directly use mouse position state, the `App` component still re-renders each time
the mouse moves, 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 Tooltip = () => {
  const {
    visible,
    show,
    hide
  } = useTooltipToggle();

  return (
    <>
      <button onMouseEnter={show} onMouseLeave={hide}>Hover me!</button>
      {visible && <Tooltip text="Hello, Tooltip!" />}
    </>
  );
};
```

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

> In this solution, the `Tooltip` logic moved down from `App` to the 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.


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 `modal dialog` at the top of the app.

```jsx
const App = () => {
  // Some code here
  return <div className="layout">
    {/* The button should go somewhere here */}
    <VerySlowComponent />
    <AnotherComponent />
    <OtherStuff />
  </div>;
};
```

Then you implement it. The task seems trivial. We've all done it hundreds of times:

```jsx
const App = () => {
  // Add state  
  const [isOpen, setIsOpen] = useState(false);

  // Everything that is returned here will be re-rendered when the state is updated
  return <div>
    {/* Add the button */}
    <Button onClick={() => setIsOpen(true)}>
      Open dialog
    </Button>

    {/* Add the dialog */}
    {isOpen && <ModalDialog onClose={() => setIsOpen(false)} />}

    <VerySlowComponent />
    <AnotherComponent />
    <OtherStuff />
  </div>;
};
```

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

When you run the app, there’s a noticeable delay ⏰, **almost a second** — before the dialog 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 `setIsOpen` setter function, which updates the `isOpen` state from `false` to
`true`. As a result, the `App` 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. (Comming
soon...)

<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 ButtonWithModalDialog = () => {
  const [isOpen, setIsOpen] = useState(false);

  return <>
    <Button onClick={() => setIsOpen(true)}>
      Open dialog
    </Button>

    {isOpen && <ModalDialog onClose={() => setIsOpen(false)} />}
  </>;
};
```

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

```jsx
const App = () => {
  return <div>
    // Our new component
    <ButtonWithModalDialog />

    <VerySlowComponent />
    <AnotherComponent />
    <OtherStuffComponent />
  </div>;
};
```

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

Consequently, the modal dialog 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.

Understanding React Re-Renders: What Triggers Them and Why They Matter


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.org](https://semver.org/) to understand semantic versioning rules.

---

## **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 guide. Learn best practices for naming variables, functions, and classes to write cleaner code.

JavaScript Naming Conventions: A Complete Guide for Clean 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.


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. You can do this by running:

```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`.

### 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](./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 framework for building static sites and web applications. It is built on top of modern web technologies like
JavaScript, HTML, and CSS, and uses a component-based architecture to make it easy to build and maintain complex web
projects. With Astro, you can build websites and applications that are fast, efficient, and easy to scale.

## Key Features

Astro offers several key features that make it a powerful tool for building modern web projects.
These include:

- **Performance**: Astro is designed to be fast and efficient, with built-in optimizations that help to reduce page load
  times and improve overall site performance.
- **Ease of use**: Astro is designed to be easy to use, with a simple and intuitive syntax that makes it easy to create
  complex web projects.
- **Themes**: Astro has an impressive array of ready-made [themes](https://astro.build/themes/) and templates to get
  started quickly.
- **Zero JS, by default**: No JavaScript runtime.
- **Component-based** architecture: Astro uses a component-based architecture that makes it easy to build and maintain
  complex web projects.
- **Template directives**: Astro's template directives make it easy to create reusable components that can be used
  throughout your site or application.
- **Built-in CMS functionality**:  Tailwind, MDX, and 100+ other integrations to choose from.
- **UI-agnostic**: Supports React, Preact, Svelte, Vue, Solid, and more.

## Creating Your First Astro Project

To create your first Astro project, you'll need to install the Astro CLI. You can do this by running the following
command:

```shell
# create a new project with npm
npm create astro@latest
```

Then navigate to the project directory and start the development server by running the following commands:

```shell
npm run dev
```

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

This will start a live Astro development server, which will automatically rebuild your site as you make changes to your
code.

## File-based routing

One of the key features of Astro is its file-based routing system. With this system, developers can easily create routes
and pages for their websites by simply creating files in the appropriate directories. This makes it easy to create and
manage complex routing structures without the need for additional configuration or setup.

### Static routes

Any `.astro` page elements, as well as Markdown and MDX files (with extensions ".md" and ".mdx"), located in the `
src/pages/` directory, will be automatically transformed into pages on your website. The page's URL will match its path
and file name within the "src/pages/" directory.

```shell
# Example: Static routes for site.com
src/pages/index.astro             -> site.com/
src/pages/about.astro             -> site.com/about
src/pages/about/index.astro       -> site.com/about # Nested folder with index file
src/pages/about/career.astro      -> site.com/about/career
src/pages/articles/1.md           -> site.com/articles/1
```

### Dynamic routes

In an Astro page file, it's possible to define dynamic route parameters within the file name. This allows for the
creation of multiple pages that match the specified parameter.

For instance, by using the file name `src/pages/users/[user].astro`, you can generate a user's page for each user
featured on your blog. The `user` in the file name serves as a parameter that can be accessed within the page.

Because all routes must be determined at build time, a dynamic route must export a `getStaticPaths()` that returns an
array of objects with a params property. Each of these objects will generate a corresponding route.

```md:src/pages/users/[user].astro
---
export function getStaticPaths() {
  return [
    {params: {user: 'Serhii'}},
    {params: {user: 'Roman'}},
    {params: {user: 'Alexander'}},
  ];
}

const { user } = Astro.params;
---

<div>Hello, {user}!</div>
```

## Astro Component Structure

The Astro component consists of two primary components: the Component Script and the Component Template.

```md:src/components/Component.astro
---
// Component Script (JavaScript)
---

```

## Astro slots

The `<slot />` element is a placeholder for external HTML content, allowing you to inject (or “slot”) child elements
from other files into your component template.

By default, all child elements passed to a component will be rendered in its `<slot />`

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

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

```md:src/pages/content.astro
---
import Wrapper from '../components/Wrapper.astro';
---

<Wrapper title="Main Page">
  <p>Here is some stuff.</p>
</Wrapper>
```

## Data Fetching

All Astro components have access to the global [fetch()](https://developer.mozilla.org/en-US/docs/Web/API/Window/fetch)
function in their component script to make HTTP requests to APIs.

This fetch call will be executed at build time, and the data will be available to the component template for generating
dynamic HTML. If SSR mode is enabled, any fetch calls will be executed at runtime.

I use [randomuser.me](https://randomuser.me/) API to this example. Please, read the documentation before.

```md:src/components/User.astro
---
import Avatar from '../components/Avatar.jsx';

const response = await fetch('https://randomuser.me/api/');
const { results } = await response.json();
const [ user ] = results;
---

<h1>{user.name.first} {user.name.last}</h1>
<p>{user.email}</p>


<Avatar picture={user.picture.large} />
```

> Before using React inside Astro add [integration](https://docs.astro.build/en/guides/integrations-guide/react/)

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

You can read more about data fetching in [official documentation](https://docs.astro.build/en/guides/data-fetching/).

## Styles & CSS

You can either compose your own CSS code within an Astro component or bring in your preferred CSS library, such as
[Tailwind](https://github.com/withastro/astro/tree/main/packages/integrations/tailwind). Additionally, Astro supports
sophisticated styling languages like `Sass` and `Less`.

```md:src/components/Component.astro
<style>
  h1 { color: orange; }
</style>
```

Astro supports a wide amount of popular styling techniques out of the box:

- Import a local stylesheet
- Use a \<style\> block anywhere in `.astro` files and the CSS will be scoped to that component
- [CSS modules](https://css-tricks.com/css-modules-part-1-need/)
- [CSS Preprocessors](https://docs.astro.build/en/guides/styling/#css-preprocessors) [Sass/Less/Stylus]

> The [styling doc](https://docs.astro.build/en/guides/styling/) has more detail.

## Template Directives

By default, a UI Framework component is not hydrated in the client. If no client:* directive is provided, its HTML is
rendered onto the page without JavaScript.

### client:load

- **Priority**: High
- **Useful for**: UI elements that require immediate interactivity and should be visible right away

> Load and hydrate the component JavaScript immediately on page load.

```jsx
<BuyButton client:load />
```

### client:idle

- **Priority**: Medium
- **Useful for**: UI elements with lower priority that do not require immediate interactivity

> Load and hydrate the component JavaScript once the page is done with its initial load.

```jsx
<BuyButton client:idle />
```

### client:visible

- **Priority**: Low
- **Useful for**: UI elements with low priority can be positioned either far down the page or require significant
  resources to load. In case the user never sees such elements, it would be preferable not to load them at all

> Load and hydrate the component JavaScript once the component has entered the user’s viewport.

```jsx
<ImageCarousel client:visible />
```

### client:media

- **Priority**: Low
- **Useful for**: Elements that might only be visible on certain screen sizes.

> Loads and hydrates the component JavaScript once a certain CSS media query is met.

```jsx
<Sidebar client:media="(max-width: 1024px)" />
```

### client:only

Skips HTML server rendering, and renders only on the client.

```jsx
<ReactComponent client:only="react" />
<SvelteComponent client:only="svelte" />
<Component client:only="vue" />
```

## Do you need to learn the Astro?

At the [moment](https://2022.stateofjs.com/en-US/libraries/rendering-frameworks/), Astro is considered a very
interesting framework that most people want to learn and understand. So be the first to figure it out 🚀.

<Image src="astro-state.jpeg" alt="Astro framework interest on stateofjs" />

## Useful Links

If you're interested in learning more about Astro, here are some useful links to get you started:

- [Astro home page](https://astro.build/)
- [Astro documentation](https://docs.astro.build/en/getting-started/)
- [Astro GitHub repository](https://github.com/withastro/astro)
- [Are SPAs better than MPAs? | HTTP 203](https://www.youtube.com/watch?v=ivLhf3hq7eM)
- [Astro usage in npm and ratings](https://bestofjs.org/projects/astro)

Comprehensive guide to the Astro framework. Learn what makes it special, explore its core features, and understand why it's great for static sites.

Exploring the Astro Framework: A Comprehensive Guide


<Image src="node-post.jpg" alt="Laptop with cone on screen with bloored background" />

[NVM](https://github.com/nvm-sh/nvm), or Node Version Manager, is essential for managing multiple versions of Node.js on
our development environment.
[Node.js](https://nodejs.org/en) is a JavaScript-based web technology, that allows developers to write server-side code
using JavaScript.

By using NVM to manage different versions with ease, developers can keep their environment up-to-date with the best
tools and achieve their desired results with ease.

In this article, we’ll be looking at how to install NVM with Brew and verify it worked properly. Additionally, we’ll
take a look at why we need NVM, a useful NVM cheatsheet, and how to install NVM on Windows, Linux, and MacOS.

## What is NVM?

Simply put, it is a software that allows you to install and manage different versions of Node.js on your system. You can
also switch easily between them, making it ideal for keeping your development environment updated.

## Why Do We Need NVM?

NVM is essential for managing multiple versions of Node.js on our systems. By using NVM to manage and switch between
different versions, we can make sure our environment is always up-to-date with the latest version. This allows us to
take advantage of the newest tools available in the Node.js ecosystem.

Additionally, NVM helps us become more efficient as developers. With NVM, we can quickly switch between different
versions of Node.js without having to reconfigure our environment and restart our terminal.

## How to Install NVM with Brew

Installing NVM with [Brew](https://brew.sh/) is a fairly straightforward process.

First, you’ll need to install Brew, which you can do simply by entering this on your terminal:

```shell
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
```

Once Brew is installed, you can install NVM by entering `brew install nvm` on your terminal.
This command will download the latest version of NVM for your system, including the necessary libraries and packages.

```shell
brew install nvm
```

### Verify It Worked

Once you’ve installed NVM with Brew, you can verify that it worked by entering `nvm —-v` on your terminal. This command
will show you the version of NVM you’re currently running.

```shell
nvm —-v

#Node Version Manager (v0.39.3) // It's my version of NVM
```

## NVM Cheatsheet

Using NVM can be intimidating at first. To help, here’s a helpful NVM cheatsheet:

```shell
- nvm install 8.0.0                     #Install a specific version number
- nvm use 8.0                           #Use the latest available 8.0.x release
- nvm run 6.10.3 app.js                 #Run app.js using node 6.10.3
- nvm exec 4.8.3 node app.js            #Run `node app.js` with the PATH pointing to node 4.8.3
- nvm alias default 8.1.0               #Set default node version on a shell
- nvm alias default node                #Always default to the latest available node version on a shell
- nvm uninstall [<version>]             #This command will uninstall a specific version of Node.js

- nvm install node                      #Install the latest available version
- nvm use node                          #Use the latest version
- nvm install --lts                     #Install the latest LTS version
- nvm use --lts                         #Use the latest LTS version
```

## How to Install NVM on Windows

Installing NVM on Windows is slightly more involved than with Linux or macOS. To do so, you’ll need to have the [Windows
Subsystem for Linux](https://learn.microsoft.com/en-us/windows/wsl/install) (WSL) installed. Once you have WSL
installed, you can use Brew to install NVM just as you would with Linux or macOS.

## How to Install NVM on Linux

The easiest way to install NVM on Linux is to use Brew. Simply open your terminal and then enter `brew install nvm`.

Before it install Brew 🍻

## Recap

Hopefully this article has helped you get a better understanding of NVM and how to install it on a variety of systems.
Installing and managing multiple versions of Node.js is essential for staying up-to-date with the best tools and
achieving better results.

With NVM, you’ll be able to easily switch between different versions and keep your development
environment updated.



Learn how to install and use Node Version Manager (NVM) to switch between Node.js versions. Essential for projects with different Node version requirements.

Managing Node Versions Made Easy with Node Version Manager (NVM)


Very often, cloud database services such as [neon.tech](https://neon.com/) allow you to connect via URL.
That is, without credentials such as `user`, `password`, etc.

## Connection details

### Connection URL

It's [official PostgreSQL format for connection URLs](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING)

<Image alt src="postgresql-connection-string.png" priority={true} alt="S.Shramko personal site screenshot"/>

### Base URL and path

Here's an example of a base URL and path structure using uppercase placeholder values:

```text
postgresql://USER:PASSWORD@HOST:PORT/DATABASE
```

<Image alt src="db-table.png" priority={true} alt="S.Shramko personal site screenshot"/>

## How this site connects to the database

### Store your credentials in .env

Store your credentials in your `.env` file.

```shell
PGHOST='<endpoint_hostname>:<port>'
PGDATABASE='<dbname>'
PGUSER='<username>'
PGPASSWORD='<password>'
ENDPOINT_ID='<endpoint_id>'
```

where:

- `endpoint_hostname` the hostname of the branch endpoint. The endpoint hostname has an ep- prefix and appears similar
  to
  this: **ep-tight-salad-272396.us-east-2.aws.neon.tech**
- `dbname` is the name of the database. The default Neon database is neondb
- `user` is the database user
- `password` is the database user's password, which is provided to you when you create a project
- `endpoint_id` is the ID of the branch endpoint that you are connecting to. The endpoint_id has an ep- prefix and
  appears
  similar to this: **ep-tight-salad-272396**

### Use prisma.io to connect Postgres

```js
// You can create DATABASE_URL in your code
const DATABASE_URL = `postgres://${PGUSER}:${PGPASSWORD}@${PGHOST}/${PGDATABASE}`;
```

```shell
# Or better to use .env file
datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
  referentialIntegrity = "prisma"
}
```

### Use Datagrip to connect Postgres

You can use same credentials like `HOST`, `PORT`, `USER`, `PASSWORD`, `DATABSE` for connection to Database with
DataGrip.

<Image alt src="db-datagrip.png" priority={true} alt="S.Shramko personal site screenshot"/>




Learn how to connect to PostgreSQL using a connection URL string. Simple guide for Node.js, DataGrip, or any client supporting URL-based database connections.

Use Postgres Connect URLs for DB Connections


<Image src="fruits.png" alt="ES modules structure diagram" priority={true} />

## Syntax

Arrays are zero-indexed ordered lists of values. They are a convenient way to store a set of related elements of the
same type (such as numbers or strings), although an array can contain multiple types of elements, including other
arrays.

```js
// An array containing numbers
const numberArray = [0, 1, 2, 3, 4, 5];

// An array containing different data types
const mixedArray = [1, 'chicken', false];
```

## Creating an Array

The easiest way to create an array is to use array literals - `[]`, as in the example above.

```js
const fruits = ['🍎', '🍐', '🍊', '🍋', '🍉', '🍓'];
```

With the Array class by using the new keyword and passing in the elements as arguments:

```js
const fruits = new Array('🍎', '🍐', '🍊', '🍋', '🍉', '🍓');
```

Though, because the effect is exactly the same, it
is [preferable to use the literal method](https://google.github.io/styleguide/jsguide.html#features-arrays-ctor) for
simplicity

## Accessing the Elements of an Array

Array elements are ordered by index values, starting at 0:

- Index 0 has the first element
- Index 1 has the second element
- Index n-1 has the nth element
- Index array.length-1 has the last element

```js
//              [0]   [1]   [2]  [3]   [4]   [5]
const fruits = ['🍎', '🍐', '🍊', '🍋', '🍉', '🍓'];

// Get first element of array
console.log(fruits[0]); // 🍎

// Get third element of array n-1
console.log(fruits[2]); // 🍊

// Get last element of array
console.log(fruits[fruits.length]); // 🍓
```

## Array methods and properties

Arrays provide a lot of methods and properties.

### Array properties

The Array does not have a lot of property 😂.

#### Array length

The `length` property is used to know the amount of items in your array.

```js
const apples = ['🍎', '🍎', '🍎'];

// Length of an array
console.log(apples.length); // logs 3
```

### Array methods

For these examples I use this sample data:

```js:DATA_SAMPLE
const employees = [
  {
    name: 'Serhii',
    age: 29
  },
  {
    name: 'Anna',
    age: 20
  },
  {
    name: 'Roman',
    age: 27
  },
  {
    name: 'Julia',
    age: 25
  },
  {
    name: 'Mykola',
    age: 35
  }
];
```

#### Add & remove items from array

Methods that add and remove items from the beginning or the end:

- employees.push(...items) – adds items to the end
- employees.pop() – extracts an item from the end
- employees.shift() – extracts an item from the beginning
- employees.unshift(...items) – adds items to the beginning

#### Find element in array

The `.find()` method will return the **_first element_** in the array that matches a test you provide.

```js
const employees = [/* See DATA_SAMPLE */]

// Find employe with name 'Serhii'
const serhii = employees.find((employe) => employe.name === 'Serhii');

// or with object destructuring
const serhii = employees.find(({ name }) => name === 'Serhii');
```

#### Transform elements in array

The `.map()` method will apply a given function to every item in your array and give you a **_new array with those
values_**.

```js
// Transform employees array to new array of names.
// I use object destructuring in this and future examples
const names = employees.map(({ name }) => name);
```

#### Filter elements in array

The `.filter()` method takes your array and removes items that don't pass a test you give it, and return new array.

```js
// Keep employees who are younger than 25
const youngEmployees = employees.filter(({ age }) => age < 25);
```

#### Merge two arrays to one

The `.concat()` method is used to merge two or more arrays, or concat new array to old. This method does not change the
existing arrays, but instead returns a new array.

```js
const evenNumbers = [2, 4, 6];
const oddNumbers = [1, 3, 5];

const allNumbers = evenNumbers.concat(oddNumbers); // [ 2, 4, 6, 1, 3, 5 ]
```

#### Join each element in array

The `.join()` method creates and returns a new string by concatenating all elements in an array.

```js
// Before .join() we must transform each object in array to string
const foematedOutput = employees
  .map(({ name }) => name) // Transform employee object to name string
  .join("\n"); // "\n" – add newline after each element
```

```shell:Output
Serhii
Anna
Roman
Julia
Mykola
```

#### Check if every element in array matches some criteria

The `.every()` method checks that every single item in your array matches some criteria.

```js

const isAdult = (employe) => employe.age > 18;

// Check is every our employe older than 18 age
const isEveryEmployeeYoung = employees.every(isAdult); // true
```

#### Check if at least one item in array matches some criteria.

The `.some()` method checks that at least one item in your array matches some criteria by compare function.

```js

const isAdult = (employe) => employe.age > 18;

// Check is every our employe older than 18 age
const isEveryEmployeeYoung = employees.every(isAdult); // true
```

#### Check if at least one item includes in your array

The `.includes()` method checks that at least one item in your array matches some value.

```js
// Check is name "Serhii" includes in employees array
const isSerhiiNameExist = employees
  .map(({ name }) => name) // Transform employee object to name string
  .includes('Serhii'); // true
```

#### Loop through an array

The `.forEach()` method executes a provided function once for each array element.

It doesn't return a value though. It's useful for side effects.

```js
// Print to console name of each employe
employees.forEach((employe) => console.log(employe.name))
```

## Conclusion

The array has many methods, in this article I have shown the most used in my opinion.

Further, you can learn more methods on the pages of MDN Web Docs, so I wish you inspiration and hope this article will
be useful to you.


Master JavaScript array methods with this beginner-friendly guide. Learn map, filter, reduce, find, and other essential methods with practical examples.

Mastering JavaScript Arrays: A Beginner's Guide to Essential Concepts


I am a Frontend mentor in a [MacPaw internship](https://macpaw.com/bootcamp) and sometimes my interns get confused 🫠
about how links work in HTML.

So I decided to write a small article about this topic.

## Anatomy of a URL

<abbr title="Uniform Resource Locator">URL</abbr> - is a string that indicates the address of a document or file on the
Internet.

<Image src="anatomy.png" alt="Anatomy of URL" inverted />

### Scheme

The first part of the URL is the scheme, which indicates the protocol that the browser must use to request the resource.
The protocol is usually HTTPS or HTTP, but can also be:

- ftp
- gopher
- file
- mailto
- and others

### Authority

Authority is the domain and optional port like `:80`.

Now you are in `shramko.dev` domain.

### Path to resource or file

```text
/blog/difference-between-absolute-and-relative-url
```

This is the path to the HTML file of this article. You can check it in the console if you write:

```javascript
window.location.pathname
```

## Relative links

These links will always be anchored to the place where they are located.
The browser will use the same protocol and the same domain.

### Relative to the root of the site

An important point, we add `/` to the address at the beginning.

```html
<a href="/about">About page</a>
```

<Image src="root-example.png" alt="Relative to the root of the site example" inverted />

### Relative path from the current document

Similar to the previous example, but
the [path to the file](#path-to-resource-or-file) is saved.

An important point, we do not add `/` to the address at the beginning.

```html
<a href="category/js">JS category of Blog</a>
```

<Image src="location.png" alt="Relative path from the current document example" inverted />

## Absolute links

An absolute link is an address to a file or page as a whole, with all the above-described parts of
the <abbr title="Uniform Resource Locator">URL</abbr>. With such a link, regardless of where this link is located, you
will be able to get to the right resource.

You will be taken to any page or site exactly as indicated by a link of this type:

```html
<a href="https://shramko.dev/dashboard">My Dashboard</a>
```

You can not specify the protocol `http/https`, then the browser will automatically use the protocol on which the site
was loaded.

```html
<a href="//shramko.dev/dashboard">My Dashboard</a>
```

## Anchors (links by #id)

Anchor links are usually used to navigate the current page. For example, a link to a paragraph or heading.

The link below moves you to the section about [Anatomy of URL on this page](#anatomy-of-a-url).

Add `#anatomy-of-a-url` to the current URL in your browser.

## Cheat Sheet

Examples that we discussed today.

<Image src="cheat-sheet.png" alt="Relative and Absolute paths Cheat Sheet" inverted />

## Useful links

- [Article about how my site works under the hood](https://shramko.dev/blog/introducing-the-new-shramko.dev)
- [Site where I drew pictures](https://okso.app/)
- [Nice tutorial about how DNS works](https://howdns.works/)
- [What is a URL](https://developer.mozilla.org/en-US/docs/Learn_web_development/Howto/Web_mechanics/What_is_a_URL)


Understand when to use absolute vs relative URLs in HTML. Clear examples showing how each type works, their pros and cons, and best practices for web links.

Absolute vs Relative URL: Which One Should You Use


## ❌ 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)


Replace messy switch statements with dispatch tables in JavaScript. Learn this clean code pattern for handling multiple conditions with maintainable code.

Dispatch Tables in JavaScript: A Clean Code Approach


## The For Loop

There are many ways to iterate in JavaScript, and probably one of the most common is for a loop.

The for statement is a type of loop that will use up to three optional expressions to implement the repeated execution
of a code block.
Let’s take a look at an example of what that means:

```js
for (initialization; condition; final expression) {
  // code to be executed
}
```

```js
// Initialize a for statement with 5 iterations
for (let i = 0; i < 5; i++) {
  // Print each iteration to the console
  console.log(`The number is ${i}`);
}
```

```shell:Output
The number is 0
The number is 1
The number is 2
The number is 3
The number is 4
```

But in addition to this `for` loop, there are two other types of for iteration methods we can use: `for...in`
and `for...of`.

## The for...in Statement

The `for...in` statement iterates over
all [enumerable properties](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Enumerability_and_ownership_of_properties)
of an object that is keyed by strings (ignoring one keyed by Symbols), including inherited enumerable properties.

The syntax `for...in` looks like this:

```js
for (const variable in enumerable) {
  // Do something
}
```

For example, to loop through and `console.log` all the values in this `user` Object:

```js
const user = {
  name: 'Serhii',
  age: 29,
  email: 'shramko.dev@gmail.com',
  country: 'Ukraine',
  city: 'Kyiv'
}

for (const key in user) {
  console.log(`user.${key} = ${user[key]}`)
}
```

```shell:Output
user.name = Serhii
user.age = 29
user.email = shramko.dev@gmail.com
user.country = Ukraine
user.city = Kyiv
```

We iterate through each `key` of the `user` Object, and then through this key we get the value
with [Bracket notation](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Property_accessors#bracket_notation)
.

### for...in and Objects

`for...in` is probably the easiest way to go through the object and use the key to get the value from it.

### for...in and Arrays

The keys in the array are indexes (numbers).

```js
const creatures = [
  "octopus",
  "squid",
  "shark",
  "seahorse",
  "starfish",
];

for (const index in creatures) {
  // We need access to creatures value by index
  console.log(creatures[index])
}
```

```shell:Output
octopus
squid
shark
seahorse
starfish
```

### for...in and Strings

```js
const oceanCreature = 'Shark';

for (const index in oceanCreature) {
  console.log(oceanCreature[index])
}
```

```shell:Output
S
h
a
r
k
```

## The for...of Statement

The `for...in` statement is useful for iterating over object properties, but to iterate over iterable objects like
arrays and strings, we can use the for...of statement. The `for...of` statement is a newer feature as of ECMAScript 6.

In this example of a `for...of` loop, we will create an array and print each item in the array to the console.

```js
const sharks = ["tiger", "great white", "hammerhead"];

// Print out each type of shark
for (const shark of sharks) {
  // Unlike for...in, we don't need an index now
  // we have immediate access to the element of the array
  console.log(shark);
}
```

```shell:Output
tiger
great white
hammerhead
```

### for...of and Objects

The `for...of` loop doesn't work with Objects because they don't have a [Symbol.iterator] property.
You can try but you will get an error:

```js
"Uncaught TypeError: Object is not iterable"
```

### Iterating over a DOM collection

Iterating over DOM collections like [NodeList](https://developer.mozilla.org/en-US/docs/Web/API/NodeList):

```js
const paragraphElements = document.querySelectorAll('p');

for (const paragraph of paragraphElements) {
  // Make all paragraphs red
  paragraph.style.color = 'red';
}
```

## Conclusion

In this post, we understood how for loops work and the difference between `for...of` and `for...in` statements.

Loops are an integral part of any programming language, as they are constantly used in places where you need to perform
the same type of tasks several times.


Understand the key differences between for...in and for...of loops in JavaScript. Learn when to use each for iterating over arrays, objects, and iterables.

JavaScript Loops: for...in vs for...of


JavaScript distinguishes _expressions_ and _statements_. A statement is an instruction, an action.

Remember conditions with `if`, `loops` with `while` and `for` — all those are _statements_, because they just perform
actions and control actions, but don't become values.

`Expression` returns (expresses) a value. Each of the following lines contains an expression:

```js
100 // this is a literal that expresses number 100

getUserName() // expresses Serhii

5 + 2 // expresses 7
```

`Statements` produce or control actions, but do not turn into values:

```js
let x; // declare a variable 'x'

function foo() {} // declare a function 'foo'

function bar() {
  return null // return is also a statement
}
```

You can't put statements where expressions are expected. For example, passing a const statement as a function
argument will produce an error. Or trying to assign the if statement to a variable:

```js
let b = if (x > 10) { return 100; };  // error!

console.log(const y);  // error!
```

## Related posts

- [Expressions versus statements in JavaScript](https://2ality.com/2012/09/expressions-vs-statements.html)
- [Expressions - MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Expressions_and_operators)


Learn the difference between expressions and statements in JavaScript. Understanding this distinction helps you write better code and avoid syntax errors.

JavaScript Expressions vs Statements: What's the Difference?


<Image src="es-module.png" alt="ES modules structure diagram" priority={true} />

## Problem

I ran into this error when using ```__dirname``` in an ES module.

```__dirname``` is an environment variable that tells you the absolute path of the directory containing the currently
executing file, and many Node.js projects use this.

But if you use it inside an ES module, you can't use it because of the infamous "__dirname is not defined in ES module
scope" an error appears.

## Solution

What can you do in this case?

To get the current file directory, we'll want to use a combination of a global variable and a few built-in methods:

- `import.meta.url` to get the current file's as a URL
- `url.fileURLToPath` to change the URL to a path
- `path.dirname` to get the directory name

Using these methods, we can reconstruct the global `__dirname` and `__filename` variables:

```js
import path from 'path';
import { fileURLToPath } from 'url';

const __filename = fileURLToPath(import.meta.url);

const __dirname = path.dirname(__filename);
```

Now you can use `__dirname` as usual:

```js
console.log(__dirname)
```

## Conclusion

Due to the different approaches to modularity in Node.js and EcmaScript, you may encounter such problems.

For further reading, check out
the [Node.js documentation for __dirname](https://nodejs.org/docs/latest/api/modules.html#modules_dirname).


Fix the "__dirname is not defined in ES module scope" error in Node.js. Learn how to recreate __dirname and __filename using import.meta.url in ES modules.

Fix “__dirname Not Defined” in ES Modules – Quick Guide

Master JavaScript with practical tutorials and best practices. Learn ES6+ features, async patterns, and modern techniques for web development.

JS16 articles

Articles

The early return pattern in JavaScript

Custom Hooks Pitfalls

React Re-Renders

Semantic Versioning in npm

Why Are JavaScript Naming Conventions Important?

Conventional Commits

How to decrease deployment time by 44% with pnpm

What is Astro Framework?

Node Version Manager

Postgres connect to database with URL

JavaScript 101: Arrays

Difference between absolute and relative URL in HTML

Dispatch table in javascript

for...in vs for...of Loops

Expressions vs Statements

How to fix "__dirname is not defined in ES module scope"