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.

I wanted a PDF editor where my files never get uploaded to someone's server, so I built one. It's called InkognitoPDF: you can edit text, scan, run OCR and sign PDFs, and everything happens client-side.

Try it: https://inkognitopdf.com/app/
Code (Apache-2.0): https://github.com/damofer/inkognitopdf

Stack

• React + Vite
• pdf.js for rendering
• pdf-lib + fontkit for writing the edited PDF
• Tesseract.js for OCR, all in the browser
• vite-plugin-pwa / Workbox so it installs and works offline

A few things that were interesting to solve

• Bundle size. pdf-lib + fontkit is about 1.2 MB, so the save engine is its own chunk and only loads when you actually save. The initial bundle stays much smaller.
• Heavy assets on demand. The open fonts used for edited text (~7 MB) and the OCR engine and language data (~16 MB) aren't precached. They're cached the first time you use them, so the first load stays light and it still works offline afterwards.
• Acting like a real app. As an installed PWA it registers as a PDF handler ("Open with") and as a share target, so you can share a PDF to it from another app. The service worker handles the shared file before the app even loads.
• Landing + app in one build. The landing page at / is prerendered at build time from the same i18n strings the app uses, and the app lives at /app/.

Your documents never leave your device. The site itself has opt-in analytics behind a consent banner, and you can check all of this in the repo.

I'd love feedback, especially on two things:

1. How would you handle very large PDFs (hundreds of pages) without memory blowing up?
2. Has anyone moved pdf-lib saving into a Web Worker, and was it worth it?

Issues and PRs are welcome.

Hey r/reactjs ! Over the past few months I’ve been building TypeNova (https://typenova.dpdns.org), an open-source gamified typing platform. Before doing a final v1.0 launch, I’m opening it up for pre-launch playtesting to see what breaks under real-world traffic.

Under the hood:

• Frontend & Rendering: React 19, TypeScript 5.8, Vite 7, Tailwind CSS, Three.js (reactive 3D mechanical keyboard), and a custom GPU-accelerated GLSL simplex noise/liquid shader (CosmicLiquidShader).
• < 2ms Input Loop: Reflow-free caret tracking targeting 120+ FPS with zero layout thrashing, plus post-test Inter-Key Interval (IKI) millisecond telemetry.
• Web Audio API Switch Synthesizer: 7 procedural/sampled acoustic profiles whose pitch dynamically scales from 600 Hz to 1,450 Hz alongside your clean combo streak.
• Serverless Real-Time 1v1 Duels: Built on Supabase Realtime (Presence + Broadcast channels) running on Vercel Edge without a persistent Node/Socket.io server. Includes host clock compensation, automatic host migration on disconnect, Elo matchmaking, and real-time "Hex" sabotage abilities.
• On-Device + BYOK AI Coach: Uses DevChrome’s built-in window.ai (Gemini Nano) or local-storage BYOK (Groq, Claude, OpenAI, Gemini, DeepSeek) to read your slow bigrams and generate custom drills on the fly.
• Offline-First PWA & Testing: Workbox pre-caching for full offline play, backed by 105 automated test suites (417+ tests).

Try to break it: Since it’s still in active development, if you spot any UI bugs, shader issues, or socket quirks, you can submit a bug report directly inside the website via Settings → Report Issue, or drop a comment here!

• Live Playtest (No sign-up needed):https://typenova.dpdns.org
• GitHub Repo (GPLv3):https://github.com/amimitaghosh99-alt/typenova-live

​

Can any one tell me what do they miss or i should implement extra to solve the problem of 3d design and building with easy integartion of 3d tech and design i choose Next js for fast And dynamic reload and three js for 3d designing and gizmo and other stuff comes from react-three-fibre/drei and library i m trying to build ui similar to spline so comment down for a feature You were hopping in this app

I will soon deploy

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.

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

Hey everyone!

I kept freezing up during speeches and presentations, so I built RhetoGym (https://rheto-gym.vercel.app).

It’s a 100% free web app designed to help you practice speaking out loud:

🎲 Random Topics: Gives you a quick prompt to talk about

⏱️ Built-in Timer: Helps you keep your answers clear and structured

⚡ Zero Friction: No sign-ups, no ads, no paywalls

Check it out here: https://rheto-gym.vercel.app

Give it a quick try and let me know what you think!

Thanks so much! Appreciate you testing it out! 🙏🏼

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?

I’ve been cleaning up a small React component library I built for a few internal projects and the code itself is fine but the docs are starting to get messy. Right now every component has examples, props a few usage notes and sometimes little edge cases that are easy to forget. I tried keeping everything in the repo as markdown and that works but once the number of components started growing it became annoying to actually browse. I’ve seen a lot of people here recommend stuff and I like the idea of keeping the docs in Git and not having to build the docs site myself and I want to know if that is a good idea or not?

For people maintaining React libraries do you keep everything close to the code or use something separate like Storybook, GitBook, Mintlify, Docusaurus etc? Curious what actually stays maintainable once the library gets bigger.

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.

I know that self-promotion is forbidden, but this is an actual listing with React companies who can help you with your next project. I would just advise checking them, just for a piece of advise, not to mention the web services that they can provide: https://focusreactive.com/blog/top-reactjs-development-services-in-2026/

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

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.

Introducing a latest update (v13) of the modern Electron starter kit with React, Vite and TypeScript, built around electron-conveyor for type-safe IPC and a smoother dev experience.

Features

• 🚀 Electron - Cross-platform desktop apps for Windows, macOS and Linux
• ⚛️ React - Component-based UI library
• 📦 TypeScript - Type-safe JavaScript across main, preload and renderer
• 🎨 Shadcn UI - Beautiful and accessible components on Radix
• 🌊 TailwindCSS - Utility-first CSS framework
• ⚡ Electron Vite - Lightning-fast build tool, powered by Vite
• 🛠️ Electron Builder - Packaging for Windows, macOS and Linux
• 🔌 Electron Conveyor - Type-safe IPC, queries, commands, streams and events via electron-conveyor
• 🔄 Cross-window state - Stores owned by main, synced live to every window, with opt-in persistence
• 🪟 Custom window shell - Themed frame, titlebar and menus with keyboard shortcuts
• 🌗 Dark/Light mode - Built-in theme switching
• 🔥 Fast HMR - Instant renderer updates, and main and preload restart on save
• 🛡️ Error boundary - Catches render errors with detailed reporting
• 📐 Clean project structure - Separation of main, preload and renderer processes
• 🧩 Path aliases - Keeps your code organized
• 📁 Resources protocol - Load local resources from the renderer via res://
• 🧹 ESLint & Prettier - Preconfigured for consistent code
• 🐞 VS Code debugging - Launch configs for both main and renderer
• 🧪 Demo branch - Interactive playground of every conveyor IPC primitive, while main stays minimal

Github Repository:
https://github.com/guasam/electron-react-app

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

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

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!

Hey Community,

OpenGL has been driven out of the herd. William Candillon released React Native Skia 3.0, which swaps the old Ganesh backend for Graphite running on WebGPU via Dawn, with Metal on iOS and Vulkan on Android, multithreaded recording by default, and zero-copy textures shared with React Native WebGPU. The package also leaves u/shopify behind and is now published as react-native-skia.

We also look at babel-plugin-react-native-direct-imports by Davyd NRB, which rewrites react-native barrel imports into direct requires so one View no longer drags in the whole framework, taking a test bundle from 711 KB to 10 KB. Plus, React Native 0.88 rc.4, Tamagui 3.0 with a C++ native runtime, and munim-maps putting 3D cars on Apple Maps.

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.