DEV Community: Mía Salazar

How to Improve Performance in React Applications

Mía Salazar — Fri, 27 Mar 2026 12:22:38 +0000

Optimizing performance in React applications is essential to create smooth, fast, and responsive user experiences. React’s flexibility and component-based architecture allow developers to implement various strategies to enhance performance.

In this article, we’ll explore key techniques such as dynamic imports, list virtualization, and others to help you boost your app’s speed.

Dynamic Imports: Code Splitting for Faster Load Times

One of the most effective performance optimizations in React is code splitting, which allows you to load JavaScript files only when needed. This can drastically reduce the initial load time, especially for large applications. React’s dynamic imports enable you to load components and modules on demand, which means users only download the code they need.

With dynamic imports, you can split your application into smaller chunks and only load parts of the app when required. For example, you might load a component for a specific route only when the user navigates to it, rather than including it in the initial bundle.

By implementing dynamic imports, you improve your app’s initial loading time and reduce the amount of unnecessary code loaded upfront.

import React, { Suspense } from 'react';

const LazyLoadedComponent = React.lazy(() => import('./LazyLoadedComponent'));

function App() {
  return (
    <div>
      <Suspense fallback={<div>Loading...</div>}>
        <LazyLoadedComponent />
      </Suspense>
    </div>
  );
}

List Virtualization: Rendering Only What’s Visible

In applications that display large lists of data, rendering every single item at once can be a performance bottleneck. List virtualization solves this problem by only rendering the items visible on the screen at any given time, drastically reducing the number of DOM elements.

Libraries like react-window help implement list virtualization by rendering a small subset of items based on the visible area, improving rendering speed and reducing memory usage.

Memoize Expensive Calculations with useMemo

If you perform heavy calculations or transformations (like sorting, filtering, or mapping large arrays), memoize the result with useMemo so it's only recalculated when the inputs change.

const sortedList = useMemo(() => {
  return items.sort((a, b) => a.name.localeCompare(b.name));
}, [items]);

This avoids unnecessary recalculations on every render.

Preload Critical Resources

Use <link rel="preload"> or tools like React Helmet to preload fonts, critical images, or even API data you know the user will need immediately. This can significantly reduce LCP and improve perceived performance.

Smart Data Fetching with React Query

Managing server state efficiently is key to performance. Instead of manually fetching and storing data in state variables, libraries like React Query handle caching, background refetching, and request deduplication out of the box.

React Query can:

Cache requests and avoid redundant fetches.
Refetch data in the background without blocking the UI.
Handle loading, error, and success states automatically.

Optimize Images and Assets

Large or unoptimized images are one of the most common causes of slow-loading apps. To avoid this:

Use modern formats like WebP or AVIF
Compress images before loading
Use lazy loading (<img loading="lazy" />) for below-the-fold images
Leverage responsive images with srcSet for different screen sizes

<picture>
  <source media="(min-width:768px)" srcset="flowers-tablet.jpg">
  <img src="ppizza.jpg" alt="Pozza" style="width:auto;">
</picture>

Keep Components Small and Focused

Smaller components are easier to optimize, understand, and reuse. If a component does too many things, it’s more likely to re-render often. Split logic-heavy components into smaller children where only relevant parts update.

Analyze and Monitor with Performance Tools

Lighthouse (via Chrome DevTools or CI)
Web Vitals extension
React Profiler
Sentry/Datadog for performance monitoring

Measure, benchmark, and monitor performance to track regressions over time.

Use useEffect and useCallback Wisely

React’s useEffect and useCallback hooks are powerful, but they can easily become sources of performance issues if not used thoughtfully.

With useEffect, it's important to limit side effects to what’s necessary and avoid including unstable dependencies (like inline functions or objects) unless absolutely required. This reduces the risk of unnecessary re-renders or even infinite loops. Also, always clean up subscriptions or event listeners inside effects to prevent memory leaks.

On the other hand, useCallback helps memoize functions so they retain a stable reference between renders, useful when passing callbacks to memoized child components or when including functions as dependencies in useEffect. However, overusing useCallback can clutter your code and offer little benefit if the function isn’t passed as a prop or used in dependency arrays.

In short, use useEffect to manage external interactions and side effects with minimal, clear logic, and reserve useCallback for stabilizing functions that really need it. Used wisely, these hooks help you keep your components performant and predictable.

Conclusions

Performance optimization in React is not just about writing faster code. It's about making thoughtful architectural choices, leveraging the right tools, and reducing unnecessary work for the browser.

Focus on rendering only what’s needed, when it’s needed, and keep an eye on the network, re-renders, and the structure of your components. With these strategies in place, you’ll create React apps that are not only functional but delightfully fast.

Writing Scalable and Maintainable CSS: BEM, SMACSS and OOCSS

Mía Salazar — Thu, 12 Mar 2026 10:27:09 +0000

Managing CSS at scale is one of the hardest challenges in front-end development. As projects grow, CSS can easily become brittle, hard to maintain, and prone to unintended side effects due to excessive inheritance and uncontrolled specificity.

This article introduces some popular methodologies: BEM, SMACSS, and OOCSS, and explains how they help create scalable, modular CSS architectures with clear naming conventions, low specificity, and better separation of concerns.

The Problem: Cascading and Specificity

CSS was designed to cascade, but uncontrolled cascading often leads to:

Deep selector chains (.header .menu ul li a span { ... })
Overuse of !important
Inheritance leaks causing unintended style changes
Difficulty overriding styles without breaking existing layouts

When stylesheets become difficult to predict or extend, developers start fearing changes. The key is to avoid deeply nested selectors and manage specificity explicitly.

The Solution: Modular CSS Architecture

A modular CSS approach aims to:

Create independent, reusable components
Minimise selector specificity
Clearly separate structure (layout, positioning) from skin (visual appearance)
Use consistent naming conventions
Avoid over-reliance on inheritance

Let’s explore some well-known methodologies that encourage this.

BEM

BEM stands for Block Element Modifier, and it works like this:

Block: the standalone entity (e.g. card)
Element: a part of the block (e.g. card__header)
Modifier: a variant or state (e.g. card--highlighted)

BEM creates predictable class names with low specificity and no dependence on DOM structure or nesting. Besides, the low specificity makes these class names easy to override and compose.

<div class="card card--highlighted">
  <div class="card__header">Title</div>
  <div class="card__content">Content here</div>
</div>

SMACSS

Scalable and Modular Architecture for CSS (SMACSS) categorises CSS rules into five types:

Base: default browser styles (typography, resets).
Layout: large structural areas (grid, header, footer).
Module: reusable components (cards, buttons, forms).
State: UI states (.is-active, .is-hidden).
Theme: visual skins.

SMACSS encourages separation of concerns, promoting reusability and scalability, and it helps organise large codebases logically.

/* layout/_header.scss */
.header { ... }

/* module/_card.scss */
.card { ... }

/* state/_visibility.scss */
.is-hidden { display: none; }

OOCSS

Object-Oriented CSS (OOCSS) promotes splitting styles into:

Structure (object): layout and positioning.
Skin: colours, fonts, shadows, borders.

OOCSS encourages thinking of UI as reusable "objects" that can be extended visually through skins. It creates highly reusable elements, separating layout and appearance.

/* structure */
.box { display: block; padding: 1rem; }

/* skin */
.box--primary { background-color: blue; color: white; }
.box--secondary { background-color: grey; color: black; }

Managing Specificity and Avoiding Excessive Inheritance

All these methodologies share common goals:

Limit specificity: Prefer simple class selectors over IDs or long chains.
Avoid deep nesting: Don’t rely on parent-child structures (.nav .list .item .link), flat selectors are easier to override.
Use consistent naming: BEM-style or SMACSS naming conventions make styles easy to locate and modify.
Separate structure and skin: Keep layout and visual design decoupled.
Use utility classes for global states: e.g. .is-disabled

Conclusion

BEM, SMACSS, and OOCSS are not mutually exclusive: they share complementary principles that help you write predictable, maintainable, and scalable CSS. By embracing flat class-based selectors, separating concerns, and managing specificity, your front-end code will remain robust even as your project grows.

A clear modular architecture with naming conventions not only improves maintainability but also fosters team collaboration and confidence in styling changes.

Multiple header, footer, and h1 Elements: What Is Actually Accessible?

Mía Salazar — Fri, 20 Feb 2026 15:18:07 +0000

Questions about how many header, footer, or h1 elements are allowed in a page are extremely common in web development, and they are often framed as strict accessibility rules. In reality, accessibility is less about counting elements and more about meaning, structure, and relationships.

This article clarifies what is valid, what is accessible, and what actually matters when using header, footer, and h1 elements in a single document.

The Core Principle: Semantics Over Superstition

HTML is not a set of fragile rules that break accessibility when slightly bent. It is a semantic language designed to describe the structure of a document.

The key question is not "how many of these elements am I allowed to use?", but rather "Do these elements accurately describe the structure of the content?".

Multiple `header` Elements

Is it allowed? Yes. You can have multiple header elements in a single document. A header represents introductory content for its nearest sectioning ancestor, such as:

body
main
article
section
nav

Example

<header>
  <h1>Site name</h1>
</header>

<main>
  <article>
    <header>
      <h2>Article title</h2>
    </header>
    <p>Article content…</p>
  </article>
</main>

This structure is both valid HTML and accessible. Each header introduces its own section. Screen readers expose headers as structural landmarks tied to their sections. Multiple headers are not confusing when the hierarchy is clear.

Multiple `footer` Elements

Is it allowed? Also yes. Like header, the footer element is section-scoped. A footer contains information related to its nearest ancestor section, such as:

Author information
Related links
Metadata

Example

<article>
  <p>Post content…</p>
  <footer>
    <p>Written by Alex</p>
  </footer>
</article>

<footer>
  <p>© 2026 Example site</p>
</footer>

Screen readers announce footers as landmarks only when they are top-level. Nested footers are treated as part of their section, which is expected behaviour.

Multiple `h1` Elements

Is it allowed? A really strong yes. HTML5 explicitly allows multiple h1 elements. Each h1 represents the top heading of its sectioning context.

Example

<main>
  <article>
    <h1>Article title</h1>
    <section>
      <h2>Introduction</h2>
    </section>
  </article>

  <article>
    <h1>Another article</h1>
    <section>
      <h2>Overview</h2>
    </section>
  </article>
</main>

The Real Accessibility Question About Headings

The real issue is not the number of h1s, but whether the heading hierarchy makes sense.

A good heading structure involves headings that reflect the content structure, that levels are not skipped arbitrarily, and sections are clearly defined

//Poor Heading Structure

<h1>Main title</h1>
<h4>Subsection</h4>

Skipping levels creates confusion for screen reader users who navigate by headings.

Screen Readers and Navigation

Many assistive technology users navigate pages by headings, landmarks or regions. Proper use of header, footer, and heading levels enables faster navigation, clear mental models of the page and predictable reading order

The problem is not multiplicity: it is misrepresentation.

Practical Guidelines

header and footer elements should be used to introduce or conclude meaningful sections of content, not as generic wrappers. Headings should reflect the real structure of the page rather than visual styling choices, helping users understand how content is organised.

Clarity should always be prioritised over rigid or outdated rules, and heading navigation should be tested with a screen reader to ensure the structure works in practice.

If the structure makes sense to a human, it usually makes sense to assistive technology.

Conclusions

Using multiple header and footer elements in a document is both valid and accessible when they correctly describe their respective sections. Multiple h1 elements are also allowed and often appropriate, particularly in documents composed of distinct articles or regions.

Accessibility does not depend on counting elements, but on providing a clear and logical hierarchy that accurately represents the content.

HTML accessibility is ultimately about expressing meaning rather than following myths or arbitrary conventions.

When Does a Component Re-render in React?

Mía Salazar — Sun, 01 Feb 2026 19:53:25 +0000

React's declarative nature and virtual DOM abstraction make it deceptively easy to build complex UIs. However, understanding when and why a component re-renders is essential for performance, especially in larger applications. Re-renders can be cheap, but unnecessary ones add up.

This article explains the most common triggers of component re-renders and offers strategies for controlling them effectively.

What Triggers a Re-render?

When a component’s state changes using useState, React schedules a re-render of that component.

Every call to setCount with a different value will cause the component to re-render.

const [count, setCount] = useState(0);

const increment = () => setCount(count + 1);

Prop Changes

If a component receives new props (i.e., if the parent re-renders and passes new values), the child will also re-render by default.

If someValue changes (even if it’s deeply equal but a new reference), MyComponent will re-render.

<MyComponent data={someValue} />

Context Changes

React Contexts provide a way to share values across the component tree. Any update to a context value will re-render all consuming components.

When theme changes, ChildComponent and all others using useContext(MyContext) re-render.

<MyContext.Provider value={theme}>
  <ChildComponent />
</MyContext.Provider>

Parent Re-renders

Even if a child’s props didn’t change, it can re-render if its parent re-renders unless it’s memoised with React.memo.

React Reconciliation: How React Decides to Re-render

React uses referential equality (===) to compare props and state. If something changes, a new object, array, or primitive, it assumes the UI might need to update.

This is why using immutable patterns is crucial. Mutating objects without changing their reference can lead to bugs or skipped renders.

How to Prevent Unnecessary Re-renders

Use React.memo for Pure Functional Components

Only re-renders if name changes.

const MyComponent = React.memo(({ name }) => {
  console.log("Rendered!");
  return <div>{name}</div>;
});

Use useCallback and useMemo to Stabilise Functions and Values

Without useCallback, the function is recreated on every render and may cause children to re-render unnecessarily.

const handleClick = useCallback(() => {
  // Do something
}, []);

Avoid Inline Objects and Arrays in Props

// Causes re-render
<Component data={{ a: 1 }} />

// Use useMemo
const data = useMemo(() => ({ a: 1 }), []);
<Component data={data} />

Keep State Local Where Possible

Lifting state up or storing too much in global context can lead to unnecessary tree-wide re-renders. Keep state close to where it’s used.

Conclusion

Understanding when React re-renders a component is vital to building performant and predictable interfaces. State, props, context, and parent updates are the primary causes. By embracing immutable patterns and using tools like React.memo, useCallback, and useMemo, you can significantly reduce unnecessary rendering and boost the responsiveness of your application.

Regular Functions vs Arrow Functions in JavaScript

Mía Salazar — Mon, 26 Jan 2026 08:34:50 +0000

JavaScript offers two main ways to declare functions: regular functions and arrow functions. While both can perform the same tasks, they behave differently in key areas, especially regarding this, arguments, and how they’re used in front-end development.

`this` Binding

Regular functions get their own this depending on how they’re called. this changes based on who calls the function.

const button = document.querySelector('#myButton');

button.addEventListener('click', function () {
  console.log(this); // 'this' = the button
});

In this case, this refers to the button that was clicked

Arrow functions don’t have their own this; they inherit it from their surrounding scope. this comes from where the function is written.

This makes arrow functions ideal in situations where you want to keep the context

const button = document.querySelector('#myButton');

button.addEventListener('click', () => {
  console.log(this); // 'this' = window or outer scope
});

Here, this does not refer to the button.

Arguments Object

The arguments object is a built-in feature in regular functions in JavaScript. It contains an array-like list of all the values passed to that function, even if they weren’t defined as parameters.

Regular functions have access to the arguments object, an array-like list of arguments passed to the function.

function showArguments() {
  console.log(arguments);
}

showArguments('Hello', 42, true);
// Output: ['Hello', 42, true] (in modern browsers)

Arrow functions do not have their own arguments. You need to use rest parameters instead (...args).

If you try to use arguments inside an arrow function, it won’t work the way you might expect. If you need to collect arguments in an arrow function, use the rest parameter syntax:

const showArguments = (...args) => {
  console.log(args);
};

showArguments('Hello', 42, true);
// Output: ['Hello', 42, true]

Constructors

Regular functions can be used as constructors with new.

function Person(name) {
  this.name = name;
  this.sayHello = function () {
    console.log(`Hello, I'm ${this.name}`);
  };
}

const user = new Person('Alice');
user.sayHello(); // Hello, I'm Alice

Arrow functions cannot be used that way. They’re not constructors.

const Person = (name) => {
  this.name = name;
  this.sayHello = () => {
    console.log(`Hello, I'm ${this.name}`);
  };
};

const user = new Person('Alice'); // ❌ TypeError: Person is not a constructor

Syntax

Arrow functions are more concise, especially for one-liners or callbacks.

Conclusion

Arrow functions and regular functions both allow you to define reusable blocks of code. However, they serve slightly different purposes in modern JavaScript.

Arrow functions are shorter, cleaner, and automatically bind this and arguments from their surrounding context. This makes them ideal for callbacks, array methods, and React components, where you want predictable scope and no surprises with this.

On the other hand, regular functions are more flexible when you need your function to have its own this, use the built-in arguments object, or act as a constructor with new. They are better suited for event handlers on the DOM, older codebases, or where full control over the function context is required.

Understanding when to use each helps keep your code readable, efficient, and bug-free, especially in front-end development where scope confusion is a common issue.

Human‑Driven vs AI‑Driven IDEs

Mía Salazar — Fri, 09 Jan 2026 09:29:09 +0000

AI‑powered IDEs such as Cursor, VS Code with Copilot, and WebStorm AI Assistant are rapidly becoming part of everyday development. They can autocomplete code, refactor components, generate tests, and explain unfamiliar APIs.

There is, however, a crucial distinction in how these tools are used:

AI‑driven development: the IDE leads, the human reacts.
Human‑driven development: the human leads, the AI assists.

This article explains that distinction, why human‑driven workflows matter for teams, and how to configure AI‑enabled IDEs (with Cursor as a concrete example) to support that approach.

What Do We Mean by AI‑Driven?

An AI-driven workflow is one in which the developer accepts large AI-generated blocks of code with little or no critical review, allows the AI to make decisions about architecture, naming, and patterns, and increasingly relies on the tool to “solve” problems instead of reasoning through them. In this model, the AI effectively leads the development process, while the human mainly reacts to its output.

// Prompt: "Create a responsive navbar in React"

export default function Navbar() {
 return (
  <nav>
   <ul>
    <li>Home</li>
    <li>About</li>
    <li>Contact</li>
   </ul>
  </nav>
 );
}

This code works, but the AI has implicitly made design decisions on behalf of the team, without considering accessibility, responsiveness, design‑system conventions, or state management. These omissions are subtle, but they accumulate quickly in real codebases.

What Is Human‑Driven Development?

Human‑driven development keeps intent, judgement, and responsibility firmly with the developer.

In a human-driven approach, the AI is treated as a fast typist, a refactoring assistant, and a source of suggestions rather than a decision-maker. The human developer defines what needs to be built and why, while the AI helps with how to implement it, and all generated code is carefully reviewed, understood, and adapted to fit the wider system and context.

interface NavItem {
 label: string;
 href: string;
}

const navItems: NavItem[] = [
 { label: 'Home', href: '/' },
 { label: 'About', href: '/about' },
 { label: 'Contact', href: '/contact' },
];

export function Navbar() {
 return (
  <nav aria-label="Main navigation">
   <ul className="nav-list">
    {navItems.map(item => (
     <li key={item.href}>
      <a href={item.href}>{item.label}</a>
     </li>
    ))}
   </ul>
  </nav>
 );
}

Here, the AI may have helped with typing or mapping logic, but the structure is intentional, accessibility is explicit, and data is separated from presentation

Using Cursor as a Human‑Driven IDE

Using Cursor effectively requires deliberate constraints. Its deep AI integration can easily shift control away from the developer if left unchecked.

A human‑driven setup starts by making intent explicit before invoking AI, through comments, partial implementations, type definitions, or clearly stated constraints. This anchors suggestions in the developer’s reasoning and ensures that the tool responds to existing context rather than introducing unsolicited structure or assumptions.

In practice, Cursor works best when used incrementally. Inline completions and small, reviewable changes encourage understanding and ownership. Conservative configuration helps prevent large, unexamined rewrites. Treated this way, Cursor becomes an accelerator for well‑defined ideas rather than a substitute for architectural thinking or judgement.

Configuration Files for a Human‑Driven Cursor Setup

A key part of keeping Cursor human‑driven is making your preferences explicit in configuration files. This reduces accidental AI overreach and aligns the tool with team standards.

1. Project‑Level Rules (`.cursor/rules.md` or similar)

Use a project‑local rules file to describe how the AI should behave.

# AI Usage Rules

- Do not introduce new libraries without asking
- Prefer existing project patterns over generic best practices
- Optimise for readability over cleverness
- Always respect accessibility (WCAG) concerns
- Never change public APIs unless explicitly requested

This works especially well in teams, as it makes expectations explicit and repeatable.

2. Editor Settings (`settings.json`)

Cursor builds on VS Code, so editor configuration still matters.

{
  "editor.inlineSuggest.enabled": true,
  "editor.suggest.preview": true,
  "editor.acceptSuggestionOnEnter": "off",
  "cursor.ai.autoGenerate": false,
  "cursor.ai.inlineSuggestions": true,
  "cursor.ai.confirmLargeChanges": true
}

These settings bias toward small, intentional interactions rather than wholesale generation.

3. Repository Documentation (`CONTRIBUTING.md`)

Document how AI is expected to be used in the repository.

## AI‑Assisted Development

AI tools may be used for:
- Refactoring
- Test generation
- Documentation improvements

AI tools should not be used for:
- Designing core architecture
- Introducing new patterns without review
- Replacing code reviews

This makes AI usage part of the team’s social contract, not an implicit or ad‑hoc practice

4. Optional: Prompt Templates

Some teams keep prompt snippets in the repo for consistency.

## Refactoring Prompt

Refactor the selected code:
- Keep the public API unchanged
- Do not introduce new dependencies
- Prefer clarity over abstraction
- Explain the changes briefly

This reduces vague prompts and improves output quality.

Human‑Driven Prompting Patterns

Instead of vague prompts like "Build this component", use constrained prompts such as:

"Refactor this function to be more readable, keep the API unchanged"
"Suggest accessibility improvements only, no visual changes"
"Explain this code rather than rewriting it"

One effective pattern is using AI for review, not creation. The AI becomes a second pair of eyes, not the primary author.

// Ask the AI:
// "What edge cases am I missing here?"

function formatPrice(value: number) {
  return `£${value.toFixed(2)}`;
}

Why Human‑Driven Matters in Front‑End

Front‑end code is not just about logic; it directly shapes user experience, accessibility, performance, and visual consistency. Every component encodes product decisions and design intent.

AI models have no real understanding of your users, business goals, regulatory constraints, or design system nuances. When they lead, those concerns are flattened or ignored.

Human‑driven workflows help teams:

Avoid fragmented UI patterns
Preserve long‑term code quality
Reduce hidden technical debt
Improve readability and onboarding
Maintain shared understanding across the codebase

By keeping intent and judgement with developers, teams gain speed without sacrificing coherence.

Conclusion

AI‑enabled IDEs are not inherently good or bad; the real risk lies in ceding intent.

By defining goals clearly, configuring tools conservatively, and treating AI as an assistant rather than an architect, developers can benefit from increased velocity without losing understanding or ownership.

Human‑driven development is not slower: it is deliberate. And in UI‑centric codebases, that deliberation is a feature, not a bug.

Replacing Toasts with Accessible User Feedback Patterns

Mía Salazar — Tue, 18 Nov 2025 18:43:49 +0000

Providing users with timely and meaningful feedback is essential for a usable digital experience. However, one of the most common UI patterns, toast notifications, often introduces serious accessibility barriers. Toasts tend to appear unpredictably, disappear too quickly, lack keyboard accessibility, and are rarely announced properly by assistive technologies.

This article explores why toast notifications often fail to meet WCAG guidelines, and proposes accessible alternatives, complete with example code snippets.

Why Toasts Are Problematic

Toasts typically violate several WCAG 2.2 success criteria

Non-interruptive timing issues: Toasts frequently appear for only a few seconds, preventing some users from perceiving them.
Lack of screen reader announcement: Many toasts are not implemented as live regions, meaning assistive technology users may never know they were there.
Keyboard inaccessibility: If the toast contains actionable elements (e.g., an “Undo” button), users often cannot tab into it before it vanishes.
Unexpected appearance on screen: Toasts that slide into view can cause layout shifts or distract users.

Accessible Alternatives to Toast Notifications

Use Persistent Status Message Regions

Avoid transient pop-ups and instead display status messages in a consistent, easily discoverable location, typically above the main content or directly beside the component that has changed.

This ensures the message:

Is always in a predictable location (WCAG 3.2.3 Consistent Navigation)
Can remain visible until dismissed (WCAG 2.2.1 Timing Adjustable)
Can be announced with aria-live (WCAG 4.1.3 Status Messages)

<div 
  aria-live="polite"
  aria-atomic="true"
  id="status-message">
</div>

Use Inline Feedback Near the Trigger

For actions such as form submissions or toggles, providing feedback next to the interactive element can help users immediately associate the message with the action they performed.

<button id="save-btn">
  Save
</button>
<span 
  id="save-feedback"
  class="visually-hidden"
  aria-live="assertive"
></span>

Use a Non-modal, Dismissible Alert Component

If a notification must stand out, consider an alert component fixed to the top of the page or container. Ensure it:

Stays visible until user dismissal (WCAG 2.2.1 Timing Adjustable)
Is reachable via keyboard (WCAG 2.1.1 Keyboard)
Is properly announced (WCAG 4.1.3 Status Messages)

<div
  id="alert"
  class="alert"
  role="alert"
  tabindex="-1"
  hidden
>
  <p id="alert-text"></p>
  <button aria-label="Dismiss alert" id="alert-dismiss">×</button>
</div>

Keep Animations Minimal and Optional

Some users may experience distraction or discomfort from motion. It is recommended to avoid unnecessary motion unless essential to functionality (WCAG 2.3.3 – Animation from Interactions) and respect the user’s “prefers-reduced-motion”.

@media (prefers-reduced-motion: reduce) {
  .alert {
    transition: none;
  }
}

Conclusion

Toasts may be familiar and visually appealing, but they often create accessibility barriers. By using persistent status areas, inline messages, or properly implemented alert components, designers and developers can ensure all users, including those with assistive technologies, can perceive, understand, and respond to important feedback.

Replacing toasts with more accessible patterns not only improves compliance with WCAG but also leads to clearer, more reliable communication across your interface.

Why Skipping Frontend Tests Always Backfires

Mía Salazar — Wed, 22 Oct 2025 07:05:38 +0000

Every team has that one person, or two, who insists that “frontend tests are a waste of time.”

They might say E2E tests are flaky, or that QA already does the job. But deep down, skipping tests isn’t a bold time-saving move; it’s a long-term productivity trap.

Here’s how to win the argument (and save your project from endless regressions).

Why Testing Matters, even on the Frontend

1.Tests catch regressions before your users do

Frontend changes are deceptively simple. You tweak a component or update an API call, and suddenly the login form stops working.

Having automated tests for critical flows (login, checkout...) ensures that your app’s core functionality never silently breaks. Without tests, the real testers are your users, and they’re the worst kind of testers.

2.They actually save time

Fixing a bug found in production takes exponentially more time than catching it during development. Manual QA can’t rerun every scenario on every release, but a test suite can, in seconds.

So while writing tests feels slow upfront, it pays off every sprint.

3.They make refactoring safe

When your codebase grows, refactors are inevitable. Without tests, developers fear touching anything. With tests, you can confidently restructure, optimize, or modernize your code, knowing that your safety net will catch regressions instantly.

4.They force better code design

Writing testable code means separating responsibilities and avoiding hidden side effects. Tests naturally lead to cleaner, more modular, and easier-to-understand components.

In the long run, this reduces onboarding time for new developers and increases overall code health.

5.You don’t need 100% coverage

Nobody’s asking for full-blown test coverage. Start small: Cover only the key integration flows.

Common Objections, and How to Defeat Them

"Tests are too fragile": Badly written tests can be unstable, but using modern tools, and using them well, makes them reliable and maintainable.
"We don’t have time": Skipping tests saves time only in the short term. Bugs found later cost far more to fix and slow development over time.
"QA already checks that": QA should focus on exploratory and edge-case testing, not on repeating the same core flows every release.
"Our app changes too often": Frequent changes increase the risk of regressions. Well-structured tests provide confidence and prevent hidden breakages.
"Tests slow us down": Full E2E coverage can be slow, but a balanced strategy, focusing E2E on key user flows and using faster integration or unit tests elsewhere, keeps feedback loops quick and efficient.

Why End-to-End tests alone aren’t enough

E2E tests are fantastic, they simulate real user behavior and verify that everything works together. But relying only on E2E tests is like checking if your car drives without ever opening the hood.

Here’s why that’s risky:

E2E tests are heavy and slow: They take longer to run and are more brittle because they depend on the full stack being up and stable.
When they fail, it’s hard to know why: A single failing E2E might mean a backend bug, a frontend change... Debugging takes longer than if you had smaller, faster integration or unit tests.
You lose granularity: Without lower-level tests, you can’t easily isolate where a bug originates.
They don’t scale well: Large teams need fast feedback loops. Having only E2E tests means waiting minutes (or hours) for CI runs instead of seconds for unit tests.

Conclussions

Convincing someone to write tests isn’t about dogma: it’s about pragmatism. It’s insurance against chaos. Start small, show quick wins, and let the results speak for themselves. Before long, your once-skeptical teammate will be willing to create more tests.

Modals and accessibility

Mía Salazar — Tue, 14 Oct 2025 07:18:48 +0000

Modals are a frequently used element on web pages. These components appear as overlays on the current page, preventing full view and interaction with the underlying content. They are often used for confirmation or cancellation screens, or to request additional details on a subject.

While common in design, modals can be a real challenge for keyboard or screen reader users if not properly implemented.

Opening the Modal

An essential aspect is how the modal opens. When a modal is triggered, the focus should shift to the first interactive element within it. Interactive elements include links, buttons, and form elements like input or select.

Screen readers

To ensure compatibility with screen readers, the modal should be properly identified using role="dialog" (or role="alertdialog") and aria-modal="true". This informs assistive technologies that the rest of the page is inactive while the modal is open.

In older implementations, developers often used aria-hidden="true" to hide background content from screen readers. However, this approach is more error-prone and harder to maintain, especially in complex applications, so aria-modal="true" is now the preferred solution.

Regardless of the approach, it's still necessary to manage focus and prevent interaction with background content through proper focus trapping and scripting.

ARIA roles and relationships

To make modals fully accessible to assistive technologies, it is important to correctly define their structure and semantics using ARIA attributes.

First, every modal should have a clear accessible name. If the modal includes a visible title, the container element with role="dialog" should reference it using aria-labelledby. This ensures screen readers announce the modal with its proper title.

Additionally, if the modal contains descriptive text that explains its purpose or provides context, this should be associated using aria-describedby. This allows screen readers to read both the title and the supporting description when the modal is opened.

<div role="dialog" aria-labelledby="modal-title" aria-describedby="modal-description" aria-modal="true">
  <h2 id="modal-title">Delete account</h2>
  <p id="modal-description">This action cannot be undone.</p>
</div>

Another important attribute is aria-modal="true". This indicates to assistive technologies that content outside the modal is inert (non-interactive) while the modal is open.

Difference between role="dialog" and aria-modal="true"

Although often used together, these attributes serve different purposes:

role="dialog" defines the element as a dialog (a modal window) and provides semantic meaning to assistive technologies.
aria-modal="true" indicates that the dialog is modal, meaning interaction is limited to the dialog and background content should be ignored.

In other words, role="dialog" tells what the element is, while aria-modal="true" tells how it behaves.

Both should be used together for proper accessibility support, especially since not all assistive technologies fully infer modality from the role alone.

Focus trapping

Keyboard users can accidentally navigate out of an open modal, which can lead to confusing interactions with elements behind the modal. To prevent this, implement focus trapping.

Focus trapping is a technique that ensures the focus remains within the modal while it is open. This way, a keyboard user cannot leave the modal until it is closed or the necessary action to close it is performed.

This technique is crucial for accessibility, as it prevents interactions with elements behind the modal and creates a circular navigation among the elements within the modal.

There are numerous articles on how to implement focus trapping in React
or Vanilla JavaScript, among other frameworks.

Escaping the Modal

Users often expect pressing the Escape key to close the modal. Therefore, it's important to implement this functionality. Additionally, when the modal closes, the focus should return to the element that triggered the modal.

General tips

To conclude, here are some general tips for improving the accessibility of your modals:

On mobile or small devices, modals should occupy the entire screen to enhance readability. On larger screens, use an opaque or semi-opaque layer beneath the modal to improve visibility.
Each modal should have a title explaining its functionality to make its purpose clear. The close button should be visible and large enough to be easily clicked, at least 44px by 44px.
Use semantic HTML for all elements within the modal. The more information we provide to assistive technologies, the better.
Prevent background scrolling when the modal is open to avoid confusion.

Conclusions

Building accessible modals requires more than just visual design: it involves careful consideration of semantics, focus management, and user interaction. Using role="dialog" together with aria-modal="true" provides the necessary context for assistive technologies, while aria-labelledby and aria-describedby ensure the modal is properly announced with meaningful information.

However, ARIA alone is not enough. Proper focus management (including focus trapping and restoring focus on close) and preventing interaction with background content are essential to create a predictable and usable experience for all users. An accessible modal should behave consistently across input methods, keyboard, screen reader, and pointer, ensuring that all users can interact with it effectively and without confusion.

How to Find a Job in Tech: Practical Advice for Navigating a Tough Market

Mía Salazar — Sat, 30 Aug 2025 12:18:15 +0000

In recent years, finding a job in tech, especially in software development, has become increasingly challenging. The market is more saturated, competition is stronger, and fully remote opportunities are no longer as abundant or well-paid as they once were. As someone who's been through this process, I want to share some practical tips that have helped me and might help you too.

Phase 1: Define Your Strategy

1. Choose Your Focus (But Stay Flexible)

Before you start applying, think carefully about what you want to do. The more specific your goal, the harder it might be to land interviews. For instance, if you only look for React roles, you may be missing out on opportunities that require other frameworks. I recommend checking out which technologies are in demand. Then, decide what you want to prioritize, both for now and your long-term career.

2. Decide on the Work Model (Remote, On-site, Hybrid)

Remote work is much harder to get nowadays, especially fully remote roles. These positions are often more competitive and sometimes come with lower salaries. Choosing on-site or hybrid may increase your chances of getting hired faster, depending on your location and flexibility.

3. Define a Salary Range (and Make Sure It’s Realistic)

Have a clear salary expectation, but verify that it's in line with market standards. Remember: fully remote jobs tend to pay less, especially if you're based in countries with lower cost of living.

4. Open Up to International Markets

If you speak other languages, consider applying internationally. English is the key to most global opportunities, but you'll need to be comfortable enough to handle technical interviews. Confidence in both communication and coding is essential.

5. Add a Timeframe to Your Plan

Set time-based checkpoints to reassess your strategy. For example:

“If I haven’t found a job in 3 months, I’ll start considering hybrid roles.”
“If after 2 months there are no responses, I’ll expand my search to include more tech stacks.”

These personal deadlines help you stay grounded and prevent frustration from growing aimlessly. Adapting doesn't mean giving up, it means staying strategic.

Phase 2: Search Effectively

6. Be Systematic

Choose a few job platforms that work well for you, don’t try to monitor 300 websites or you might end up losing your mind. Search daily using a variety of keywords. For example, if you're a frontend developer, search terms like “frontend developer,” “front-end engineer,” “React,” etc. Keep track of where you’ve applied and what keywords work best.

7. Track Your Progress with a Spreadsheet

Create an Excel or Google Sheets file with key information:

Company name
Work model (on-site/remote/hybrid)
Work hours and flexibility
Salary range offered
Link to the job post
Contact person
Application status (e.g., applied, phone screen, rejected)
Phase at which you were rejected

Use this data to identify patterns. If you’re consistently dropped at the same stage (e.g., technical interview), that’s a signal to improve in that area.

8. Stay Responsive: Check Your Phone & Email Regularly

Recruitment processes can move fast. Stay reachable:

Keep your phone on sound
Check your email and LinkedIn messages frequently
Save the phone numbers of recruiters with the company name, so you recognize who’s calling
Update your Excel tracker with any contact details to stay organized

Being responsive helps you avoid missing important calls or time-sensitive opportunities.

9.Pace Yourself: Don’t Burn Out

If you're in a rush to find a job, you might feel the need to apply to everything and enter multiple processes at once. That’s okay, but you must prioritize:

Focus on the roles that look most promising
Sometimes you’ll need to choose between two take-home assignments. Decide which company is more aligned with you

Try not to schedule more than 2–3 interviews per day, and leave breaks between them to avoid mental exhaustion. If you’re not in a rush, take it slower:

Space out interviews and assignments
Be selective with where you apply
Choose when and how to give your best energy

Even if time is tight, structure your week so that you stay sane. Good organization beats frantic multitasking.

10. Know Your Strengths (and Gaps)

If you’re applying to jobs using technologies you haven't worked with in a while (e.g., Angular or Vue when you've only used React recently), be prepared. Consider building a small project (a “pet project”) with those technologies so you’re not caught off guard during technical interviews.

Phase 3: Prepare Your Materials

11. Build a Strong CV (in All Relevant Languages)

Your CV should be detailed and tailored to the roles you’re applying for. Include:

Exact dates of employment (month/year)
Technologies used
Projects and responsibilities
Architecture, methodologies, and principles followed

Forget the “1-page CV” myth. More pages are fine if the content is valuable. Have it available in multiple formats (PDF, DOC) and in all the languages relevant to your job search.

12. Write Custom Cover Letters

Always include a cover letter tailored to each company. Read the job description carefully, and align your message with what the company is looking for.

Phase 4: Interview Preparation

13. Know Your Rights: Watch Out for Illegal Questions

Before your interviews, take a moment to review local labor laws regarding job interviews. For example, in Spain it’s illegal for interviewers to ask about your age, marital status, sexual orientation, or family plans. They cannot legally discriminate based on any of those factors

If you're asked inappropriate or illegal questions:

Politely deflect or refuse to answer
Take it as a red flag. If they disregard the law during recruitment, it might reflect deeper problems within the company culture
Don’t hesitate to walk away from companies that cross these boundaries. Your well-being and rights matter more than any offer

Being aware of these laws helps you protect yourself and recognize trustworthy employers.

14. Be Consistent in Your Narrative

Make sure your answers align with your stated long-term goals.
For example:

If you say your goal is to move into management, reinforce this by mentioning leadership experiences, mentoring juniors, taking responsibility, etc.
Avoid giving conflicting answers that make your story seem incoherent

A coherent, consistent narrative shows you’re clear about your goals and reliable in your planning.

15. Prepare a Solid Answer for: "Why Are You Leaving Your Current Job?"

This is one of the most common and delicate questions.
Avoid answers that:

Criticize your colleagues ("my coworkers were unbearable")
Make you sound unstable ("I get bored quickly")
Raise concerns about your teamwork or long-term commitment

Instead, focus on positive, professional reasons:

Seeking new challenges
Wanting to grow technically
Looking for better alignment with your career path
Company restructuring (if applicable)

16. Maintain a Stable Career Timeline (If Possible)

Frequent job changes or unexplained employment gaps can make HR suspicious:

They may wonder if you fail probation periods
They may worry that you’ll leave quickly again
They may question your ability to integrate into teams

Of course, sometimes short stays or breaks are legitimate:

You tried a company and it wasn’t the right fit
You needed personal time off
There were economic layoffs

If this happens, learn how to explain these gaps calmly and professionally.

17. Don’t Speak Badly About Former Employers or Coworkers

Even if you had very negative experiences, avoid badmouthing previous companies or colleagues. Why?

It can raise red flags about your teamwork skills
It can make interviewers wonder if you’ll speak the same way about them later
It shows a lack of professionalism

Focus on what you learned, what you’re looking for now, and how you want to grow.

18. Research the Interviewers & Use AI to Simulate Interviews

Before your interview, try to identify who will be interviewing you:

Look them up on LinkedIn or the company website
Check their roles, backgrounds, technical focus, and seniority

This can give you hints on the likely topics:

Are they more focused on culture?
Are they technical experts in certain stacks?
Are they product-oriented?

Once you know who you’ll be talking to, you can use AI tools like ChatGPT to:

Generate possible behavioral or culture-fit questions based on the company’s mission and values
Simulate technical interview questions for the specific tech stack
Generate product-oriented questions if the role is customer-facing or domain-specific
Practice your answers to feel more confident

You can also search online for "Technology interview questions" to review common technical challenges for your target role.

19. First Interview: Know the Company & Sell Yourself

Before your first interview:

Review the job description
Identify which of your strengths align with the role
Research the company to understand its mission and product

During the interview, confidently (but humbly) talk about what you’re proud of. Show enthusiasm and provide context for your skills and experience.

Adapt your tone and focus depending on the company: If they emphasize culture fit, show how your values align. If they stress technical depth, highlight your hard skills and project experience.

20. Look Professional (Even on Camera)

Appearances matter, especially in remote interviews. Make sure:

You have good lighting and your face is clearly visible
Your camera angle is at eye level
You wear clean, professional-looking clothes (even if it’s just the top half!)
You use a neutral or blurred background if your real one isn’t suitable

These small touches help you appear prepared and confident.

21. Technical Interview: Review the Stack

If a technical interview is part of the process, go over the technologies listed in the job ad. Prepare for common interview questions and brush up on both basic and advanced concepts depending on the level of the role.

If you consistently fail technical interviews on certain technologies or topics, identify them and study them intentionally. Practice with exercises, tutorials, and small projects to build confidence.

22. Ask Questions & Seek Feedback

At every interview stage, ask questions:

In HR interviews, ask about working conditions, team structure, and expectations.
In technical interviews, ask thoughtful questions about their stack, architecture, or dev culture. It shows interest and depth.

Always request feedback after interviews. Whether you pass or not, it can help you improve. After technical challenges or live coding, thank the interviewers for their time and note what you learned.

It leaves a good impression and helps build relationships.

23. Watch Your Words Until the Very End

Often, we think the interview is going either really well or terribly, and we relax, or panic, and say things we shouldn't. Don’t make that mistake.
Never assume you’ve passed or failed. The interview is still happening until you hang up the call. Stay professional throughout.

You might feel like your technical interview was a disaster, only to find out later you passed. Or you might think everything went great and slip up in the last minute with an off-hand comment. Control your nerves and your words from start to finish. Always leave the best possible impression.

24. Live Coding: Explain Your Thought Process

If you’re doing live coding with someone watching, always:

Read the prompt carefully
Explain your approach as you go
Ask questions if something’s unclear
Make the solution work first and then improve it

Before these sessions, practice with coding katas or timed exercises in the relevant language/framework.

25. Understand the Types of Live Coding

Not all live coding challenges are the same. Ask in advance what type you'll face so you can prepare properly. Common formats include:

Code review of a broken or badly written snippet. Your task is to suggest improvements or spot bugs
Fixing broken code, where you're asked to debug and correct functionality
Katas, which may include algorithmic challenges or small component builds under time pressure

Be aware of restrictions. Some interviews may:

Prohibit ChatGPT or other AIs
Disallow Stack Overflow or Google searches
Only allow access to official documentation

Make sure you clarify the rules and, if needed, train your memory and problem-solving without relying on external tools.

26. Take-Home Assignments: Impress Them

If you’re given a take-home challenge:

Use technologies you’re strongest with
Stick closely to the requirements
Go above and beyond. Add documentation, tests, or even a polished README explaining your architecture and decisions

Keep in mind: even if they say it takes “2 hours,” it usually takes more. Make the extra effort to stand out.

Phase 5: Final Steps

27. Network Smartly

Don't rely only on job portals. Talk to people. Reach out to connections or professionals in your field and ask if they know of any openings. Check company websites directly and when applying, craft thoughtful answers to open-ended questions.

You can use ChatGPT to help you draft responses and improve your applications.

28. Manage Expectations

If you’ve been searching for a long time and keep hearing that your salary expectations are too high or that the market is tough, consider adjusting. Either adapt to the current market or be patient and wait for the right opportunity.

29. Be Patient (Really Patient)

Job hunting, especially when you’ve set ambitious criteria, takes time. If you’re only applying to very specific roles (e.g., fully remote, niche tech stack, high salary), be ready to wait longer.

That said, it’s okay to reevaluate if your conditions are too strict and you realize you don’t have unlimited time, savings, or patience. You can always ease some of your filters.

Also, remember: many recruitment processes are slow, sometimes disorganized, and can take weeks (or months). Take breaks when needed, but trust the process and keep going.

30. Don’t Take It Personally

Rejection is hard, but it doesn’t always mean you’re not good enough. Sometimes:

You’re simply not the profile they were looking for at that moment
Another candidate had just a bit more experience with the exact tool they needed
Or your strengths lie in areas that weren’t evaluated deeply enough

In other cases, you may need to improve in specific areas, and that’s okay too. Use feedback to identify those gaps and work on them. But always keep in mind: one rejection (or ten) does not define your worth or potential.

31. Keep Going. It Gets Easier

The first few interviews can be intimidating. You may feel caught off guard, especially in technical interviews or live coding sessions. But the more interviews you do, the more familiar the patterns become:

Many questions will repeat across companies
You’ll get better at explaining yourself
You’ll become more comfortable under pressure

Treat each interview as practice for the next one. Confidence grows with repetition.

Phase 6: After the Offer

32. Don’t Accept Immediately: Take Your Time

When you receive an offer, don’t feel obligated to say yes on the spot.
It’s perfectly acceptable, and even expected, to ask for a few days to evaluate:

You may receive another offer shortly after
You need to analyze salary, conditions, work model, growth potential, etc.

Avoid making emotional decisions in the heat of the moment. Take your time to compare offers calmly and make a decision that aligns with your long-term goals.

33. Ask for a Pre-Contract (Offer Letter) Before Resigning

Before resigning from your current job, request a pre-contract or offer letter that clearly states:

Salary
Start date
Work model
Benefits
Any special agreements

This provides legal and psychological security, especially if you’re leaving a stable job.

Having something signed avoids last-minute surprises and allows you to transition with confidence.

34. Rest and Prepare Before Starting the New Job

Sometimes after signing the offer, the company may share:

Technologies to review
Tools or frameworks to familiarize yourself with
Onboarding materials

It’s good to prepare, but don’t burn yourself out before even starting.
If possible, negotiate a gap of a few days or weeks between jobs to:

Rest and recharge
Reset your mind

Start your new role with energy and clarity

You’ll perform better if you start fresh, not exhausted.

35. Close the Loop: Inform Other Companies

Once you’ve accepted an offer, inform other companies where you’re still in process that you’re no longer continuing:

Respect the time and effort of recruiters and interviewers. It’s professional and leaves the door open for future opportunities. A short polite message is enough.

Conclusion

Job hunting in tech can be a marathon, not a sprint. By defining your strategy, tracking your progress, preparing thoroughly, and staying proactive, you can significantly improve your chances, even in a tough market. Treat it like a project, stay consistent, and don’t be afraid to ask for help or adjust your approach as you go.

React Best Practices

Mía Salazar — Fri, 08 Aug 2025 09:10:10 +0000

React is powerful, but with great flexibility comes great responsibility. As your application grows, so does the complexity, and that’s when best practices become essential.

In this article, we’ll walk through practical techniques and habits that help you write clean, maintainable, and scalable code.

Keep Components Small and Focused

A component should do one thing, and do it well. Split large components into smaller ones for better reusability and readability.

Use Functional Components and Hooks

Avoid using class components unless you have a specific reason (like legacy codebases). Functional components with hooks are simpler, cleaner, and the current standard in modern React development.

Functional component

function Counter() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(count + 1)}>{count}</button>;
}

Class component

class Counter extends Component {
  constructor(props) {
    super(props);
    this.state = { count: 0 };
  }

  handleClick = () => {
    this.setState((prevState) => ({
      count: prevState.count + 1
    }));
  };

  render() {
    return (
      <button onClick={this.handleClick}>
        {this.state.count}
      </button>
    );
  }
}

export default Counter;

Use a Clear Folder Structure

There’s no single "perfect" folder structure in React. What matters most is that it’s clear, consistent, and aligned with your team’s chosen architecture.

Whether you follow a feature-based, domain-driven, or atomic design approach, pick one that fits your app’s complexity and stick to it. Constantly mixing styles leads to confusion and tech debt.

Example of a feature-based structure:

/src
  /features
    /auth
      AuthForm.tsx
      useAuth.ts
      authService.ts
    /dashboard
      Dashboard.tsx
      useDashboardData.ts

Example of a clean architecture structure:

/src
  /domain
    user.ts
  /application
    useLogin.ts
  /infrastructure
    api.ts
  /presentation
    LoginForm.tsx

Custom Hooks for Reusable Logic

Whenever you find repeated logic across components, consider extracting it into a custom hook. Custom Hooks allow us to separate concerns, create cleaner and more testable components, and have better composition.

Custom hooks are not just about reuse. They're about clarity.
They help enforce clean architecture, reduce repetition, and improve the developer experience.

Use TypeScript (if possible)

Adding TypeScript helps catch bugs early, improves autocomplete, and makes code more robust.

Avoid Prop Drilling with Context

Prop drilling happens when you pass props through multiple layers of components just to get data to a deeply nested child. This makes your code harder to maintain and clutters component APIs.

React Context allows you to share values like state, theme, language, or user data across your entire component tree without passing props manually at every level.

Use Meaningful Names

Good naming improves readability for everyone, including your future self.

Write Tests for Critical Logic

Writing tests for critical logic ensures that key functionality works as expected. Tests catch bugs early, reducing the risk of introducing errors in production and improving overall code stability.

By testing the core behavior of your app, you ensure that essential features are always functional, even as new features are added or the codebase evolves.

Additionally, tests act as living documentation. As your project grows, automated tests help new developers quickly understand how certain features should behave. They ensure that everyone on the team is aligned on expectations, improving collaboration and reducing the chance of miscommunication.

Conclusions

React is just a tool. The way you structure, write, and organize your code makes all the difference in long-term quality.

Adopting these best practices doesn't mean rewriting everything overnight, but gradually improving your codebase will pay off in the long run. Your future self (and your teammates) will thank you.

Clean Architecture in Front-End Development

Mía Salazar — Sun, 01 Jun 2025 08:44:57 +0000

Clean Architecture, introduced by Robert C. Martin, is a software design philosophy that emphasizes the separation of concerns and independence from frameworks or tools.

While it originally gained traction in back-end development, it's increasingly being adapted to front-end projects, especially as these applications grow more complex.

In this article, we'll break down what Clean Architecture means for front-end developers, explain its core layers, and show you how to apply it in real-world UI codebases.

What is Clean Architecture?

Clean Architecture organizes code into layers, forming concentric circles. Each layer depends only on the one inside it. This approach allows you to write code that is independent of frameworks, easy to test, and resilient to change.

The main idea:

Your business logic should not depend on frameworks, databases, or UI code. These are implementation details that can change.

Core Layers

The traditional Clean Architecture model maps layers this way:

Image from Clean Architecture on Frontend, Alex Bespoyasov

Entities (Domain Layer): This layer is Framework-agnostic. It is for core business logic and domain models and it contains rules that rarely change

export type User = {
  email: string;
  password: string;
};

export const isValidEmail = (email: string): boolean => {
  return email.includes('@');
};

Use Cases (Application Layer): The use cases layer orchestrates how data flows between the domain and UI and it encapsulates application-specific rules

export const loginUser = async (
  email: string,
  password: string
): Promise<boolean> => {
  if (!isValidEmail(email)) {
    throw new Error('Invalid email');
  }

  const user: User = { email, password };
  return await loginApi(user);
};

Interface Adapters (Presentation Layer): Includes components, view models, presenters...

export const LoginForm = () => {
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');

  const handleLogin = async () => {
    try {
      const success = await loginUser(email, password);
      alert(success ? 'Logged in!' : 'Login failed');
    } catch (error) {
      alert((error as Error).message);
    }
  };

  return (
    <form onSubmit={(e) => e.preventDefault()}>
      <input
        type="text"
        placeholder="Email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
      />
      <input
        type="password"
        placeholder="Password"
        value={password}
        onChange={(e) => setPassword(e.target.value)}
      />
      <button onClick={handleLogin}>Login</button>
    </form>
  );
};

Frameworks & Drivers (Infrastructure Layer): These should only interact with your app through interfaces or adapters such as axios, fetch, local Storage...

export const loginApi = async (user: User): Promise<boolean> => {
  const response = await fetch('/api/login', {
    method: 'POST',
    body: JSON.stringify(user),
    headers: {
      'Content-Type': 'application/json',
    },
  });

  return response.ok;
};

Benefits

Testability: You can test business logic without a browser or DOM.
Maintainability: You can swap frameworks or APIs with minimal impact.
Scalability: You can grow the codebase easily.

Conclusions

Clean Architecture isn't just a pattern: it's a mindset. In front-end development, it helps keep your application modular, testable, and framework-agnostic, which is especially valuable in a fast-evolving JavaScript ecosystem.

Even if you don’t adopt all its principles at once, gradually introducing its ideas can lead to cleaner, more resilient code.

Interesting links

https://bespoyasov.me/blog/clean-architecture-on-frontend/
https://dev.to/tagada216/clean-architecture-for-the-front-end-3ni4
https://eduardo-ottaviani.medium.com/a-definitive-guide-to-front-end-clean-architecture-3a62418becb4

DEV Community: Mía Salazar

How to Improve Performance in React Applications

Dynamic Imports: Code Splitting for Faster Load Times

List Virtualization: Rendering Only What’s Visible

Memoize Expensive Calculations with useMemo

Preload Critical Resources

Smart Data Fetching with React Query

Optimize Images and Assets

Keep Components Small and Focused

Analyze and Monitor with Performance Tools

Use useEffect and useCallback Wisely

Conclusions

Writing Scalable and Maintainable CSS: BEM, SMACSS and OOCSS

The Problem: Cascading and Specificity

The Solution: Modular CSS Architecture

BEM

SMACSS

OOCSS

Managing Specificity and Avoiding Excessive Inheritance

Conclusion

Multiple header, footer, and h1 Elements: What Is Actually Accessible?

The Core Principle: Semantics Over Superstition

Multiple header Elements

Example

Multiple footer Elements

Example

Multiple h1 Elements

Example

The Real Accessibility Question About Headings

Screen Readers and Navigation

Practical Guidelines

Conclusions

When Does a Component Re-render in React?

What Triggers a Re-render?

Prop Changes

Context Changes

Parent Re-renders

React Reconciliation: How React Decides to Re-render

How to Prevent Unnecessary Re-renders

Use React.memo for Pure Functional Components

Use useCallback and useMemo to Stabilise Functions and Values

Avoid Inline Objects and Arrays in Props

Keep State Local Where Possible

Conclusion

Regular Functions vs Arrow Functions in JavaScript

this Binding

Arguments Object

Constructors

Syntax

Conclusion

Human‑Driven vs AI‑Driven IDEs

What Do We Mean by AI‑Driven?

What Is Human‑Driven Development?

Using Cursor as a Human‑Driven IDE

Configuration Files for a Human‑Driven Cursor Setup

1. Project‑Level Rules (.cursor/rules.md or similar)

2. Editor Settings (settings.json)

3. Repository Documentation (CONTRIBUTING.md)

4. Optional: Prompt Templates

Human‑Driven Prompting Patterns

Why Human‑Driven Matters in Front‑End

Conclusion

Replacing Toasts with Accessible User Feedback Patterns

Why Toasts Are Problematic

Accessible Alternatives to Toast Notifications

Use Persistent Status Message Regions

Use Inline Feedback Near the Trigger

Use a Non-modal, Dismissible Alert Component

Keep Animations Minimal and Optional

Conclusion

Why Skipping Frontend Tests Always Backfires

Why Testing Matters, even on the Frontend

1.Tests catch regressions before your users do

2.They actually save time

3.They make refactoring safe

4.They force better code design

5.You don’t need 100% coverage

Common Objections, and How to Defeat Them

Why End-to-End tests alone aren’t enough

Conclussions

Multiple `header` Elements

Multiple `footer` Elements

Multiple `h1` Elements

`this` Binding

1. Project‑Level Rules (`.cursor/rules.md` or similar)

2. Editor Settings (`settings.json`)

3. Repository Documentation (`CONTRIBUTING.md`)