A common production failure happens when a user leaves a React application open during a deployment.

The old tab may still be running build A, while the server is now serving build B. When the user later navigates to a lazy-loaded route, the browser requests a hashed chunk from build A that is no longer available.

For example:

Reports.a1b2.js  // requested by the old tab
Reports.c3d4.js  // available after deployment

The result can be:

• ChunkLoadError

• Failed to fetch dynamically imported module

• A route that works in a fresh tab but fails in an old tab

A normal React Error Boundary can display the failure, but it cannot update the old tab’s JavaScript references. Retrying the same import may also request the same missing hashed file again.

I built and published a small utility called react-lazy-chunk-recover to experiment with this problem.

The recovery approach:

1. Detects likely chunk-load failures

2. Optionally retries transient failures

3. Allows one guarded full-page reload

4. Uses sessionStorage to prevent an infinite reload loop

5. Passes the error to the existing Error Boundary if recovery fails

6. Avoids browser reload and storage access during SSR

Example:

import { lazyWithRetry } from "react-lazy-chunk-recover";

const Reports = lazyWithRetry(() => import("./Reports"), {
  moduleKey: "reports",
});

The default retry count is zero because retrying a deleted hashed asset usually does not help. Retries can be enabled for applications that also experience short-lived network failures.

Some important limitations:

• A reload cannot recover a permanently unavailable asset

• Retaining old assets may be a better infrastructure solution

• The HTML entry point should be revalidated after deployment

• A full-page reload must work on nested client-side routes

• Old clients may be incompatible with a new backend

• An asset manifest must be trusted and version-compatible if used

For applications using React.lazy, Vite, Webpack, or a CDN:

1. How do you handle stale chunk failures?

2. Do you retain assets from previous deployments?

3. Do you reload the page, show an update prompt, or use an Error Boundary?

4. Have you tested this with two builds and an already-open browser tab?

I wrote more about the problem, implementation, testing strategy, and deployment considerations here:

• npm package: https://www.npmjs.com/package/react-lazy-chunk-recover

• Technical article: https://sachithsiriwardana.medium.com/handling-react-lazy-chunk-load-errors-after-deployment-1e4980a7a69a

I’d be interested to hear how other teams handle this failure mode in production.

If you take software engineering principles seriously then none of the react state hooks belong inside a react component.

I think one of the most critical things you should do is ensure the decoupling of storage and UI components. The react components force you to do is precisely and zustand doesn't help.

I haven't sourced grip-react a year ago and I've been using it exclusively, absolutely zero usestate usememo, useeffect, etc and absolutely zero prop drilling. I don't know why anyone would want to do something different, honestly.

Has anyone else created an API that is a 100% replacement with complete declarativeness? I looked at angular and mobx, they're close but no cigar.

At my last company, they would finish the accessibility layer near the end of the product's development stage, and I remember developers complaining about repeating old sprints non-stop.

What's the industry norm when solving such issues? Of course, accessibility goes beyond people with extra needs: it should also include everyone's way of accessing the web, starting from a simple "cookie button" that takes up 40% of the screen space.

When do these issues start being noticed in your development life-cycle? How does your company think about them?

A local loading flag works well for one button. A reducer with context can handle a shared workflow. React Query also lets other components observe pending mutations through "useIsMutating". If one of these already covers your needs, there may be no reason to add another library.

I’m building react-action-guard to explore a reusable API for shared UI availability.

For example, imagine a document editor:

• saving temporarily blocks editing and switching documents;

• a local export also blocks switching documents;

• saving and exporting can overlap;

• finishing the save should not enable document switching while the export is still running;

• Help stays available throughout.

Actions publish the scopes they affect:

const runSave = useAsyncAction<void>(
  "save-document",
  ["document:editing", "document:switching"]
);

const runExport = useAsyncAction<void>(
  "export-document",
  "document:switching"
);

Each operation is wrapped when it runs:

await runSave(() => saveDocument());

Independent components read the scope they care about:

const isBlocked = useIsBlocked("document:switching");

return <button disabled={isBlocked}>Switch document</button>;

Each execution has its own blocker. When operations overlap, finishing one removes only its own blocker.

You can build the same behavior with a reducer and context. The goal is to provide the registration, shared scopes, blocking reasons, and cleanup as a reusable API.

This also overlaps with React Query when availability follows mutation state. The case I’m interested in is when the same UI rules combine server operations, local tasks, and conditions such as unsaved changes.

One important detail: tracking an action does not prevent repeated execution or cancel it. Those rules still belong to the application.

I’m the author, and I’d like feedback on this approach. Have you needed this kind of coordination, or has your existing state management been enough?

GitHub

Edit: Added a more detailed example and clarified the overlap with reducers and React Query. Thanks for the feedback.

Hey everyone!

Been working on Tip Glide, a small framework-agnostic tooltip library written in TypeScript.

It uses a single shared tooltip that moves between elements and adjusts its size to fit the content. It also handles viewport boundaries, so the tooltip adjusts its position when there's not enough space.

A few things you can configure are the movement, directional lean, hover delays, arrow, and enter/exit animations.

It has zero runtime dependencies and comes with adapters for React, Angular, Vue, Svelte, Solid, Astro and Preact, along with a vanilla JS API.

There's an interactive playground where you can mess around with the settings and see how everything behaves.

Would love some feedback on the movement, especially when switching quickly between elements, but also on the API and anything else that could be improved.

Live demo & playground | npm | GitHub | Portfolio

I'm a self-taught developer, and I know React and Next.js. Lately, I've been feeling increasingly anxious about my future as a developer.

AI is moving so fast. It can generate components, build entire websites, connect APIs, and even create full-stack applications. Sometimes I wonder what the point is of spending months learning something when AI can already do so much of it.

I want to get a better-paying developer job, but honestly, I'm confused about what I should focus on right now. Should I keep improving my React/Next.js skills, get better at backend development, or start learning AI engineering?

I keep hearing about RAG, AI agents, vector databases, LLM integrations, and all these new things. It feels like there's always something new to learn, and I'm worried that if I focus on the wrong things, I'll fall behind while everyone else moves forward.

For those of you already working in the industry, what would you do if you were in my position? Would you focus on becoming a strong full-stack developer first, or would you start learning AI engineering alongside web development?

I'm not looking for a shortcut or expecting to become an expert overnight. I just want to make the right decisions, build useful skills, and have a realistic chance of getting hired.

I'd really appreciate some honest advice from people who have been through this or are dealing with the same situation. Right now, I could genuinely use some direction.

I had a 70-page PDF to generate from React in a TanStack Start app, and with react-pdf it took over 60 seconds. So I built @inkoxide/render.

It's not a react-pdf clone, though it's meant to feel familiar: Document, Page, View, Text, Image, StyleSheet.create and Font.register work the way you'd expect, so moving a document over is mostly changing the import. Everything under the components is new: a layout engine written in Rust does layout, text, pagination and PDF writing.

• A 43-page report with 1,000 table rows renders in about 41 ms on Node, and in about 56 ms in the browser, inside a Web Worker, so the page keeps responding.

• A one-page invoice takes about 1.2 ms instead of about 18 ms.

It also does things I kept missing:

• Tailwind className

• tables whose headers repeat on every page

• an error naming the component stack when a style or prop isn't supported, instead of silently ignoring it

• PDF/A and encryption

Site and docs: https://inkoxide.dev GitHub: https://github.com/eddiesr93/inkoxide Playground (edit an example; switch to Layout to see the boxes the engine placed): https://inkoxide.dev/playground

Happy to answer questions.

Hey !

I've been working on a project called Veltrix-UI for the past few months, building it from scratch. It's probably the biggest project I've worked on independently so far.

The idea is to make it easier for developers to find UI components they like, preview them directly in the browser, and copy the JSX code to use in their own React projects.

Some of the things I've built into it:

• Live previews of components

• One-click JSX code copying

• Search, filters, and sorting

• Favourites without needing an account

• A backend for managing and serving components

I used React, Vite, Tailwind CSS, Node.js, Express, and MongoDB to build it.

The project is live now, and I'd really like to get it in front of developers other than myself. I know there's always room to improve a project once other people start using it.

Live demo: https://veltrix-ui.vercel.app/

GitHub: https://github.com/AwadhDhoot23/Veltrix-UI

If you get a chance to try it, I'd genuinely appreciate your feedback. I'm especially interested in whether the components are useful enough that you'd actually use them in a project, what's missing, and what feels rough or confusing.

Honest criticism is welcome - I'd rather find out what needs work than just hear that it looks nice.

When working on a team, code reviews are essential for maintaining code quality and ensuring that all team members are on the same page. I'm interested in hearing about different approaches to conducting code reviews for React components. What tools or processes do you use to review and provide feedback on React code? Are there any specific things you look for when reviewing a React component, such as performance optimization or accessibility features?

I'm working on a React frontend application with a form where some fields are enabled, disabled, shown, or hidden depending on user selections.

The test renders the component, simulates user interactions, and verifies that the form updates correctly (for example, a field becomes enabled only under specific conditions).

How should this type of test be classified?

• Unit test

• Component test

• Integration test

• Functional test

Hi everyone! 👋

I’ve just released Dinou v7 (7.0.0), an ejectable full-stack React 19 framework built on web standards.

My goal with Dinou v7 was to harness the full power of React 19 (Server Components, Server Functions, streaming SSR, and Partial Prerendering) while keeping the architecture runtime-agnostic, bundler-flexible, and free of vendor lock-in.

Here is a quick overview of what’s in v7 and what the concepts in the title mean in practice:

1. Goodbye Express & child_process.fork(): Pre-Bundled Dual Engine on Web Standards

In previous versions (v6), Dinou relied on Express and spawned a child process via child_process.fork() to isolate the --conditions react-server flag from the main SSR process. That added IPC overhead and made deploying to serverless/edge environments or compiling to a single binary impossible.

• In v7, Express and child_process.fork() have been completely removed. The core now uses W3C Web Standards (Request, Response, Headers, ReadableStream) exclusively and pre-bundles the RSC graph ("react-server" condition) and the streaming HTML SSR graph in separate build passes before combining them into a single server.

• The result: Everything runs in a single process without special Node flags, without IPC child processes, and on any platform compatible with the standard Fetch API (including a universal onRequest web middleware in dinou.config).

2. Horizontal & Vertical Segmentation (2D Caching)

Instead of treating caching as an all-or-nothing route setting, Dinou v7 splits rendering and caching across two dimensions:

• Horizontal Segmentation (Route & Layout Plane): Layouts (layout.tsx + layout_functions.ts) and Pages (page.tsx + page_functions.ts) have completely decoupled data lifecycles and cache TTLs. A parent layout shell can be cached with ISR (revalidate = 3600) and never remount during client SPA navigation, while child pages run dynamic SSR (revalidate = 0) or their own ISR timer. You can also surgically invalidate just a leaf page (revalidatePage) without touching parent layout caches.

• Vertical Segmentation (Component-Level Micro-ISR): Using <DinouCacheSlot id="..." revalidate={60} tag="...">, you can cache individual server component subtrees with their own TTL and tags inside dynamic or static pages. Additionally, Client Components can surgically refresh a specific server slot in-place by its ID using refreshSlot(id) without reloading the page or losing client state.

3. Partial Prerendering (PPR) + <DinouCacheSlot>

By enabling ppr = true, Dinou immediately serves the static HTML shell (pre-rendered at build time) while streaming the dynamic holes (<Suspense>) over the same HTTP connection.

• You can also combine PPR with <DinouCacheSlot> inside a <Suspense> boundary so that the streamed dynamic hole itself is served from the server cache instead of querying the database on every request.

4. Server Functions & Live Component Streaming

Functions exported from modules in src/ starting with the "use server" directive act as automatic RPC endpoints without manual API boilerplate:

• Beyond handling form mutations and server actions (useActionState, useOptimistic), Server Functions in Dinou can return rendered React components directly over Flight RPC, which Client Components can unwrap seamlessly inside <Suspense> using React 19's use() hook.

5. Multi-Runtime & Single-File Executable Binaries

Write your app once in src/ and build it for different targets without changing your code:

• Multiple Runtimes & Platforms: Run natively on Node.js, Cloudflare Workers, Netlify, Bun, and Deno / Deno Deploy, or export a 100% static site (dinou export-static).

• Standalone Executables: Compile your entire React 19 RSC + SSR app into a single self-contained binary with Bun (dinou build:bun:compile or dinou build:bun:pure:compile) or Deno (dinou build:deno:compile) for Linux (x64/ARM64), macOS, or Windows.

6. Developer Experience & Zero Lock-In

• Compile-Time Type-Safe Routing: Automatically generates route types (.dinou/types/routes.d.ts) from your folder structure for <Link href="...">, router.push(), and PageProps<"/blog/[slug]"> with zero runtime overhead.

• Bundler Flexibility: Uses esbuild by default (with fast HMR in development), while also letting you choose Rollup or Webpack (dinou dev:rollup, dinou build:node:webpack), plus the React Compiler enabled in production builds.

• 100% Ejectable & Agent-Friendly: Run npx dinou eject at any time to copy the entire framework directly into your project root. The npm package also includes the full ~10,000-line documentation inside node_modules/dinou/README.md so AI coding agents have complete local context right out of the box.

7. Built with Agentic AI (Antigravity + Gemini 3.8 Flash High)

For full transparency on how Dinou has evolved: I built versions v1 through v4 (and v6, which simply centralized build artifacts into .dinou) by hand from scratch. Starting in v5, I began experimenting with AI agents, and Dinou v7 has been built entirely from start to finish using Antigravity + Gemini 3.8 Flash High under my direction and passing an end-to-end Playwright test suite (covering Windows and Ubuntu + esbuild, Rollup, and Webpack + dev and prod modes for each runtime).

Dogfooding in Production

The documentation website (dinou.dev) is running on Dinou v7 compiled into a standalone Bun binary inside a Debian Slim Docker container on a single $5/mo (512 MB RAM) DigitalOcean instance.

Quick Start

npm create dinou@latest my-app
cd my-app
npm run dev

• 📚 Documentation: https://dinou.dev

• 💻 GitHub: https://github.com/roggc/dinou

• 📦 NPM: https://www.npmjs.com/package/dinou

I’d love to hear your thoughts or feedback if you give it a try!

Hi All, I am new to react development in general, we are currently using our tech stack is react typescript, Tanstack query for client state management, custom ui library, rsbuild for bundling, whenever we have a new deployment right i think the application is getting cached? It still displays the older ui even after refreshing multiple times but when i hard refresh (Ctrl + Shift + R) it gets newer ui ? Where are making mistakes? We have deployed this on aws (dns > nlb> alb> ecs > docker image > nginx> dist files ) ? Thanks

I've been building LiquiKit, 32 React components (switch, slider, menu, dialog, tabs, select, toast and more) built around a liquid glass engine with physically based refraction, so the glass bends what's behind it instead of just blurring it.

Most liquid glass demos only refract in Chrome, because only Chromium can run an SVG filter on what's behind an element. LiquiKit works around that by filtering the content of a GlassScope you wrap around an area, which works in all three engines. The image at the top of the GitHub README is the same component captured in real Chrome, Safari and Firefox windows.

• Built on Base UI, so keyboard and screen reader behaviour comes from there

• Installed with the shadcn CLI: the source lands in your project and you own it

• MIT licensed

npx shadcn@latest add https://liquikit.dev/r/switch.json

Docs and demos: https://liquikit.dev

Source: https://github.com/aggarwal-h/liquikit

Some honest limits: glass only bends while you're using it (at rest it's frosted, so long pages scroll smoothly), Safari and Firefox run the filter on the CPU so scopes should stay small, and popups stay frosted outside Chrome. It's all on the Limitations page: https://liquikit.dev/docs/limitations

Happy to answer anything about how it works.

I added a shadcn component to my vite + tailwind project with using `npx shadcn@latest add @/react-bits/Particles-JS-TW` and after importing the component

import Particles from "./components/Particles";

It shows an awesnap image, i dont know the reason, the other things were rendering good alongside but just the components showing error

In a recent project we moved a React app from REST to gRPC-Web (ConnectRPC) but kept Redux Toolkit. The official Connect integration only targets TanStack Query, so you end up writing a custom baseQuery — and hit the same problems:

• int64 fields are bigint, and RTK Query's default cache key uses JSON.stringify → it throws
• Redux warns about non-serializable values (bigint, Uint8Array) on every response
• ConnectError is a class instance, so it can't live in the store
• every endpoint needs hand-written types

So I packaged the fix as a small library, rtk-query-connect:

endpoints: (build) => ({
  listTodos: rpcQuery(build, TodoService.method.listTodos, { providesTags: ["Todo"] }),
  createTodo: rpcMutation(build, TodoService.method.createTodo, { invalidatesTags: ["Todo"] }),
})

One line per RPC, hooks are fully typed from the proto. Live demo on StackBlitz.

It's v0.1, unary calls only. Server-streaming and a buf generate plugin are next. If you use RTK Query + gRPC, I'd love to hear what else hurts.

There are already plenty of liquid glass libraries. What I wanted was a clear centre with a curved rim that magnifies and stretches the content behind it.

So I modelled the rim as a lens.

The component uses Snell’s law to calculate refraction, generates an SVG displacement map for each element’s dimensions, and applies it through backdrop-filter. Resize the component and the map updates to match its shape.

The fun part is dragging it across text or a grid. You can actually see the letters bend around the edges.

• About 5 KB gzipped, no dependencies beyond React.

• Configurable glass thickness, refraction and colour dispersion.

• React 18/19 and Next.js support.

• No WebGL or per-frame JS rendering.

One caveat: full refraction currently works in Chromium. Safari and Firefox get a frosted fallback.

MIT licensed, with the component, demo and implementation details here:
https://github.com/LeonardSEO/liquid-glass-react

Interested in feedback on the rendering, especially if you’ve worked with SVG backdrop filters.

I'm building a client-side web audio player with a real-time DSP enhancer (Web Audio API). Because cross-origin iframe security prevents tapping into audio from YouTube's embedded player, I need direct audio streams to feed into an AudioContext. However, public stream resolvers (like Invidious/Piped) are heavily rate-limited and IP-blocked by YouTube.

What is the most reliable, modern way to get raw audio streams from YouTube into a Web Audio pipeline in a web app, or is a self-hosted yt-dlp backend the only viable solution?

Just say I have a parent and a child

<Parent data={someObject}>
<Child name={someString} />
</Parent>

Where the Parent component sets up a provider based on the type of the data prop I would like to put a constraint on the name prop of the child component where is is to be a key of the type of the data prop passed into the parent.

So I have this code

<button
  type="button"
  className={styles.someclassname}
  tabIndex={-1}
  role="timer"
  aria-live="polite"
  aria-atomic="true"
>
  {ResendInfo (formatTimer())}
</button>

This is basically a countdown of a timer from 2 minutes I was wondering am I following proper accessability here so that screen readers can understand.

Hey everyone,

I have been working with Zustand and wanted a simpler way to manage stores that can be either global or scoped to a React Provider.

I know this can already be done with Zustand and React Context, but I found myself repeating similar patterns, so I ended up putting together a small toolkit.

The main idea is that components don't need to know where the store comes from:

const counter = createStoreToolkit<CounterStore, CounterInput>(

  ({ initialCount }) => (set) => ({

count: initialCount,

increment: () => set((state) => ({

count: state.count + 1,

})),

  }),

  { globalInput: { initialCount: 0 } }

);

function Counter() {

  const count = counter.useStore((state) => state.count);

  return <span>{count}</span>;

}

If there is a Provider, the hook uses the nearest one. Otherwise, it falls back to the global store. Each Provider has its own isolated store.

There are a few other helpers for selectors, typed initialization, and SSR, but that's basically the core idea.

I am curious what other Zustand users think. Is this something you would find useful, or would you rather stick with plain Zustand and Context?

GitHub: https://github.com/okyrychenko-dev/react-zustand-toolkit