DEV Community: Isabelle M.

Can We Ever Achieve a Utopian Release?

Isabelle M. — Fri, 03 Apr 2026 20:03:50 +0000

What if releases didn't feel stressful?

Not just "we followed the process" safe, but actually safe. The kind where you don't hesitate before deploying, don't keep checking Slack afterward, and don't quietly wonder what might go wrong this time.

Because if we're honest, most of us recognize a very specific moment.

A release finishes. Everything is deployed.
Dashboards are open. People are watching.

Slack goes a bit quieter than usual.

No one says anything, but the same thought is there in the background:

Let's see what breaks.

We spend a lot of time trying to improve releases.

We add better pipelines. We introduce more automation. We create more environments.

On paper, things look more mature over time.
And yet, the feeling often doesn't change.

That's because the real issue is not only technical.

Releases don't feel risky because they fail. They feel risky because they are unpredictable.

The Myth of the "Perfect Release"

There is a quiet assumption behind many teams: If everything is done correctly, nothing will go wrong.

It sounds reasonable. It's also not true.

Systems are complex. Dependencies are not always visible. Production behaves differently. And people make decisions under pressure.

You don't get perfect releases. You get managed risk.

Where Things Actually Go Wrong

Most issues don't come from the places we expect.
They come from small decisions that feel harmless:

"It's a small change"
"Let's include this one as well"
"We don’t need to wait for this"

Each decision makes sense on its own. But they don't exist in isolation.
Over time, they accumulate. And the system becomes harder to reason about.

That's when releases start to feel risky.

Most teams try to solve this with process and tooling.

They define what "done" means.
They rely on automation.
They introduce canary releases.
They build dashboards.

And all of these help. But they also create a dangerous illusion: That if everything looks correct, everything is correct.

In reality:

A ticket can be "done" and still hide assumptions.
Tests can pass and still miss real behavior.
A canary can look healthy at 5% and fail at scale.
Dashboards can show green while something important is broken.

Release problems rarely come from one big mistake. They come from many small ones.

One extra ticket.
One skipped validation.
One assumption left unchecked.

Each decision feels reasonable. Together, they create unpredictability.

What Actually Helps

There's no single fix.
What works is consistency:

Only shipping work that is truly ready
Introducing changes in small steps
Detecting issues early
Recovering quickly and calmly

These are simple ideas. But they require discipline.

Practical Takeaways

If you want to improve your releases, start here:

Define what "release-ready" actually means — and stick to it
Reduce how much you ship at once
Keep your main branch releasable at all times
Monitor a few critical user flows closely after deployment
Make rollback simple and familiar

You don't need to fix everything at once.
Even one improvement can make releases feel more predictable.

Closing Thought

A utopian release is not one where nothing ever goes wrong.
It's one where things can go wrong — and it doesn't turn into chaos.
Where issues are expected, visible, and manageable.
Where releases stop feeling like events and start feeling like routine.

The goal isn't perfect releases.
It's releases you don’t have to be afraid of.

That's probably the closest thing to utopia we get.

Docker vs. Kubernetes: Which Is Right for Your DevOps Pipeline?

Isabelle M. — Sat, 16 Nov 2024 14:05:10 +0000

As modern applications grow in complexity, developers and DevOps teams face an important question: Docker or Kubernetes? These two tools are foundational in the DevOps ecosystem, yet they serve distinct purposes based on the scale and requirements of your application pipeline.

In this article, we'll break down their roles, address common myths, explore challenges, and provide practical guidance to help you decide which tool—or combination—is right for your workflow.

Docker and Kubernetes: Complementary Tools in DevOps

Docker and Kubernetes are not competing tools but complementary components in a modern DevOps workflow. Each serves a distinct role:

Docker: A containerization platform that simplifies packaging applications with dependencies into lightweight, portable containers. It’s indispensable for development, testing, and deployment.
Kubernetes: A container orchestrator that manages containers at scale, automating tasks like load balancing, scaling, and recovery, making it essential for production-ready applications.

Example: A developer might use Docker to create a container for a microservice and Kubernetes to deploy, scale, and monitor multiple instances of that container to handle user demand.

Addressing Common Misconceptions

Myth 1: You Must Choose Between Docker and Kubernetes

Reality: Docker and Kubernetes often work together. Docker handles container creation, while Kubernetes orchestrates and scales them across clusters.

Example: A development team might use Docker to package a microservice and Kubernetes to deploy and scale it across multiple servers.

Myth 2: Kubernetes Replaces Docker

Reality: Kubernetes builds on Docker (or another runtime) to manage clusters of containers. Think of Kubernetes as the conductor of an orchestra, with Docker playing the instruments.

Myth 3: Kubernetes is Essential for Every Workflow

Reality: Kubernetes can be overkill for small-scale projects or single-container applications, where Docker alone may suffice.

Myth 4: Docker Swarm and Kubernetes are Interchangeable

Reality: Docker Swarm is simpler but lacks Kubernetes’ advanced features like self-healing and multi-cloud support. Swarm is best for small-scale projects, while Kubernetes excels in complex environments.

Choosing Between Docker and Kubernetes for Your DevOps Pipeline

Every DevOps pipeline consists of distinct stages, and Docker and Kubernetes each shine in different areas. Let’s explore their strengths across key workflows:

Development, Local Testing, and Continuous Integration (CI)
- Best Tool: Docker
- Why: Docker simplifies creating lightweight, consistent environments that mirror production. Its isolated environments ensure reliable testing during development and CI pipelines, minimizing errors caused by mismatched configurations.
- Example: A developer working on a microservice can spin up a Docker container with the exact dependencies needed for development and testing. In CI pipelines, containers allow each build to run in a consistent environment, preventing interference from other processes.
- Pro Tip: Use docker-compose to manage multiple containers locally, and integrate Docker with CI tools like Jenkins, GitHub Actions, or GitLab CI for seamless automation.
Continuous Deployment (CD) and Production
- Best Tool: Kubernetes
- Why: Kubernetes excels at managing complex production systems. Its ability to handle load balancing, automatic scaling, and container recovery ensures applications remain stable even under high traffic or unexpected failures.
- Example: A high-traffic e-commerce platform uses Kubernetes to scale microservices during Black Friday sales automatically.
- Pro Tip: Use Helm charts to manage Kubernetes configurations and deployments more efficiently.
Multi-Cloud or Hybrid Environments
- Best Tool: Kubernetes
- Why: Kubernetes provides a unified way to deploy and manage containers across multiple clouds or on-premise setups, ensuring seamless integration and consistent deployment experiences.
- Example: A SaaS company deploying applications on both AWS and Google Cloud uses Kubernetes to ensure the same configurations are applied across regions.
- Pro Tip: Use Kubernetes operators to extend its functionality for specific cloud services like AWS RDS or GCP BigQuery.
Monitoring and Observability
- Best Tool: Kubernetes
- Why: Kubernetes integrates seamlessly with monitoring tools like Prometheus and Grafana, allowing teams to track resource usage, application performance, and potential bottlenecks.
- Example: A team monitoring microservice performance uses Grafana dashboards to identify latency issues in real time.
- Pro Tip: Set up alerts in Prometheus for automated issue detection and faster response times.

Alternatives to Docker and Kubernetes

Alternatives to Docker:

Podman: Rootless and daemonless, offering enhanced security.
LXC (Linux Containers): Lightweight containerization for simpler use cases.

Alternatives to Kubernetes:

Docker Swarm: Simpler orchestration for small projects.
Nomad: Supports mixed workloads and integrates with HashiCorp tools.
Serverless Frameworks: Event-driven platforms like AWS Lambda for lightweight applications.

Docker vs. Kubernetes: Pros and Cons

Here’s a quick comparison of their key features:

Feature	Docker	Kubernetes
Ease of Use	Intuitive for local environments and testing.	Requires orchestration and clustering knowledge but simplified by managed services.
Scalability	Ideal for single-host or small-scale applications.	Built to handle distributed, large-scale applications.
Resource Management	Basic capabilities; scaling is manual.	Advanced auto-scaling and scheduling.
Fault Tolerance	Limited failover capabilities.	Robust self-healing and failover mechanisms.
Deployment Speed	Quick setup for simple applications.	Slower initial setup but efficient for complex deployments.
Cost	Minimal infrastructure requirements.	Resource-intensive but can be optimized using cloud services.

Common Challenges and Solutions

Docker Challenges:

Dependency Bloat:
- Use multi-stage builds to reduce image size.
Security Risks:
- Use trusted images and avoid running containers as root.

Kubernetes Challenges:

High Complexity:
- Use managed services like GKE, EKS, or AKS to simplify cluster setup.
Monitoring Overload:
- Implement tools like Prometheus and Grafana to track metrics and set alerts.
Overhead for Small Projects:
- Consider lighter tools like Docker Compose for simpler applications.

Conclusion: Finding the Right Tool for Your DevOps Needs

Docker and Kubernetes are foundational to modern DevOps workflows. For small-scale workflows, Docker provides simplicity and efficiency. For distributed, high-traffic systems, Kubernetes offers unparalleled scalability and reliability.

Remember, these tools often work together to create seamless pipelines. Start small, experiment, and scale your approach as your needs evolve.

REST vs. GraphQL: Choosing the Right API for Your Project

Isabelle M. — Thu, 14 Nov 2024 23:09:20 +0000

In the world of APIs, REST and GraphQL are two popular choices, each offering unique advantages. Choosing the right approach can significantly impact the performance, flexibility, and scalability of your project. This article will explore the key differences between REST and GraphQL, providing insights to help you determine which is best suited for your needs.

What Is REST?

REST (Representational State Transfer) is an architectural style where clients interact with servers through specific endpoints and HTTP methods (like GET, POST, PUT, DELETE) to retrieve or modify data. Each REST endpoint represents a unique resource and returns standard HTTP status codes for handling errors and responses.

Simplicity: REST is straightforward and predictable, making it easy to work with.
Caching: REST endpoints suit caching well, improving performance in applications with repeated data requests.

REST API Example: Fetching a User Profile

In a REST API, you might retrieve a user's profile with a GET request to an endpoint like /users/123.

GET /users/123
Response:
{
   "id": 123,
   "name": "John Doe",
   "email": "john.doe@example.com"
}

REST is effective for simpler applications where data relationships are minimal and caching is important. Its predictable structure suits straightforward CRUD applications and microservices.

What Is GraphQL?

GraphQL, developed by Facebook, is a query language that lets clients define the exact data they need. Unlike REST, which requires multiple endpoints, GraphQL uses a single endpoint with flexible queries for specific fields, minimizing data transfer and enhancing efficiency.

Flexible Data Retrieval: Clients can request only the necessary data, reducing over-fetching and under-fetching.
Single Endpoint: With GraphQL, you use one endpoint, and clients specify the data structure they need.

GraphQL Example: Fetching a User Profile with Specific Fields

In GraphQL, you can fetch only the fields you need by specifying them in the query. Here's how a request for a user's profile might look:

query {
   user(id: "123") {
      id
      name
      email
   }
}

GraphQL is particularly beneficial in projects that require complex, nested data or real-time features. Its flexibility can significantly reduce data transfer, especially in mobile apps where network efficiency is crucial.

REST vs. GraphQL: Key Differences

Data Flexibility
- REST: With predefined endpoints, REST can lead to over-fetching or under-fetching, especially if the client doesn't need all the data an endpoint provides.
- GraphQL: Clients specify only the data they need, which makes data fetching more efficient and reduces bandwidth usage.
Example: Suppose you need a user's posts along with the profile data. In REST, you might need a separate endpoint to fetch posts, resulting in multiple requests. With GraphQL, you can retrieve everything in one request:
```
query {
  user(id: "123") {
     name
     posts {
        title
        content
     }
  }
}
```
API Structure
- REST: Uses multiple endpoints, each mapping to a specific resource (e.g., /users, /posts).
- GraphQL: Has a single endpoint that handles all requests, with clients specifying the data structure and fields they need.
Caching
- REST: Works well with HTTP caching since each endpoint has a predictable structure.
- GraphQL: Caching is more complex due to the dynamic nature of requests. GraphQL often requires specific client tools, like Apollo Client, to manage client-side caching effectively.
Error Handling
- REST: Uses standard HTTP status codes (e.g., 404, 500) for clear error handling, which is familiar to most developers.
- GraphQL: Errors are handled within the response body, so clients must parse responses to handle errors properly.

REST vs. GraphQL: Performance Considerations

REST can be faster for simpler applications due to HTTP caching and predictable, resource-specific endpoints. In cases with complex data requirements, however, GraphQL can be more efficient because it enables clients to fetch precisely the data they need in a single request. This can reduce network round-trips, which is beneficial for performance in applications with nested data. At the same time, complex GraphQL queries can increase server load due to custom query processing, so it's essential to consider your application's data complexity, caching needs, and server capacity.

Alternative API Approaches

While REST and GraphQL are popular, there are other API styles worth considering:

gRPC: Great for high-performance, low-latency applications, especially in microservices.
SOAP: Commonly used in enterprise applications with strict data validation and security needs.

These alternatives provide other design options if REST and GraphQL aren't the best fit for your specific requirements.

When to Use REST

REST might be the best choice if your project requirements include:

Simple Data Structure: When data doesn't require nested relationships, REST's straightforward nature fits well.
Standardized API: REST's use of HTTP codes makes it easy to understand and standardize, especially for public APIs.
Caching Needs: REST's endpoints are well-suited for caching, making it ideal for applications where caching is essential.

Ideal for: Microservices, CRUD apps, and APIs with simpler, non-nested data structures.

When to Use GraphQL

Consider GraphQL if your project requires:

Complex, Nested Data: GraphQL's nested queries are efficient for data-heavy applications where multiple related data points are needed.
Customizable Data: When clients need to fetch only specific fields, GraphQL is more efficient.
Real-Time Data: GraphQL's subscriptions allow for real-time data updates, which can be essential for applications needing live updates.

Ideal for: Mobile apps, real-time applications, and applications requiring highly flexible queries and efficient data fetching.

Actionable Checklist for Choosing REST vs. GraphQL

To make your decision even easier, here's a quick checklist:

Use REST if:
- Your data requirements are simple and flat.
- Caching is a high priority for your project.
- You want predictable endpoint structures for easier debugging.
Use GraphQL if:
- Your application needs flexible, nested queries.
- Reducing data over-fetching is critical for performance.
- Real-time data updates are part of the application requirements.

Conclusion

Both REST and GraphQL excel in different scenarios, and sometimes they can even complement each other within a project. REST is ideal for predictable data and caching needs, while GraphQL shines in applications requiring flexible queries and real-time updates.

Here's a quick summary table to help you decide:

Feature	REST	GraphQL
Data Flexibility	May lead to over/under-fetching	Highly flexible, request-specific fields
API Structure	Multiple endpoints for resources	Single endpoint with custom queries
Caching	Straightforward caching	More complex, often needs client tools
Error Handling	Uses HTTP status codes	Errors are within the response body

Understanding Git Branching in 5 Minutes

Isabelle M. — Sat, 02 Nov 2024 15:49:52 +0000

Git branching is an essential part of version control, allowing multiple people (or just you!) to work on features, fixes, and updates without disrupting the stable codebase. Understanding how to use branches in a project can help keep the workflow smooth and minimize conflicts. Here's a quick guide to Git branching basics.

What Is a Branch in Git?

In Git, a branch is a separate line of development that lets you work independently of the main codebase. When you create a branch, it's a copy of main (or master) where you can safely make changes without affecting the stable code.
Think of branches as different versions or "paths" of your project that can later be merged back together.

Working with Feature Branches in a Git Project

In a Git project, it's best practice to create a new branch for each feature or fix, keeping changes organized and minimizing conflicts. Here's the typical workflow for working on a feature branch:

Create a Feature Branch

Start by updating your local main branch with the latest code:
```
git checkout main
git pull origin main
```
Next, create and switch to a new branch for your feature, using a descriptive name like feature-login-form:
```
git checkout -b feature-login-form
```
Keep Your Branch Up-to-Date

As you work on your feature, other team members may make changes to main. Regularly sync your feature branch with main to avoid conflicts down the line:
```
git checkout main
git pull origin main
git checkout feature-login-form
git rebase main
```
If your branch is only being used by you, rebasing onto main keeps your branch history clean and linear by replaying your commits on top of the latest main. This minimizes conflicts during the final merge. However, if you're working on a shared branch, consider merging main instead of rebasing to avoid rewriting history and disrupting collaborators.
Merging Your Feature Branch into main

When your feature is complete, push your branch to the remote repository:
```
git push origin feature-login-form
```

Merging vs. Rebasing: When to Use Each

In a Git project, you have two main ways to integrate changes from one branch into another: merging and rebasing.

Merging: Keeps all original commits intact and adds a "merge commit" to combine branches. This approach is great for shared branches because it preserves the full commit history and is less disruptive.
Rebasing: Replays your commits on top of the latest main branch, creating a linear history without merge commits. It's ideal for keeping your branch history clean but should be done only on personal branches. Avoid rebasing environment branches or shared branches, as it rewrites history and may disrupt other team members' work.

In short, merge when you need a quick update and rebase when you want a tidy, linear commit history.

Best Practices for Branching

Use Descriptive Branch Names: Naming conventions (e.g., feature-, bugfix-, hotfix-) make it easy to understand the purpose of each branch.
Make Frequent, Focused Commits: Small commits with meaningful messages help with tracking changes and identifying issues.
Keep Your Branch Up-to-Date with main: Regularly syncing with main reduces conflicts during the final merge.
Use Integration Branches for Complex Features: For multi-person features, consider an integration branch to test combined changes before merging into main.
Use Feature Flags for Incomplete Features: Feature flags allow you to merge work early without exposing it to end users.

Git branching is a powerful tool that, when used effectively, helps teams manage complexity, avoid conflicts, and maintain a clean codebase. By following these branching strategies and best practices, you'll be well-prepared to handle both solo projects and collaborative work with confidence.

How to check if a tuple is empty in Python?

Isabelle M. — Sat, 24 Dec 2022 22:00:00 +0000

Just like lists, tuples are also a sequence of values and are considered falsy if they are empty. So, if you want to check if a tuple is empty, you can simply use the not operator.

empty_tuple = ()
non_empty_tuple = (1, 2, 3)

not empty_tuple # True
not non_empty_tuple # False

In the above code example, we can see that the not operator returns True if the tuple is empty and False if the tuple is not empty. The not operator is a unary operator that returns the opposite of the value it is applied to. Using the not operator is considered the most Pythonic way to check if a object is empty.

There are other ways to check if a tuple is empty. For example, you can use the len() function. This function returns the length of the tuple, which is 0 if the tuple is empty.

empty_tuple = ()
non_empty_tuple = (1, 2, 3)

len(empty_tuple) == 0 # True
len(non_empty_tuple) == 0 # False

One more way to check if a tuple is empty is to compare the tuple to an empty tuple using the == operator.

empty_tuple = ()
non_empty_tuple = (1, 2, 3)

empty_tuple == () # True
non_empty_tuple == () # False

Javascript Array.from() second argument

Isabelle M. — Sun, 18 Dec 2022 10:00:00 +0000

Array.from() is a method that creates a new array from an array-like or iterable object. However, one property that is often overlooked is that the method can accept a mapping function as a second argument.

This map function is called on every element of the array that is being generated. Basically, Array.from() with a function as a second argument is equivalent to Array.from().map() only that it does not create an intermediate array.

console.log(Array.from([1, 2, 3], x => x + x)); // [2, 4, 6]

One very simple use case for this is to create an array of a specific length and fill it with an arithmetic sequence.
For example, if you want to create an array of 5 elements and fill it with the value 1 to 5, you can do it like this:

const arr = Array.from({ length: 5 }, (v, i) => i + 1);
console.log(arr); // [1, 2, 3, 4, 5]

Why do SQL Server views need refreshing?

Isabelle M. — Sun, 04 Dec 2022 10:00:00 +0000

Views in SQL are a great way to simplify complex queries, to hide sensitive data, or to provide a different perspective on the data. But they can also be a source of confusion and frustration.

Why do SQL Server views need refreshing?

A view, basically, is a stored query represented as a virtual table. When you create a view, you can use it just like a table which means you can query it, join it, and use it in other queries. Basically, a view is a snapshot of the schema at the time it was created.
However, if a schema change occurs which causes the underlying object to change, the metadata of the view will not be updated automatically and the results of the view will be incorrect. Note that the need to refresh a view depends on the underlying object. For example, if the underlying object is a view, a refresh may not be needed.

Schema changes can be caused by a number of things, such as adding a new column to a table, changing the data type of a column, or even deleting a column. So basically if you have a view that references a table that has changed, you will need to refresh the view.

How to refresh a view

There are a few ways to refresh a view. The most common way is to use the DROP VIEW and CREATE VIEW statements. This will drop the view and then recreate it.

DROP VIEW view_name

CREATE VIEW view_name AS
SELECT column_name
FROM table_name
WHERE condition

This is a simple and effective solution, but it can be time-consuming if the view is complex.

Another way is to use the stored procedure sp_refreshview which is a system stored procedure available in SQL Server.

EXEC sp_refreshview 'view_name'

This stored procedure will refresh the view and update the metadata to match the base table.

Finally, if the tables are all in the same database on the same server you can use the option WITH SCHEMABINDING when creating the view.

CREATE VIEW view_name WITH SCHEMABINDING AS
SELECT column_name
FROM table_name
WHERE condition

This option binds the view to the schema of the underlying table. This means that this base table cannot be modified in a way that would affect the view definition. The view definition itself must first be modified or dropped to remove dependencies on the table that is to be modified.

When to use useRef() instead of useState()

Isabelle M. — Sat, 26 Nov 2022 22:00:00 +0000

In React, hooks are a way to use state and other React features without having to generate a class component. One of the most frequently used hook is useState(), however on occasion useRef() might be a better and more efficient way to manage state.
A common use case is handling a form input field when the submit button is clicked. For example, lets look at the following code snippet:

const [email, setEmail] = useState('');
const [password, setPassword] = useState('');

const handleSubmit = (e) => {
  e.preventDefault();
  console.log(email, password);
};

return (
  <form onSubmit={handleSubmit}>
    <input
      type="email"
      value={email}
      onChange={(e) => setEmail(e.target.value)}
    />
    <input
      type="password"
      value={password}
      onChange={(e) => setPassword(e.target.value)}
    />
    <button type="submit">Submit</button>
  </form>
);

In the above example, we have two input fields, one for the email and one for the password. When the submit button is clicked, the values of the two input fields are logged to the console. The useState() hook is used to manage the state of the two input fields. Although, this code does what it's supposed to do, it also causes the component to re-render every time the input fields are changed.

This is due to the usage of the useState() hook, which by definition causes the component to re-render every time the state is changed. This is not a problem in this example, but in a more complex application, this can cause performance issues. To avoid this, we can use the useRef() hook instead of useState().

const email = useRef('');
const password = useRef('');

const handleSubmit = (e) => {
  e.preventDefault();
  console.log(email.current, password.current);
};

return (
  <form onSubmit={handleSubmit}>
    <input
      type="email"
      value={email.current}
      onChange={(e) => (email.current = e.target.value)}
    />
    <input
      type="password"
      value={password.current}
      onChange={(e) => (password.current = e.target.value)}
    />
    <button type="submit">Submit</button>
  </form>
);

When to use `useRef()` instead of `useState()`

A rule of thumb is to use useState when you need to re-render the component when the state changes and useRef when you don't need to re-render the component when the state changes.
Here are some examples of when to use useRef instead of useState:

When you need to store a value that does not trigger a re-render when it is updated.
When you need to store a value that is not used in the render method.
When you need to store a value that persists for the lifetime of the component.

How can I set the value of a select input in React?

Isabelle M. — Sun, 20 Nov 2022 10:00:00 +0000

Adding selected to an option

A very common way of setting a <select> input's value is by adding a selected attribute to one of its <option> elements. For example:

const Select = ({ values, callback, selected }) => {
  return (
    <select
      disabled={disabled}
      readOnly={readonly}
      onChange={({ target: { value } }) => callback(value)}
    >
      {values.map(([value, text]) => (
        <option selected={selected === value} value={value}>
          {text}
        </option>
      ))}
    </select>
  );
}

Setting value for the select

While this approach closely resembles HTML and feels intuitive, there is an easier way to do the same thing. React provides us with a shared API between <input type="text">, <textarea> and <select> where we can use value or defaultValue (depending if the input is controlled or not) to set the field's value.

Using this API, we minimize the effort of checking for the selected value, as well as making the code easier to read and update as necessary. Here's an example:

const Select = ({ values, callback, selected }) => {
  return (
    <select
      disabled={disabled}
      readOnly={readonly}
      defaultValue={selected}
      onChange={({ target: { value } }) => callback(value)}
    >
      {values.map(([value, text]) => (
        <option value={value}>
          {text}
        </option>
      ))}
    </select>
  );
}

Note that the above implementation uses defaultValue, therefore it implies that the component is uncontrolled. You can convert this Select component into a controlled component by using value instead of defaultValue.

Do you like short, high-quality code snippets and articles? So do we! Visit 30 seconds of code for more articles like this one or follow us on Twitter for daily JavaScript, React and Python snippets! 👨‍💻

Tip: React conditional className, empty strings and null

Isabelle M. — Sun, 13 Nov 2022 10:00:00 +0000

When developing React components, you often need to conditionally apply a className attribute to one or more elements. Sometimes, you will have two or more possible values depending on a condition. But there are also times that you might apply a className based on a condition or leave it completely empty otherwise.

There is a correct way to handle a conditional empty className and an incorrect one. Surprisingly, the incorrect way is pretty common and examples of it can be found all around the web. Consider the following code:

const MyComponent = ({ enabled }) => {
  return ( <div className={enabled ? 'enabled' : ''}> Hi </div> );
};

const OtherComponent = ({ enabled }) => {
  return ( <div className={enabled ? 'enabled' : null}> Hi </div> );
};

ReactDOM.render(
  <>
    <MyComponent enabled={false} />
    <OtherComponent enabled={false} />
  </>,
  document.getElementById('root')
);

In this code example, we define two very similar components. Both of them conditionally set the className of an element based on the value of the enabled prop. The first one will set the className to an empty string if enabled is false and the second one will set it to null.

The resulting output is pretty similar. However, if you carefully inspect the HTML, you will notice that the first one will render <div class>Hi</div> whereas the second one will render <div>Hi</div>. This kind of markup (an attribute being present but without value) is rather uncommon and you'd rarely ever see something like that without React. This subtle difference is quite important and might be the root of a lot of problems, especially when writing CSS selectors for elements with/without any classes (e.g. [class]/:not([class])).

Therefore, you should prefer null when you don't want to add a className to an element, instead of an empty string. It keeps the markup cleaner and might help prevent some potential issues.

Tip: JavaScript array sorting shorthand

Isabelle M. — Sun, 06 Nov 2022 10:00:00 +0000

When sorting an array of primitive values (e.g. strings or numbers), you'll often see a lot of code that looks like this:

const arr = [8, 2, 1, 4, 5, 0];
// Sort in ascending order
arr.sort((a, b) => {
  if (a > b) return 1;
  if (b > a) return -1
  return 0;
}); // [0, 1, 2, 4, 5, 8]

While this piece of code does the job, there is also a one-line alternative for it. The trick hinges on Array.prototype.sort() expecting either a positive or a negative value to perform a swap between two elements, thus allowing for more flexible values than 1 and -1. Subtracting the numeric values in an array is sufficient and can also be used to sort the array the other way around:

const arr = [8, 2, 1, 4, 5, 0];
// Sort in ascending order
arr.sort((a, b) => a - b); // [0, 1, 2, 4, 5, 8]
// Sort in descending order
arr.sort((a, b) => b - a); // [8, 5, 4, 2, 1, 0]

If you are working with string arrays, you should instead use String.prototype.localeCompare(), as it provides far greater flexibility, by accounting for specific locales and their unique needs:

const s = ['Hi', 'Hola', 'Hello'];
// Sort in ascending order
arr.sort((a, b) => a.localeCompare(b)); // ['Hello', 'Hi', 'Hola']
// Sort in descending order
arr.sort((a, b) => b.localeCompare(a)); // ['Hola', 'Hi', 'Hello']

How can I execute an event handler at most once?

Isabelle M. — Sun, 30 Oct 2022 10:00:00 +0000

jQuery

Back in the day when jQuery was all the rage, we would usually use $.one() to create an event handler that would execute at most once for a given event per element. A simple example would be as follows:

<button id="my-btn">Click me!</button>

$('#my-btn').one('click', () => {
  console.log('Hello!');  // 'Hello!' will only be logged on the first click
});

Using a flag

However, jQuery seems to have fallen out of favor lately and thus many developers have resorted to writing their version of $.one(). An implementation could look like this:

const listenOnce = (el, evt, fn) => {
  let fired = false;
  el.addEventListener(evt, (e) => {
    if (!fired) fn(e);
    fired = true;
  });
};

listenOnce(
  document.getElementById('my-btn'),
  'click',
  () => console.log('Hello!')
);  // 'Hello!' will only be logged on the first click

In this implementation, we use a flag, fired, to check if the event has been triggered before and only execute the passed callback, fn, the first time the event is triggered. There are some details that we might have omitted such as removing the listener, but overall this is a reasonably solid implementation.

Event listener options

If you are targeting modern browsers (i.e. not IE), EventTarget.addEventListener() has introduced the options object parameter, which allows us to pass a few different flags, one of which is once. Setting once to true results in the exact same behavior as the snippet above with minimal effort.

Here's one way to write the previous snippet using once:

const listenOnce = (el, evt, fn) => el.addEventListener(evt, fn, { once: true });

listenOnce(
  document.getElementById('my-btn'),
  'click',
  () => console.log('Hello!')
);  // 'Hello!' will only be logged on the first click