I've been working on virtual scrolling in React and found a weird issue in Safari.

When scrolling normally, everything was fine. But if I scroll very fast, sometimes I could see a white empty area for a very short moment before the next rows appeared.

First I thought React rendering was just too slow.

So I increased overscan and kept more rows above and below the viewport. It helped a lot, but I could still see the problem sometimes.

After looking into it more, I found that Safari's scroll/compositor layer can move before React finishes rendering the next virtual rows.

So basically Safari was already showing the next position, but React was still catching up.

I kept trying to make React faster, but then I tried something a little different.

Instead of trying to always win the race, I put a simple CSS background behind the real rows.

It's just a repeating-linear-gradient with the same row height, background and border.

Something like:

Safari scrolls
    ↓
CSS row background is already there
    ↓
React renders next rows
    ↓
Real rows cover it

There is no real data in the background. No cells, no events. It's just visual. I also set pointer-events: none and aria-hidden.

With this + extra overscan above and below, the flicker was almost gone.

I thought it was interesting because at first I was trying to solve a React performance problem.

But maybe it wasn't only about making React faster.

Sometimes it's enough to make those few milliseconds invisible. :)

Anyone had a similar problem with Safari and virtual scrolling?

I'm curious how you solved it.

Repo: https://github.com/coterahq/griddle - demo's linked in the readme.

We've been running data-grids over large parquet backed datasets in prod for quite a while now, and we decided to OS the component for others that might find it useful.

I am creating a little chat app for practice, but I was unsure what direction to take with the editor, out of the options I found TipTap and Lexical, I tried a bit of both (Didn't get very far with either yet) But I am still so torn on which one I should try first

In this I want more possibilities of what you can put in the chat, for example: Embedded images, tables, maybe some excalidraw integration, etc.

I also don't want to spend too much time on either and realizing that picking one over the other was not worth it long-term because of the timetaken

If anyone has used tiptap, lexical or both could you give some pro's and con's to each and some guidance on what I should pick?

Thanks! :)

Posted this a couple of months back: https://www.reddit.com/r/reactjs/comments/1thqhce/why_is_pictureinpicture_only_for_video_i_built/

Quick recap: pip-it-up pops any React component into a floating always-on-top window via the Document PiP API.

Two new things in 0.2.0:

Auto PiP: pops out on its own when the tab is hidden.

useAutoPip(enter)

Good for a standup call(already exists in GMeet) you stay on while pulling up a doc, a test runner you keep an eye on while reading docs, a reference video that plays while you edit, or an interview recording that keeps going while you type.

Route-persistent PiP: moving a component in React normally remounts it, so video resets to frame 0 and editors lose undo history. This moves the real DOM node, so it survives navigation.

<PipProvider registry={{ player: <VideoPlayer /> }}>
  <Routes />
</PipProvider>

<PipAnchor id="player" />

Good for a course lesson that plays on while you browse other lessons, a log stream docked across your admin panel, a metrics chart that stays up as you move between boards, or a draft preview that survives CMS navigation.

Still Chrome/Edge only. Safari and Firefox fall back to a popup.

Website: https://www.pipitup.dev/
Demos: https://pip-it-up-playground.vercel.app/
Code: https://github.com/Shakya47/pip-it-up

We’ve gone full-Rust with our build pipeline at Outlyne.com and it feels like the React Compiler has really arrived. The last time I posted about using React Compiler here, I talked about how good it’s been for us overall, but also about all its limitations, the biggest of which was that it would bail out on compiling any component or hook that had a try/catch with conditional logic of any kind (if/else, ternary, ??, ||, optional chaining). Another big one was that it would bail on computed object keys, which bit us a few times with assembling classes using clsx (e.g. className={clsx({ [`item-${props.index}`]: props.isItem })}).

Both of those are fixed now. The oxc team shipped official support for the Rust React Compiler on August 4th, and that support includes all of the fixes to the compiler since the v1.0 release of the Babel-based compiler. In our codebase, seven more functions the compiler had been skipping are now compiling, five from the try/catch fix, two from computed keys. And that’s lower than it would be if I hadn’t gone through and contorted eight components to keep conditionals out of their try/catch blocks, including adding a @ts-expect-error from having to drop an optional chain and extracting my auth flow into an async run() that’s immediately awaited inside the try, for no reason but to move the value blocks out of it. All of those workarounds have been rendered obsolete.

There are still bailouts, most notably logical assignment operators (??=, &&=, ||=), but far fewer, and now actively being addressed. A couple weeks ago, oxc shipped a version bump that prevents a bail out from reassigning a destructured prop that then gets read in a nested closure.

Going Rust is also, of course, much faster. The compiler step on our 1,036 files dropped from 14.3s to 0.81s (~17.6×), and the build overall from 22.1s to 9.3s. And we verified parity with the Babel compiler. Across all 1,036 files, there are zero functions the Babel compiler memoizes that the native one doesn’t. The only difference in the built JS before and after are the seven extra compiled functions.

I wrote a blog post with all the details and before/after configs both for folks using @vitejs/plugin-react and for those who use an alternative plugin (React Router framework mode’s plugin in our case): https://blog.master.dev/react-now-rusted-all-the-way-out/

Hi r/reactjs,

I wanted to share an open-source project I’ve been working on: designqr.

I built this component to turn QR codes into interactive, stylable 3D WebGL scenes while keeping them functional.

Features

• WebGL-Powered 3D Scenes: Render QR codes embedded in aesthetic 3D environments.
• Plug-and-Play React Component: Drop it straight into your React/Next.js app.
• Customizable: Control camera angles, transparent backgrounds, and themes.
• Live Interactive Playground: A dedicated web editor to customize, preview.

Quick Start

Install via npm:

npm i designqr

Usage in your component:

import { DesignQR } from 'designqr';
import 'designqr/style.css';

export default function App() {
  return (
    <DesignQR 
      value="https://your-link.com" 
      transparentBackground={true} 
    />
  );
}

🔗 Links

• Live Web Editor: https://design.johnson7543.com/qr
• GitHub Repo: https://github.com/johnson7543/design

I’d love to get your feedback on the component API, mobile performance/rendering optimizations, or any features you'd like to see added. Feel free to open issues or PR!

Hi all,

Sharing a project I recently finished and open-sourced: LaunchPad Lite.

It’s a clean starter template built around the Next.js 15 App Router ecosystem with a focus on type safety and modern auth:

- Better Auth: Handled via Server Actions and route handlers, avoiding legacy NextAuth quirks.

- Drizzle ORM: Minimalist schema setup designed to connect effortlessly with Supabase, Neon, or local Postgres.

- Tailwind CSS v4 + Radix UI: Fast UI primitives without CSS bloat.

GitHub: https://github.com/BZDevelopments/LaunchPad-Lite

For anyone who eventually needs full Stripe subscriptions, AI SDK v5, or multi-layout support, I also maintain a Pro version, but Lite is 100% self-contained and free forever.

Take a look at the repo structure and let me know what you think of the architecture!

If you're working on a React project and need some avatars for profiles, dashboards, user lists, comments, or mock data, here's a collection that might be useful.

There are 200+ free, open-source UI avatars that you can use in your projects.

There's also a UI Avatar Guide on the page if you want to learn more about using avatars in interfaces.

🔗 https://radianui.com/resources/avatar

Sharing it in case it's useful for anyone working on a React project!

I built effective-rsc because I wanted React Server Components and Effect to share one coherent application model.

The core idea is simple: React owns the UI protocol, and Effect owns the runtime.

What is different:

• Pages, Layouts, Components, Middleware, and Server Functions run as Effects.
• Application services are provided once through an Effect Layer.
• Request cancellation interrupts the Effect work and cleans up its resources.
• Server Functions preserve React’s native protocol while adding Schema-validated input.
• The client router uses the Navigation API and commits at the first UI update while the remaining Flight response continues streaming.
• There is no History API fallback.

The framework is intentionally experimental. It currently requires Bun, React Canary, Effect v4 RC, TypeScript 7, Rspack, and modern browser APIs.

You can try it with:

bunx create-ersc-app my-app

Source: https://github.com/nikhilsnayak/effective-rsc

Write-up and interactive router demo: https://www.nikhilsnayak.dev/blog/introducing-effective-rsc

Hey r/reactjs,

Whenever I spin up a new Next.js project, I always end up sinking time into the same repetitive setup: organizing folders, setting up modular architecture patterns, and configuring boilerplate before writing a single line of feature code.

To scratch my own itch and learn how developer tooling works under the hood, I built and published my first npm package: nexarch-cli.

It’s an interactive CLI that helps scaffold a clean, modular Next.js architecture in seconds so you can get right to building components and features.

You can run it directly with zero global installation:

npx nexarch-cli

• GitHub:https://github.com/CaffeineLogs/nexarch-cli
• NPM:https://www.npmjs.com/package/nexarch-cli

I’m still pretty new to this and honestly had no idea what went into publishing CLI tools until this week. Would genuinely love some brutal honesty—let me know if the architecture makes sense, what I broke, or what features are missing.

If you give it a spin or check out the code, let me know what you think in the comments!

Okay, I'm making a little website with the new React (I'm coming back from 7 years [Tailwind CSS included, Typescript (for the first time I'll add)].) I'm making a hamburger menu and the onClick function just didn't work. Okay, so there must be some weird stuff happening. No. I made a button with an onClick in a nearly top-level fragment and it does nothing.

I just want to understand if there's something fundamental that has changed, perhaps? This isn't a "please give me answers" or information kind of deal. I just want to know if I'm going crazy here. Is there any weird bugs that React has created like it did a bunch from '18-'20; or should I just "git gud"?

const handleClickTest = (event: React.MouseEvent<HTMLButtonElement>) => {
        console.log("AAAAAAAA", event.currentTarget);
    };

    return (
        <>
            <button className="relative z-50 pointer-events-auto" 
                    onClick={(e) => handleClickTest(e)}
            >
                <h1>button</h1>
            </button>
...

The React half is an ordinary React component library: typed props, a shared Tailwind layer, no hex and no bare pixel inside a component. What is unusual is where the API comes from. Every member's name, type, default and meaning is a contract file, both layers' types are generated from it, and a pixel-parity check holds the two renderings to zero difference, so the layers cannot drift apart quietly.

Accessibility works the same way: each component declares the WAI-ARIA pattern it implements, and a gate fails on the day it stops answering it, rather than an audit happening once per release.
  
The link is the benches: Calendly, ClickUp, Duolingo, Etsy, Grafana, Instagram, Notion and Superhuman, each mocked twice, every half installing from npm. MIT.

 https://arena.dravensoft.org/web-benches/

Mods kindly OK'd this. I'm finishing a master's thesis on React state management, and instead of arguing "just use Context" vs "you'll want Redux", I measured it: three application archetypes (read-heavy product catalog, multi-step form, live dashboard), each built twice, once with Context, once with Redux Toolkit; identical UIs, automated render counting.

You can watch the difference live; every demo has a render counter in the corner. Try "Add to Cart" in both:

• Context: https://thesis-catalog-context-hell-henna.vercel.app
• Redux: https://thesis-catalog-redux-rtk-ruddy.vercel.app

Context re-renders every visible card; Redux re-renders one. Then in the form app the two are identical, which is the thesis in a sentence: it depends on the application type, and the dependency is measurable.

The benchmarks are half the story. The other half is practitioners, what you actually choose and why:

👉 https://forms.gle/oMRrGYQvsezWKn2P8 — 29 questions, ~5–7 minutes, anonymous, no sign-in, academic use only.

Happy to answer anything about the methodology in the comments — and war stories about when Context bit you, or when Redux turned out to be overkill, are very welcome.

Hi r/reactjs! We just shipped v1 of webmcp-react after quite a few beta versions to work out the kinks. It is MIT licensed and we're hoping to find some more contributors!

What it does

AI agents currently have to parse through 1000s of HTML tokens to browse a website. They essentially scrape the DOM and guess where the buttons are. WebMCP is a new web standard that fixes this. It adds document.modelContext to the browser, where a page registers typed tools an agent can call. Chrome shipped it in Early Preview in February, and since companies like Shopify and Codex support it fully. The spec was barebones, and there was no clean React-like way to integrate it into modern UIs, so we made one!

webmcp-react gives you a provider and one hook. The hook registers a tool when the component mounts and removes it on unmount.

```ts import { WebMCPProvider, useMcpTool } from "webmcp-react";
import { z } from "zod";

function SearchTool() {
useMcpTool({
name: "search",
description: "Search the catalog",
input: z.object({ query: z.string() }),
handler: async ({ query }) => ({
content: [{ type: "text", text: Results for: ${query} }],
}),
});

} ```

It ships with Zod and JSON Schema inputs, a built-in polyfill, SSR support for Next.js and Remix, StrictMode safety, execution state, and cancellation through AbortSignal.

WebMCP is early and we're looking for contributors. Chrome changes the API between releases, and only a few people track it. We are a small team and we don't intend to productize this since we made it mainly to add WebMCP support to our core website. The library works, but a standard needs many hands and many real sites. We'd love any bugs / feedback. If you want to help out with the project please DM me!!

Links:

• Repo: https://github.com/agentcathq/webmcp-react
• Playground: https://agentcathq.github.io/webmcp-react/playground/
• Install: npm install webmcp-react zod

Edit: Formatting was messed up

Here is my honest question:

What's the actual problem with the useEffect hook? All over the X/twitter, I see a lot of negativity about this hook. It seems like a buggy thing in React.

My opinion is that developers blame useEffect because it's often used for data fetching as the primary use case. As we deal with various states like loading, data, error etc… synchronization of these causes bugs.

Also, a misunderstanding of the rendering cycle in React, such as where useEffect gets called could introduce additional misuses and bugs.

Hence, just saying useEffect is evil, may not be the right assumption is what I think. But, there could be cases that I'm missing.

What's your take or opinion about it?

A month ago I posted AdaptTable here. Since then the feature surface has grown quite a bit, and one of the more interesting problems has been keeping all of that optional functionality from turning the main table into one huge bundle.

Some of the heavier capabilities now have their own entry points:

@adapttable/core/xlsx
@adapttable/core/pdf
@adapttable/core/formula
@adapttable/core/pivot
@adapttable/core/stream
@adapttable/core/sparkline

The React adapters are moving in the same direction:

@adapttable/mantine/row-reorder
@adapttable/mantine/grouping
@adapttable/mantine/editing
@adapttable/mantine/virtualize
@adapttable/mantine/cell-navigation

The core entries already avoid the bundle cost unless they’re imported.
The adapter side is not completely there yet because some optional feature implementations are still reachable from the root DataTable import graph.

In v3 I’m moving those implementations out so the application only pays for the features it actually imports.

I’m also separating the framework-neutral engine logic from the React hooks/components, which should eventually make Vue and Angular bindings possible without duplicating the table engine.

For people who maintain larger React libraries: how far would you take this?

At what point do lots of feature-specific entry points become more annoying for users than the bundle-size savings are worth?

For context, this is the project:
GitHub⁠ · Live demo⁠ · v1 → v2.9 write-up⁠

Hi everyone,

I'm looking for a fully open-source spreadsheet component for React.

I do not want a paid/commercial library or a library where important spreadsheet features require a paid license.

I need something closer to Excel / Google Sheets, rather than just a data grid.

Main requirements:

• Fully open source and usable in a commercial project
• React + TypeScript support
• Import .xlsx Excel files
• Export to .xlsx
• Preserve Excel formatting as much as possible
• Formulas and calculations
• Multiple worksheets
• Cell formatting
• Merge/unmerge cells
• Copy/paste
• Sorting and filtering
• Data validation/dropdowns
• Freeze rows/columns
• Undo/redo
• Insert/delete/resize rows and columns
• Good performance with larger worksheets
• API for programmatically reading/updating cells
• Custom toolbar/components
• Extensible enough to implement drag-and-drop elements/components into spreadsheet cells

I've already looked at Univer and FortuneSheet, but I'm trying to find the best option with strong Excel import/export support.

My ideal flow is:

Import existing .xlsx → Edit in React → Export back to .xlsx

without losing important formulas, formatting, worksheets, merged cells, etc.

What is the best fully open-source React spreadsheet library in 2026 for this?

If you're using one in production, I'd really appreciate hearing about its limitations, especially around Excel import/export.

Thanks!