DEV Community: Josh Gummersall

Why migrate from Redux to React Query

Josh Gummersall — Sat, 15 Mar 2025 15:17:28 +0000

State management in React applications has evolved significantly over the years. For a long time, Redux was the go-to solution for managing state, offering a predictable, centralized store with actions and reducers to handle updates. However, while Redux provided structure, it also introduced complexity—boilerplate code, verbose action handling, and the need for additional middleware (like Redux Thunk) for async operations. Developers often found themselves writing a lot of extra code just to fetch and manage server data efficiently.

Enter React Query, a modern alternative designed specifically for managing asynchronous state with minimal effort. React Query embraces the fact that server state has unique challenges, such as caching, background synchronization, and automatic refetching. It drastically simplifies the way data is fetched, stored, and updated, removing unnecessary complexity while improving efficiency. Beyond just a better API, React Query enhances developer experience (DX) by reducing boilerplate, improving performance, and making data-fetching logic more intuitive.

Migrating from Redux to React Query isn’t just about swapping libraries—it’s about making state management simpler, more efficient, and more enjoyable.

Less Boilerplate, More Productivity

One of the biggest frustrations with (particularly legacy) Redux is the sheer amount of code required to manage server state. Fetching data typically involves:

Writing an action creator
Dispatching the action
Handling loading and error states in a reducer
Storing the fetched data in the Redux store
Selecting the data with a useSelector hook

With React Query, this entire process is replaced by a single useQuery or useMutation hook. No more writing extra reducers, manually handling cache invalidation, or worrying about keeping data fresh—React Query does it for you.

Built-in Caching & Synchronization

Redux alone doesn’t offer caching out of the box, meaning developers often have to manually manage re-fetching and updating data. With React Query, caching is automatic. It keeps track of fetched data, reuses it across components, and automatically refreshes it in the background when needed. This eliminates stale data problems and reduces unnecessary network requests, improving both performance and user experience.

Optimized Performance

Redux’s approach to state updates can lead to unnecessary re-renders, especially when dealing with deeply nested structures or large datasets. React Query optimizes re-fetching and re-renders by tracking when data changes and only updating components that depend on it. Additionally, it offers features like pagination, infinite scrolling, and optimistic updates out of the box—features that require extra work in Redux.

Better DX (Developer Experience)

React Query significantly improves DX by providing a simpler, more declarative API. Instead of manually dispatching actions, managing reducers, and handling middleware, developers can focus on writing business logic instead of plumbing code. The built-in React Query DevTools are quite nice, too!

By switching to React Query, developers spend less time managing state and more time building features. It’s a smarter, more efficient approach to state management that prioritizes performance, maintainability, and developer happiness.

When to still use Redux

While React Query is excellent for handling server state, Redux still has its place—especially for managing client state that isn’t tied to API data. Things like UI state (modals, sidebars, theme settings), complex local state (such as multi-step forms), and global state that doesn’t need to be fetched from a server are often better suited for Redux or even the Context API. Additionally, if your application already has a well-structured Redux implementation with selectors and memoization, switching to React Query might not always be necessary unless managing server state has become a significant pain point. In some cases, a hybrid approach works best—using React Query for API calls and caching while keeping Redux for UI-related state management. The key is to use the right tool for the job rather than forcing one solution to handle everything.

Conclusion

Migrating from Redux to React Query can significantly improve developer experience, efficiency, and performance by reducing boilerplate, automating caching, and simplifying state management. Instead of manually handling API calls, background synchronization, and cache invalidation, React Query takes care of it for you—allowing developers to focus on building features rather than managing state. While Redux still has its uses for client-side state, React Query is a powerful, modern alternative for handling server state with far less complexity. If you're looking for a faster, cleaner, and more efficient way to manage data in your React app, it’s time to give React Query a try.

TailwindCSS & DaisyUI in the Shadow DOM

Josh Gummersall — Thu, 13 Mar 2025 20:51:24 +0000

When injecting a React component into a third-party website—whether through a Chrome extension or a simple script—one of the biggest challenges is styling. CSS conflicts, unexpected overrides, and global styles can break your UI or make it look completely different from what you intended. The same is true of the host UI! The Shadow DOM provides a powerful solution by encapsulating your component and isolating it from the host page’s styles.

However, using popular styling frameworks like TailwindCSS and DaisyUI inside the Shadow DOM isn’t straightforward. Since styles in the Shadow DOM don’t inherit from the global stylesheet, you need a strategy to ensure your component still benefits from Tailwind’s utility classes and DaisyUI’s prebuilt components.

In this post, I'll walk you through the process of injecting a React component into the Shadow DOM while ensuring TailwindCSS and DaisyUI styles are properly applied. By the end, you'll have a working setup that you can use for script injection, Chrome extensions, or any scenario where you need a self-contained UI inside a third-party site.

What is the Shadow DOM?

The Shadow DOM is a web standard that allows developers to encapsulate HTML, CSS, and JavaScript within a self-contained scope, preventing styles and scripts from leaking in or out. This is particularly useful when injecting UI components into third-party websites, as it prevents conflicts with the site's existing styles and ensures your component looks and behaves consistently. Unlike the regular DOM, where styles can cascade globally, elements inside a Shadow DOM tree have their own isolated styles and scripts, making it ideal for building embeddable widgets, Chrome extensions, and injected scripts that need to maintain their design integrity.

Setting up React Component Injection

To inject a React component into a third-party website, you first need to create a container element and attach it to the page. However, instead of simply appending a div to document.body, we’ll use the Shadow DOM to encapsulate our component and prevent style conflicts.

const container = document.createElement("div");
document.body.appendChild(container);

const shadow = container.attachShadow({ mode: "open" });

This isolates everything we place inside shadowRoot from the rest of the page’s styles and scripts.

Now, let’s render a simple React component inside the Shadow DOM using createRoot from React 18:

createRoot(shadow).render(<Component />);

What about Tailwind CSS and Daisy UI?

We'll use Vite as a bundling solution as both Tailwind CSS and Daisy UI require importing CSS (the Get started with Tailwind CSS guide provides details on using Vite). The vite.config.ts file looks like:

import { defineConfig } from "vite";

import react from "@vitejs/plugin-react";
import tailwindcss from "@tailwindcss/vite";

export default defineConfig({
  plugins: [react(), tailwindcss()],
  build: {
    rollupOptions: {
      // Note: useful to produce a single JS file for a <script> tag
      output: {
        entryFileNames: "index.js",
        chunkFileNames: "[name].js",
        assetFileNames: "[name].[ext]",
      },
    },
  },
});

Next, using TailwindCSS 4 and DaisyUI 5, configuration is handled entirely in a single CSS file. TailwindCSS version 4 includes :host in its CSS rules intended to apply to the entire DOM. Lucky for us, :host is a CSS pseudo-selector targeting the Shadow DOM host!

For DaisyUI, we just need to include the root option as it defaults to :root if unspecified. Our CSS file looks like:

@import "tailwindcss";

@plugin "daisyui" {
  root: ":host";
}

Finally, our React Component must import this CSS file in a way that includes it in our bundled Javascript (rather than including it as a <link> tag). This ensures the TailwindCSS and DaisyUI CSS rules only apply inside the Shadow DOM. It's also a better end-user experience for the person adding just one <script> tag to their HTML.

Luckily, Vite provides a ?inline modifier for CSS imports that produces a style string:

import style from './index.css?inline';

export default function Component() {
  return (
    <>
      <style>{style}</style>
      <button className="btn btn-primary">Hello world</button>
    </>
  );
}

Wrapping Up

Notice the DOM structure in the developer tools window, and notice the host page remains un-styled

There you have it! With this setup, you have React, TailwindCSS, and DaisyUI running inside an isolated Shadow DOM. Styles are correctly applied inside the Shadow DOM, while the regular host page UI remains completely unchanged.

For more details and a jumping off point, check out the Github repository. If you need any help with React or Javascript development, please get in touch!