DEV Community: jmoreno

Sharing React Query State Across Astro Islands

jmoreno — Sat, 01 Mar 2025 13:08:59 +0000

Thinking about Astro Islands

When working with Astro's island architecture, each React component is isolated from others. This creates a challenge when you need to share state between components, especially when:

Multiple components need access to the same data
Components need to stay in sync with each other
You want to avoid redundant API calls
You need to maintain a consistent UI state across the page

Traditional React patterns like lifting state up or using a global context provider don't work well in this environment because each island has its own React tree.

The main insight here is around how JavaScript modules are executed in the browser. When Astro builds your site:

Each island becomes its own bundle with its dependencies
If multiple islands import the same module (let's call it shared.js), that module will be:
- Included in the dependency graph for each island
- But executed only once when the first island loads it
- Subsequent islands will use the already initialized instance

This execution order guarantee is the key that makes sharing state possible. If we have:

Island A → imports → shared.js (with QueryClient)
Island B → imports → shared.js (with QueryClient)

When the browser loads these islands, shared.js will be executed before either island's code runs. This means the singleton QueryClient will be initialized once and then available for all islands to access.

Why React Query is a Perfect Fit

Taking step back let's see why React Query is a great choice for this problem.

React Query offers several advantages that make it ideal:

Cache-based architecture : React Query's core is a cache that can be shared
Automatic deduplication : Identical queries automatically share data
Stale-while-revalidate pattern : Components always show something while refreshing
Configurable staleness : Control when data needs refreshing
Built-in prefetching : Load data before it's needed

Implementation

Let's implement a complete example with a todo application that has multiple components needing access to the same data:

import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
import type { ComponentType, ReactNode } from "react";

// Create a singleton QueryClient that will be shared across all components
const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      staleTime: 1000 * 60 * 5, // 5 minutes
      refetchOnWindowFocus: false,
    },
  },
});

/**
 * Higher-order component that wraps a component with a QueryClientProvider
 * using a shared QueryClient instance.
 *
 * This is useful for Astro islands where you need isolated contexts
 * but want to share the same query client.
 *
 * @param Component - The component to wrap
 * @returns A new component wrapped with QueryClientProvider
 */
export function withQuery<P extends object>(
  Component: ComponentType<P>,
): ComponentType<P> {
  // The display name for the wrapped component
  const displayName = Component.displayName || Component.name || "Component";

  // The wrapped component
  const WithQuery = (props: P) => {
    const { children, ...componentProps } = props as P & {
      children?: ReactNode;
    };

    return (
      <QueryClientProvider client={queryClient}>
        <Component {...(componentProps as P)}>{children}</Component>
      </QueryClientProvider>
    );
  };

  // Set the display name for better debugging
  WithQuery.displayName = `withQuery(${displayName})`;

  return WithQuery;
}

// Export the queryClient in case it needs to be accessed directly
export { queryClient };

Using the Pattern in Practice

Now let's use this withQuery hook to share fetched API data between our islands. In our first TodoList file we want to display our Todo items.

// src/lib/todo-api.ts
export interface Todo {
  id: number;
  title: string;
  completed: boolean;
}

// src/components/TodoList.tsx
import { useQuery } from "@tanstack/react-query";
import { fetchTodos, Todo } from "../lib/todo-api";
import { withQuery } from "../lib/with-query";

function TodoList() {
  const { data, isLoading, error } = useQuery({
    queryKey: ["todos"],
    queryFn: fetchTodos,
  });

  if (isLoading) return <div>Loading todos...</div>;
  if (error) return <div>Error loading todos</div>;

  return (
    <ul className="todo-list">
      {data?.map((todo) => (
        <li key={todo.id} className={todo.completed ? "completed" : ""}>
          {todo.title}
        </li>
      ))}
    </ul>
  );
}

export default withQuery(TodoList);

In our TodoStats we're using that same query to derive some quick stats.

// src/components/TodoStats.tsx
import { useQuery } from "@tanstack/react-query";
import { fetchTodos } from "../lib/todo-api";
import { withQuery } from "../lib/with-query";

function TodoStats() {
  const { data, isLoading } = useQuery({
    queryKey: ["todos"],
    queryFn: fetchTodos,
  });

  if (isLoading) return <div>Loading stats...</div>;

  const totalTodos = data?.length || 0;
  const completedTodos = data?.filter((todo) => todo.completed).length || 0;
  const percentComplete =
    totalTodos > 0 ? Math.round((completedTodos / totalTodos) * 100) : 0;

  return (
    <div className="todo-stats">
      <h3>Todo Statistics</h3>
      <p>Total todos: {totalTodos}</p>
      <p>Completed: {completedTodos}</p>
      <p>Completion rate: {percentComplete}%</p>
    </div>
  );
}

export default withQuery(TodoStats);

Finally we need a form to actually create our Todos. Here we're invalidating the singleton queryClient cache when we finish our mutation.

Because our components share this single queryClient instance this will cause them to update with new data.

// src/components/TodoForm.tsx
import { useMutation } from "@tanstack/react-query";
import { useState } from "react";
import { updateTodo } from "../lib/todo-api";
import { withQuery } from "../lib/with-query";
import { queryClient } from "../lib/query-client";

function TodoForm() {
  const [todoId, setTodoId] = useState("");
  const [title, setTitle] = useState("");

  const mutation = useMutation({
    mutationFn: updateTodo,
    onSuccess: () => {
      // Invalidate the todos query to trigger a refetch
      queryClient.invalidateQueries({ queryKey: ["todos"] });
      // Reset form
      setTodoId("");
      setTitle("");
    },
  });

  const handleSubmit = (e: React.FormEvent) => {
    e.preventDefault();
    if (!todoId || !title) return;

    mutation.mutate({
      id: parseInt(todoId),
      title,
      completed: false,
    });
  };

  return (
    <form onSubmit={handleSubmit} className="todo-form">
      <h3>Update Todo</h3>
      <div>
        <label htmlFor="todoId">Todo ID:</label>
        <input
          id="todoId"
          type="number"
          value={todoId}
          onChange={(e) => setTodoId(e.target.value)}
          required
        />
      </div>
      <div>
        <label htmlFor="title">New Title:</label>
        <input
          id="title"
          type="text"
          value={title}
          onChange={(e) => setTitle(e.target.value)}
          required
        />
      </div>
      <button type="submit" disabled={mutation.isPending}>
        {mutation.isPending ? "Updating..." : "Update Todo"}
      </button>
      {mutation.isError && (
        <p className="error">Error: {mutation.error.message}</p>
      )}
      {mutation.isSuccess && (
        <p className="success">Todo updated successfully!</p>
      )}
    </form>
  );
}

export default withQuery(TodoForm);

Using in Astro Templates

Now we can use these components in our Astro templates. Note the client:load this tells Astro that it should ship the javascript bundle to the client.

---
// src/pages/todos.astro
import TodoList from "../components/TodoList";
import TodoStats from "../components/TodoStats";
import TodoForm from "../components/TodoForm";
---

<html lang="en">
  <head>
    <title>Todo Application</title>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <link rel="stylesheet" href="/styles/global.css" />
  </head>
  <body>
    <main>
      <h1>Todo Application</h1>

      <div class="todo-container">
        <div class="todo-section">
          <h2>My Todos</h2>
          <TodoList client:load />
        </div>

        <div class="stats-section">
          <TodoStats client:load />
        </div>
      </div>

      <div class="form-section">
        <TodoForm client:load />
      </div>
    </main>
  </body>
</html>

Performance Considerations

This pattern offers several performance benefits:

Reduced API calls : Multiple components share the same data
Smaller bundle sizes : No need for a global state management library
Efficient updates : Only affected components re-render
Controlled refetching : Configure when data should be considered stale
Background updates : Users see fresh data without interruption

Beyond Islands: Towards SPA-like Experiences

This pattern brings us closer to building SPA-like experiences with Astro while maintaining its core performance benefits. By sharing state between islands, we can create applications that feel cohesive and responsive like a traditional SPA, but with the performance advantages of Astro's partial hydration model.

For many applications, this Astro pattern provides the best of both worlds:

Performance first : Ship minimal JavaScript by default
Progressive enhancement : Add interactivity only where needed
Shared state : Maintain a cohesive user experience across islands
Simplified mental model : No need to manage server/client boundaries as explicitly as in Next.js

As this pattern demonstrates, Astro isn't just for static sites with sprinkles of interactivity—it's a viable alternative to frameworks like Next.js for building rich, data-driven applications that prioritize performance without sacrificing user experience.

Conclusion

Sharing state between Astro islands doesn't have to be complicated. By leveraging React Query's powerful caching system and a singleton QueryClient, we can achieve seamless state sharing without sacrificing the performance benefits of Astro's island architecture.

This pattern is:

Simple : Just a small HOC and a shared client instance
Flexible : Works with any React Query features
Efficient : Minimizes API calls and renders
Maintainable : Follows established React patterns

Next time you're building an Astro site with multiple interactive components that need to share data, give this pattern a try. It provides a clean solution to a common problem while maintaining the performance benefits that made you choose Astro in the first place.

A Letter to my Junior Self: Imposter Syndrome

jmoreno — Sun, 13 Feb 2022 09:55:45 +0000

Imposter syndrome is probably one of the most common issues that new programmers face. The tech industry can seem incredibly daunting from the outside looking in, "make sure you practice leetcode, oh and put together a portfolio, and why are you learning that framework that's old news, all the cool kids have moved on to this new framework."

Then once you start the job there's a feeling of needing to keep up, to be at the same level as coworkers with much more experience than you, after all if you can't keep up then why did they hire you? Man they're probably even thinking of firing you right now aren't they?

Of course this is bullshit. The mind likes to exaggerate, in truth you're probably doing fine and a part of you knows this, but the mind is tricky and well it's not exactly wrong.

The truth is that if you're new you probably can't keep up with your more experienced coworkers, but the good news is that no one really expects you to in the first place.

So then how do we deal with imposter syndrome? The following is the process that I followed (I am not a medical professional and if you're truly struggling please reach out to a professional).

This whole letter is based on the idea that imposter syndrome is a learned reaction to a given situation, it is NOT a moral defect, or flaw in your person, it is simply how we learned to cope with unfamiliar situations. So keep that in mind as you read this letter.

First step is to simply observe, whenever you're going to be in a situation that has caused your imposter syndrome to flare up before, pay attention to your body, watch how it tenses up, watch how your breath changes, and more importantly watch the thoughts that are popping up in your head. What is the mind presenting you with at this moment? Why?

This is going to be hard at first, after all you're looking directly at the things that we want to avoid but it is important because we want to be able to see what exactly it is we're afraid of.

Then, explore what the fear is really about. This might sound silly but it's important to know what exactly it is we're afraid of, is it getting fired? Is it the reputational hit? Is it a deeper fear that maybe you chose the wrong career? Or that you're not smart enough to do this? Let's tackle a few of the common fears.

"I'm scared I might not know how to do this." Why?

Is it because you're scared you'll lose your job? Highly unlikely. If you're just starting out you were most likely hired as a junior. Your company, your coworkers, and frankly most people in tech do not expect that you know everything, we WANT to help you learn, we want to see you succeed. Why do you believe that not knowing something is a basis for being fired?

Is it because you don't want to look bad in front of your peers? Once again try to explore where you picked up the belief that not knowing how to do something is a bad thing or would make you look bad somehow.

We want to see you succeed, we want to help, and while most people don't speak openly about it I can promise you that a majority of people have felt this way.

Keep in mind that developers are fundamentally a curious group of people. We tend to pride ourselves in learning new things, so if someone doesn't know everything but is trying to learn to do things they'll usually be looked on favorably. (And if your coworkers are being elitist assholes about it, fuck them, find the helpers).

Are you comparing yourself to some mythical genius programmer who knows everything? These types of programmers may exist but in the seven years I've been in the tech industry I've never come across one, even if it looks that way sometimes from the outside. More likely they just have more experience than you and have seen more shit. This is a good thing, it means you have people to learn from. If you didn't how would anyone ever progress?

Is it because as a kid you were scolded for not knowing something? This one cuts a little deeper but was my personal reason for imposter syndrome, as a kid I was rewarded when I knew things and punished when I didn't. This is where I internalized the idea that not knowing something was a bad thing. This created a very toxic and subconscious behavior in me where I would hide away until I felt confident in doing things, after all I didn't want my parents to be upset with me. Well guess what, we're not kids anymore, no one is going to scold us, and even if someone does, we'll be fine. It might hurt, but we'll be fine. This doesn't mean that our fear is invalid, it just means that it is no longer a useful pattern of behavior.

Now, once you know what your fear is really about you have to take probably the hardest step: Acceptance.

You have to accept that this fear is there, having imposter syndrome is simply something that happens to you right now, and that's okay. It shows that you care about your work, it shows that you're conscientious, these are admirable qualities.

The fear feels unpleasant I know, and we instinctively want to get rid of it. But as you may have noticed pushing it away doesn't work and can even make it worse because now you have the fear and the shame towards having felt that fear. (After all no one else feels it right? What's wrong with us?)

So instead, just let it be there. It has valid reasons for being there. In my case as a kid I was 100% going to get in trouble for low grades this was a fact of life, so now as an adult my mind was trying to avoid that and it just hadn't realized that we were no longer in that situation. It just wanted to help. So accept it, thank the mind for looking out for you and then teach it how to look out for you in helpful ways.

This is where we get to retraining our automatic reactions, again imposter syndrome is a learned reaction to a given situation, it is NOT a moral defect, or flaw in your person, it is simply how we learned to cope with unfamiliar situations.

So how do we retrain ourselves? In my experience the best way is repetition, when imposter syndrome flares up we follow the process: observe our mind, explore the fear, accept that the fear is there, know that the mind is trying to help, and then help it help us.

If it starts going on about everyone else being smarter than you explain to it that this is simply not true, and even if it is true you're here to learn and grow not to compare yourself with others, so who cares?

If it starts going on about getting yelled at as a kid for bad grades, comfort it, tell it that it's okay to be scared, and that you know it wants to help but you're no longer there, and if your coworker yells at you they're the asshole.

Over time (weeks, months, years) this replaces the automatic reaction of fear and anxiety with an automatic reaction of exploration and acceptance, which means that we'll feel imposter syndrome less and less intensely, and because we're presenting the mind with alternatives it will eventually start to present them back to us and on days where we're feeling low, the mind will remind us that this is okay.

This is the process I personally followed to get rid of imposter syndrome, fear of public speaking, fear of looking like an idiot in front of my coworkers, and frankly just fear in general. It is hard but man is it worth it. Good luck, you got this.

For more explorations of this I suggest the following reading list.

Reading List

The Inner Game of Tennis
Zen Mind Beginner's Mind
Atomic Habits
How to Fail at Everything and Still win Big

Senior / Intermediate React Interview Questions

jmoreno — Thu, 10 Feb 2022 16:36:47 +0000

Recently I had to come up with a list of interview questions to ask potential senior / intermediate candidates.

I tried to come up with questions that showed understanding of React issues and use cases rather than surface level memorization.

What problem does React solve?
React is a way to develop UIs in a predictable, declarative way. Rather than wiring up changes to the DOM yourself you simply describe what the UI should look like for a given state and React handles the DOM patching.

What is the role of the virtual dom in React, what problems does it attempt to solve?
React makes the assumption that DOM manipulation is expensive (kudos if they explain why) so it holds a copy of the DOM in an in memory data structure known as the virtual dom. Differences in the component tree between renders are computed against this virtual representation and React tries to apply the minimal number of changes to the DOM.

Speak briefly on the component lifecycle
At the very least should mention mounting, rendering, unmounting.
Extra points if they can talk about the class based lifecycle and why it is no longer as relevant.

In the context of React what does one way data flow refer to and what are some of the advantages / disadvantages of this?
One way data flow describes how information moves through a react application, information always moves down the tree from parent to child. One of the advantages of this is that it makes application state easier to reason about since we know information will either be local or coming from a parent node.

One of the disadvantages is that it makes communication between sibling components impossible without an intermediary (parent / state store / context)

Also makes prop drilling a thing, which isn't necessarily bad but can be messy.

Elaborate on a few common approaches to sharing state between sibling components
Lifting state up, using an outside store, react context.

How would you share state between components at different levels of the component tree?
Lifting state up, using an outside store, prop drilling is also an option but has the disadvantage of introducing noise into component APIs and potentially causing extra renders which can be an issue in performance critical applications.

React Context is also an option but setting the value of a context provider will cause the entire subtree to re-render so it is a tool which should be used for values which do not change as often and not for general state management (state usually changes frequently)

What is a pure component and why would you want to use one?
Pure components are components with no side-effects, this allows us to use shouldComponentUpdate or React.memo to compare props and prevent re-renders in performance critical parts of the application.
Pure components are not without cost, in some situations re-rendering the component without comparing props is faster than doing the comparison, this is especially true for smaller components.

In the context of a react component what is a key?
Keys are required when rendering a list of items.
Keys help react keep track of components between renders.
extra points: You can force react to unmount/mount a component by changing the component's key.

What problems do refs solve and when would you want to use them?
The value of the reference is persisted (stays the same) between component re-renders;
Updating a reference doesn't trigger a component re-render.
Refs provide a way to access DOM nodes or React elements created in the render method.
You would want to use refs for:
- Managing focus, text selection, or media playback.
- Triggering imperative animations.
- Integrating with third-party DOM libraries.

What is memoization and why would you want to use it?
Memoization is a programming technique that accelerates performance by caching the return values of expensive function calls. A “memoized” function will immediately output a pre-computed value if it’s given inputs that it’s seen before.
You would want to use it to store expensive components / values and make sure they are only computed when necessary. Memoizing trades memory for computation time.

Describe what the role of the useEffect hook is, how you would use it, and some common pitfalls.
useEffect is used to encapsulate "side-effects" such as data fetching, logging, handling route changes, etc..
useEffect takes in a dependency array and will re-run the body of the hook when those dependencies change.
You can provide a return function that will be called when when the dependencies change before the next body is called.
Gotchas around useEffect usually come from not passing in the required dependencies leading to stale values or from dependencies changing on every render.

How does the useEffect hook compare dependencies across renders and what does this mean for complex types?
useEffect uses reference / shallow equality for complex data types, this leads to a common "bug" in useEffect where the dependencies are complex types and are redeclared on each render, this can cause the effect to fire more times than the developer intends.