Forem: Chao Fang

Improving Data Fetching in Next.js: Lessons from Moving Beyond useEffect

Chao Fang — Mon, 16 Mar 2026 16:19:02 +0000

At Subito (Italy's leading classifieds platform), we never paid much attention to how we made API calls in our web frontend microsites, all built on Next.js. We had a simple library based on Axios that handled everything: making requests, modeling data, and managing errors.

On the server side, it was a simple call; on the client side, we used useEffect with state management for data and errors. It worked, until we started asking: is this still the right approach?

The Wake-Up Call: The Cloudflare Incident

The turning point was reading about the Cloudflare outage caused by excessive API calls triggered by useEffect.

It made us reflect on our own stack:

Are we over-fetching?
Are we accidentally triggering duplicate requests?
Could we overload our backend without realizing it?

The Mission

Our primary goal was simple: embrace the standard! We wanted to align perfectly with the official recommendations from React and Next.js.

Since our architecture relies on the Next.js App Router to consume REST APIs, we needed a clean, well-defined data-fetching strategy that clearly distinguishes between React Server Components and Client Components.

The Server Side: embracing the standard

For Server Components, the decision was surprisingly easy: Next.js extends the native fetch API, adding powerful caching and revalidation features out of the box.

What we did: we replaced all Axios calls in our Server Components with the native fetch API extended by Next.js.

This "simple" switch allowed us to remove Axios entirely from our code, a library that, while historic, adds ~13kb to the bundle and has had multiple security advisories over the years (Axios served us well for years and played a huge role in making HTTP requests easier across the JavaScript ecosystem; but it was time to move on).

The Client Side: the great debate (React Query vs. SWR)

While the server side was easy, the client side required a comparison between two libraries: TanStack Query (React Query) and SWR.

The React Query Experiment

We started with React Query: it has gained massive popularity in the React ecosystem, and for good reason!
It's incredibly powerful, a true "server state" manager; we had to try it!

What we found: for our use case it felt like overkill: it requires a QueryClient, a Provider, and careful queryKey management.
The learning curve was steeper than expected, and integrating it into our existing microsites wasn't trivial. The mental shift and boilerplate needed slowed down adoption.
On top of that, we don't really need mutations or cache invalidation on the client since our caching is handled server-side by our backend REST APIs.

The SWR "Toy" that Could

Then we tried SWR (Stale-While-Revalidate) by Vercel.
One of our colleagues jokingly called it a "giocattolino" ("a little toy" in italian) because of how simple it is. But for our use case, it was perfect!

Zero Boilerplate: No mandatory providers. Just a hook: useSWR(key, fetcher)
Low Learning Curve: It felt like a natural extension of the platform
Client-only by design: SWR is focused solely on Client Components, exactly what we needed, since we already solved server-side fetching with native fetch

The Migration

The move from useEffect to SWR felt like cleaning a cluttered room. Here's a real example from our codebase:

Before (useEffect):

const [items, setItems] = useState<Array<AdItem>>([]);
const [isLoading, setIsLoading] = useState(true);

// load the Ads
useEffect(() => {
  getRecommendedItems(vertical)
    .then(setItems)
    .finally(() => setIsLoading(false));
}, [vertical]);

After (SWR):

const { data: items = [], isLoading } = useSWR(
  SWR_KEYS.recommender(vertical),
  fetchRecommendedItems
);

We deleted two useState declarations and replaced a bulky useEffect block with a single, declarative hook.

Centralized Key Management

To avoid "magic strings" and ensure consistent caching, we centralized our SWR keys:

export const SWR_KEYS = {
  recommender: (vertical: string) => ['recommender', 'items', vertical] as const,
  user: (userId: string) => ['user', userId] as const,
};

Simple, type-safe, and predictable.

Testing Without the Headache

Since SWR caches globally, we developed a utility to ensure our unit tests stay isolated:

import { render } from '@testing-library/react';
import { SWRConfig } from 'swr';

export const renderWithSWR = (ui: React.ReactElement) => {
  return render(
    <SWRConfig value={{ dedupingInterval: 0, provider: () => new Map() }}>
      {ui}
    </SWRConfig>
  );
};

// Usage: renderWithSWR(<RecommenderWidget />);

Conclusion

By moving away from manual useEffect fetching and adopting the SWR + Native Fetch combo, we've achieved cleaner code and a much more React-standard way to handle data fetching.

Sometimes the simplest tool is the most effective one. Our use case was clear: few mutations on the client side, no shared cache needed between server and client, and no client-side caching required since we're a pure frontend team calling REST services that handle their own caching.

For this scenario, SWR turned out to be the most immediate, simple, and fitting solution. No over-engineering, just the right tool for the job.

The big takeaway: don't just follow the hype. React Query is an amazing library, if you need complex cache invalidation, optimistic updates, or tight server-client state synchronization, it's probably the right choice. For us, it wasn't. Understand your actual requirements first, then pick the tool that fits, not the other way around.

Evolving Our UI Library: From Custom Components to a Hybrid Radix Approach

Chao Fang — Tue, 07 Oct 2025 13:37:00 +0000

How subito.it, Italy’s leading online classifieds platform, navigated the complexities of UI component libraries, from building everything in-house, to embracing open-source solutions.

Introduction

Building and maintaining an internal UI component library is one of those challenges that seems straightforward until you're deep into it.

At subito, we've experienced this journey firsthand, evolving from building custom components in-house, to experimenting with external Tailwindcss (often simply referred to as Tailwind) based libraries like Spark, and ultimately adopting a hybrid approach centered around Radix.

This is the story of our lessons learned and the pragmatic decisions that shaped our current approach.

Building Our Own: The Custom Component Challenge

Initially, we wanted to build our own components starting from native HTML elements as a foundation.

We had specific design requirements and wanted full control over our component behavior while building on top of standard browser elements like <select>, <input>, and <button>.

However, we quickly discovered that building truly accessible and cross-browser compatible components is far more complex than it appears on the surface.

The main challenges we encountered included:

Browser inconsistencies: What works perfectly in Chrome might behave differently in Safari or Firefox
Accessibility requirements: Implementing proper ARIA attributes, keyboard navigation, and screen reader support requires deep expertise
Performance optimization: Ensuring components perform well across different devices and scenarios
Maintenance overhead: Every custom component becomes a long-term commitment that needs updates, bug fixes, and feature enhancements

We realized that maintaining these internal components was becoming expensive both in terms of development time and ongoing support.

The Tailwind-Based Library Experiment

Recognizing the need for a more sustainable approach, we began looking for external solutions.

Our first attempt involved adopting a Tailwind-based library called Spark, developed by our colleagues at leboncoin.

This seemed like a natural choice given that leboncoin faced similar business requirements and design challenges, plus, the library offered a solid technical foundation and a comprehensive component set.

Integrating this Tailwind-based library into our existing ecosystem proved more challenging than anticipated:

Application-Specific Design: It was designed primarily for complete applications rather than as a foundational library for building other UI libraries, as in our case, where we maintain a UI library used across many microsites.

Tailwind Adoption Challenge: Adopting the Tailwind-based library forced us to integrate Tailwind into our web application, even though we hadn't officially approved it as a development tool.

We were implicitly opening the doors to its usage throughout the codebase.
This generated significant confusion among developers who were left wondering: "Can I now use Tailwind utilities throughout the codebase, or should I continue writing CSS the traditional way?"

Additionally, integrating Tailwind forced us to modify our existing CSS reset and baseline styles to make them coexist with Tailwindcss's own reset styles, adding another layer of complexity to our styling architecture.

The Path to Radix: Finding the Right Foundation

After analyzing the complexities introduced by the Tailwind-based library approach, we decided to step back and reconsider our strategy. This led us to Radix as our core solution.

It proved to be the ideal foundation for several reasons:

Maturity and Reliability: is an incredibly mature library with a strong track record of stability and performance.

Accessibility First: Built with accessibility as a core principle, it handles all the complex ARIA attributes, keyboard navigation, and screen reader support that we struggled with in our custom components.

Community and Contribution: The open-source nature allows us to contribute back to the project and benefit from a large community of developers and maintainers.

AI-Friendly Development: As a widely adopted library, it has excellent AI tooling support. Its popularity means that AI agents and coding assistants have extensive knowledge of Radix patterns, making it incredibly easy to build solutions on top of it with AI assistance.

However, we noticed that Radix and our UX needs are not always perfectly aligned, so we decided to adopt a hybrid strategy.

Our Hybrid Strategy: Radix + Selective Integration

Thanks to Radix modular nature, we are not forced to adopt the entire library but can include only the components we truly need.

This gives us the flexibility to rely on Radix where it provides the most value, while integrating other specialized libraries whenever a specific component offers a better fit for our expectations.

In this way, we embrace a hybrid strategy that combines the robustness of Radix with the freedom to choose the most suitable solution for each case.

For example, since Radix did not provide a dropdown that fully met our needs, we chose to integrate React Select instead of building our own.

Conclusion

Our journey in building a UI library highlighted some key lessons:

creating truly accessible components in-house is costly and time consuming, so leveraging open-source solutions is often the smarter move.
If you’re not ready to fully commit to Tailwind CSS, avoid libraries tightly coupled with it, mixing approaches usually adds complexity instead of value.
Radix proved to be a fantastic foundation: it offers mature, accessible, and behavior-driven components without dictating styling. We read about the Radix maintainers moving on, but we agree with what the author of Shadcn pointed out here.
Mixing and matching the best tools from different open-source libraries, helped us strike a balance between control, quality, and maintainability.

Beyond technology, this journey also sparked a process shift: while our UX/design team used to propose brand-new components, the focus is now on identifying the most suitable ones already available in the open-source ecosystem, contributing when possible, and adapting them to our design system.

This change transforms the relationship between design and engineering:

before, the model was focused on creation,
now, it’s increasingly about curation, research, and adaptation.

At the end of the day, the goal is simple: deliver great user experiences without reinventing every wheel along the way.