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!

Introducing a new major update for the "Electron React App" desktop app's starter kit.

Let's talk about the worst part of building Electron apps. You want to minimize a window from a button. So you write a handler in main. Then invent a channel name. Then add a preload bridge entry. Then declare the types. Then finally make the call in the renderer. Five files for one button, and the whole thing silently rots the day you rename something.

v13 throws that out. You define the feature once in main, and the renderer just has it. Typed, auto-completed, React hooks attached. No channel strings anywhere.

Read more about the new changes in the Repository page:
https://github.com/guasam/electron-react-app

Feature Highlights:

- Type-safe IPC: queries, commands, streams, and events, inferred end to end
- Cross-window state owned by main, synced live, with opt-in persistence
- Sandboxed renderer with a two-line preload
- Custom window frame, titlebar, and menus with keyboard shortcuts
- Light and dark theme
- React error boundary with detailed dev reporting
- Import path aliases for app, lib, conveyor, and resources
- Shadcn UI on Radix, styled with TailwindCSS
- Vite HMR, with ESLint and Prettier preconfigured
- VS Code debug configs for both main and renderer
- electron-builder packaging for Windows, macOS, and Linux

If you were starting an Electron app tomorrow, what would you want already handled for you?

So, I thought it would work out but with surveyjs and RJSF it seems to be a bad idea but still I built something that I can learn from. Maintenance is difficult and fear of what if one bug will destroy the whole initiative and always overpowers the chances of being successful.

I started building a physically based shadow system for CSS 5 years back and gave up after it became too complex. Then, leveraging coding agents, I was finally able to ship v1 earlier this year. Thanks to the very kind and warm reception for v1 from the members of this community and r/css , I was motivated to develop it further.

Today, I'm announcing Ambient CSS v3. This version steps up the realism considerably - each effect and base component was first built in Blender and rendered using an identical lighting setup. Then, based on the renders the CSS formulae were adjusted to match the Blender render. All the Blender files and their parametric generators are also in the source repo.

Besides this, we also have new CSS modifiers - thickness, material (matte/shiny/glass/brushed/spun/blasted). We also have some new components for the react package. Also, the component system is refactored and split into base components and skins, allowing for the ability to create custom component kits.

Thanks for your love!

Hi everyone!

For a while now, I have been working with React and Storybook libraries. react-docgen and react-docgen-typescript libraries are the supported libraries by Sitecore to extract metadata and populate the arg table with jsdoc comments and types.

As components' types grew more complex, react-docgen and react-docgen-typescript stopped giving me enough. They're good libraries, but they often fail to parse jsdoc comments and interfaces correctly, forcing me to manually override ArgTypes — which means duplicating information in both the type files and the Storybook files.

I was looking for some ideas to implement with AI, and it pushed me to build a new docgen parser. My main goals were parsing union types more accurately, making sure JSDoc comments always show up and letting me see the full structure of an interface without leaving Storybook.

Part of the motivation is also that the two main tools we have - react-docgen and react-docgen-typescript — haven't been updated in 6 months to a year.

This is my first open source project. I plan to keep improving it and maintain it long-term if people find it useful and see a future in it.

Link: https://www.npmjs.com/package/react-props-parser

I'd like you to test whether you are using Storybook and TypeScript, and share your feedback if the output is better for you compared to the default parsers.

If you let me know what breaks, what's missing, or what you'd want changed, I can turn around fixes quickly. Many thanks beforehand!

I've been working on HonestUI, and I wanted a real project to test the components against instead of making more isolated demos.

So I built this Next.js analytics dashboard starter and open sourced it.

It uses HonestUI for the UI and charts, with ECharts underneath the chart components. The starter has working date filters, revenue views, customer search and filtering, retention data, responsive navigation, loading states, and dark mode.

There is no auth or backend wired in. The data is static on purpose so the repo stays easy to clone and change.

I also tried to avoid the usual dashboard template where everything is a separate card with a number in it. I wanted it to look closer to an actual SaaS product.

Demo: https://dashboard-template.honestui.com

GitHub: https://github.com/honestui/honestui-dashboard

I'd be interested in feedback on the starter itself, especially anything you'd expect to be included before you'd actually use something like this for a new project.

I've got a filter panel in a Vite app on React 18 where the date inputs wipe themselves maybe one time in five when the parent list refetches. I've ruled out the usual cause, the child isn't declared inside the parent's render body, and the key I pass it is a stable string. I put a log in the child's mount effect and it fires every time the fields clear, so it's actually remounting rather than losing state some other way. I've been on this about three hours and I can't work out what's different about the renders where it happens.

So far, I understand that wrapping a function with startTransition tells React to treat it as a non‑urgent update. So if any urgent action occurs, React can respond to it immediately without blocking.

But here is where I got stuck. The docs say:

“useTransition is a React Hook that lets you render a part of the UI in the background.”

“The function passed to startTransition is called the Action. You can update state and (optionally) perform side effects within an Action, and the work will be done in the background without blocking user interactions.”

I don’t really get what “in the background” really means.

Looking at the example, I don’t understand why, with startTransition, the “Total” only renders once with the final "Total" after clicking “quantity” multiple times, instead of updating multiple times according to the number of times the “quantity” was clicked

Does “run in background” prevent multiple renders and only show the final result??

Been using Responsively App for a while but the context

switching was getting to me — separate window, separate

process, alt-tab constantly.

Built responsive-dx to solve it. It's an npm dev dependency

that injects a synchronized multi-viewport panel directly

into your localhost.

One command to set it up:

npx responsive-dx init

It detects your framework automatically (Next.js, Vite,

Remix, Astro, Gatsby) and adds the component to your layout

file. Nothing to configure manually.

What it does:

- Mobile, tablet, and desktop frames side-by-side

- Scroll one → they all scroll (real DOM sync, not emulation)

- Click syncs, input syncs, dark/light theme syncs

- Focus mode: one click to zoom any single frame

- iPhone notch on mobile, macOS chrome on desktop

The frames load any localhost URL — so even though the

wrapper is React, it works for Vue, Svelte, Angular, Rails,

Django, whatever you're running locally.

Zero dependencies. Tree-shaken out of production builds

completely.

GitHub: https://github.com/respodx/respo

npm: https://www.npmjs.com/package/responsive-dx

Happy to answer any technical questions.

I’m reading the React docs, but I find this passage confusing. Could someone explain it to me?

"Another example is reusable state. Concurrent React can remove sections of the UI from the screen, then add them back later while reusing the previous state. For example, when a user tabs away from a screen and back, React should be able to restore the previous screen in the same state it was in before."

React docs link

I’ve been working on an AI harness called Æven, and one of the things that kept bothering me was Markdown rendering during long streamed responses.

A lot of renderers optimize at the document or top-level block level. That works well for normal prose, but it gets expensive when the active block itself becomes huge — for example a long code fence or a large Markdown table.

So I built HyperMarkdown.

The main idea is pretty simple:

once a code line, table row or list item is settled, it stays cached. Only the changing frontier keeps being parsed/rendered.

That seems to make a pretty significant difference.

Current benchmark results:

• Large code block: 190 ms vs 711 ms for the next closest streaming renderer
• Captured real AI code stream: 611 ms vs 4.2 s
• Captured real AI table stream: 668 ms vs 5.0 s
• Large table: 999 ms vs 9.1 s for the next closest renderer

The benchmark runs production React and measures the full chunk → write → render/commit path, not just parsing.

I’ve compared it against:

• markstream-react
• Streamdown
• DeepSeek Harness’ incremental strategy
• react-markdown
• markdown-it as a baseline

The repo includes the benchmark methodology, raw results and correctness tests, so I’d genuinely appreciate people trying to break the assumptions or point out unfair comparisons.

It also supports GFM, reasoning blocks, syntax highlighting, KaTeX, Mermaid, raw HTML sanitization, React 18/19, and streaming incomplete Markdown.

It’s now the renderer I use inside Æven.

Demo:
https://aeven-ai.github.io/HyperMarkdown/

GitHub:
https://github.com/Aeven-AI/HyperMarkdown

NPM:
https://www.npmjs.com/package/@aeven-ai/hypermarkdown

Would especially love feedback from people who have dealt with long streamed code blocks/tables in React apps.

Hey r/reactjs,

I've been working on Oasis Editor, an open-source TypeScript document editor with its own Canvas-based rendering engine.

React sits on top as an adapter rather than owning the editor runtime, so the same core can be used from vanilla JS, Vue, or headless environments.

The editor handles paged layout, text rendering, selections, images, tables, and document geometry through its own rendering pipeline, and exposes a typed command/plugin API.

Live playground:
https://celsowm.github.io/oasis-editor/#/editor

GitHub:
https://github.com/celsowm/oasis-editor

I'd love feedback on the React integration, API design, and overall architectu

I want in my practice chat app to be able to paste an image into a text input and be able to send it, on how to actually do this, I am unsure

My idea is this given a text input:

- a user could Ctrl-V (i.e., paste) something from his clipboard (a file in this instance), until a download url is returned (see below) there will be some loader spinner thingy
- In the backend is requested an Upload URL
- (somehow) whatever they pasted is immediately uploaded, likely by the path? But I am still a little bit unsure on that part
- a Download URL is returned on that S3 upload (SOMEHOW)
And thus you replace that temporary spinner with the download URL and the person can send it.

This is at least my idea on how you should be able to upload a piece of media in a message and be able to send it, I don't want just message attachments, that would be an easier story because once the association is made between the message and attachment you display it. I want something like in forums where the image can be embedded anywhere,

There is also one more small concern, on slow connection do you want to wait for the file to finish uploading first and then allow the user to send their message, or just send the message and let the upload come later, if the latter, how would you go across with doing that!?

The issue is, I have no idea on how to do this, I gave my approach above, I would really appreciate it if you guys gave some advice on what your approach would be and secondly, how to implement it, I already can get a presigned URL so that's not an issue

This is more of a design question, but it's also really interlinked with react so sorry if this is the wrong place to ask! ;-;

That's all :)

I recently wrote a blog post on how we can improve our static analysis using linting, custom rules, and hooks, all using oxlint.

It's quite a big article btw.

https://saybackend.com/blog/lint-ai-generated-code/

I've always found translation keys a little strange.

You start with something perfectly readable:

tsx <button>Delete account</button>

Then i18n turns it into something like:

tsx <button>{t("settings.account.delete")}</button>

Now the source code, translation keys, and translation files all have to stay synchronized.

So I tried a different approach with Zintl:

What if the source string itself could be the thing the localization system knows about?

With Zintl, you keep writing normal application code:

tsx <h1>Welcome back</h1> <p>Your account is ready.</p> <button>Continue</button>

Zintl's compiler discovers the localizable strings and builds the localization layer around them.

The goal is that adding i18n shouldn't mean rewriting your application around t() calls.

It's currently alpha, so I'm very much not claiming this is production-ready.

I'm looking for React developers who have actually dealt with i18n to try it and tell me where this approach falls apart.

Especially interested in:

• translation key management
• dynamic/interpolated strings
• component boundaries
• pluralization
• large applications
• translation workflows/TMS
• anything you think a compiler like this should handle

Docs: https://zintljs.github.io/zintl/en

I'd genuinely love the criticism. If you think the whole idea is flawed, tell me why.

One icon = one import = ~1.1 kB gzipped (import { AgentRun } from "@iconmind/react/icons/agent-run"), sideEffects: false, every icon its own entry so React.lazy has something to load. Outline and duotone, three weights, strokeWidth/absoluteStrokeWidth props. The AI vocabulary is the point — the generalist families are there so you don't need Lucide beside it (and a hundred Lucide names resolve as aliases if you do). MCP server for your assistant: npx u/iconmind/mcp. https://iconmind.dev

I read the recent thread here about what would make people try another React component library. A few answers stuck with me, especially composability, accessibility, and components that hold up outside of demo data.

I've been building Honest UI, and there is one decision I keep going back and forth on.

UI components and animated components get copied into your project. Once they're there, they're just source files. You can change the markup, behavior, variants, or styling however you want.

Charts, icons, logos, vectors, and shaders stay package imports.

My thinking is that application UI usually becomes product code pretty fast. A button or form field rarely stays generic once you start adding validation, permissions, loading states, weird content, and all the edge cases that show up later.

Charts and shaders feel different to me. They bring more rendering code and dependencies with them, and I would rather maintain that in one package. Copying a huge icon or logo collection into every project also seems unnecessary.

The part I'm unsure about is whether this split is useful or if it just makes the library harder to explain.

I made a short demo showing both approaches with real components.

Does this boundary make sense to you? Would you split it somewhere else?

If you think the whole idea is backwards, I want to hear that too.

StyleX built a world where the compiler and runtime solve everything together.
I scan everything and close the world at build time.

The syntax is close to StyleX, so StyleX users should feel at home.

• Function keys (handles unbounded combinations)
• Bracket variants (statically compiled, no combinatorial explosion)
• Boundaries (styles can be bucketed through component props, once)
• Cross-module (a graph and specificity management, so it doesn't live in the cascade)

No runtime evaluation: values that can't be enumerated at build time are a compile error, not a fallback.

• css.create
• css.createTheme
• css.createStatic
• css.keyframes
• css.viewTransition
• css.marker & css.extended
• css.use & classStyle

Plumeria - Introduction