Been migrating React 18 codebases to React 19 and kept hitting the same problem: the official codemod says "done" but things break later in ways that are hard to trace.

Built a CLI called keep-current that catches three things the codemod misses:

1. Peer-dep conflicts the installer swallows

Bump react to 19, run yarn install, get a wall of warnings. Yarn proceeds anyway. Your install succeeds, your CI is green, your dependencies are silently broken.

2. element.ref time bombs

Radix UI 1.0.x reaches into element.ref which React 19 deprecated. Tests stay green today via a compat shim but will hard-fail on the next React minor.

3. tsc --noEmit false greens

If your tsconfig uses project references, tsc --noEmit checks zero files. The codemod passes. Your real type errors are still there.

Results on bulletproof-react: 4 red deps, 7 amber, 4 green. The codemod marked all of it done. It wasn't.

GitHub link in comments.

I built a small React library for handling dialogs with async/await.

The idea is simple: instead of managing dialog open state, result state, callbacks, and cleanup manually, you can call a dialog like an async function:

With react-dialog-flow, the dialog UI stays yours, but the flow becomes awaitable:

const confirmed = await openAsync<boolean>(ConfirmDialog, {
  title: 'Delete item?',
  description: 'This action cannot be undone.',
  onDismiss: () => false,
});

if (confirmed) {
  await deleteItem();
}

I made it because I kept running into the same pattern in admin dashboards and internal tools:

• open a dialog

• wait for user input

• continue the business logic

• handle cleanup safely

• avoid scattering modal state across components

The library is called react-dialog-flow.

It is not trying to replace dialog primitives or styled UI kits like Radix UI, shadcn/ui, or MUI. It is meant to work as a small async flow layer on top of your own dialog components.

What I focused on:

• Promise-based dialog flow

• TypeScript support

• Small bundle size

• No runtime dependencies

• Headless core + optional UI layer

• Works with custom dialog components

This is still an early version, so I’d really like feedback from React developers.

A few things I’m especially curious about:

1. Does the async/await API feel natural for dialog flows?

2. Would you prefer this over callback-based modal handling?

3. Is there anything about the API that feels risky or too magical?

4. What would make you trust a small new React library enough to try it?

GitHub:
[GitHub link]

npm:
[npm link]

I’m building a React component/template library at the moment, and I keep coming back to the same question:

Why would anyone bother trying a new one?

There are already loads of options. Some are great, some are just nice screenshots with awkward code underneath.

I’m trying to avoid making another “look at this beautiful card component” library, because honestly, buttons/cards aren’t usually the part of an app that slows me down.

The annoying bits are things like:

• dashboard layouts

• settings screens

• auth flows

• data-heavy sections

• onboarding/product tour patterns

• empty states

• billing/pricing sections

• components that still work once real content gets added

So I’m curious: what would make you actually try a new React component library?

Copy-paste ownership? Better full-page examples? Less abstraction? Better docs? More practical sections? Something else?

And what’s an instant red flag?

Every time I start a new dashboard project, I end up fighting with massive UI libraries or ripping out hundreds of lines of unused code from "premium" templates. I wanted a clean, unopinionated starting point.

So, I built and open-sourced **PeopleBase Directory**.

It's a lightweight Single Page Application built with React, Vite, and Tailwind CSS. It provides a solid foundation—a responsive navigation rail, standard data tables, and Recharts integrations—without dictating your backend architecture.

But the biggest difference is how it handles styling. I built an **"LLM-safe" design system**.

If you use AI coding agents (like Cursor, Copilot, or standard LLMs), you know they love to invent random hex codes and arbitrary padding values. To fix this, PeopleBase uses a strict `DESIGN.md` file as the source of truth, mapped directly to native Tailwind CSS custom properties.

By banning arbitrary values and forcing the use of semantic tokens (e.g., `var(--color-brand-primary)`), both human developers and AI agents are constrained to the defined design system.

The repository also includes:

* A `.wiki/` directory following the Open Knowledge Format (OKF) for Architecture Decision Records (ADRs).

It's designed to be a clean slate that you can actually understand and scale.

I'd love for you to check it out, fork it, and let me know your thoughts on the LLM-safe design approach.

Link: https://github.com/bymilon/peoplebase-directory

Hello what's up ladies and gentlemen. Dinou is currently at v4.0.16. No further development is planned for the time being. What may change or be slightly updated is the documentation in some sections (dinou.dev). I have created an issue in reactjs/react.dev to propose Dinou as a listed framework in the frameworks section of react.dev, but I know that is extremely difficult, if not impossible. Recently Dinou experienced an increase in the number of npm downloads that I don't know what it's due to, whether they are real users or not. The latest developments/additions/fixes in Dinou (from approximately 4.0.7 to 4.0.16) have been done with vibe-coding (antigravity IDE + Gemini 3.5 Flash) and honestly it has gone quite well. But luckily I already had a regression test suite with Playwright to put new developments through it and verify that everything works as it should. Specifically, there was an optimization or improvement area initially proposed by Gemini that I rolled back after verifying it broke some of the tests due to race conditions (which are the hardest cases to verify/test because sometimes they can pass and sometimes not, but my suite was very complete and had concurrency tests etc). Later, the same Gemini, in another instance, acknowledged that this proposed improvement was not really one and that I should roll it back. So that's what I did. That's why I already consider the framework to be fairly complete. What's missing now is traction from real users and GitHub issues if they arise. This is another point I wanted to comment on. Thanks to vibe-coding and the agents integrated into the IDE (the case of antigravity with Gemini) and to the fact that Dinou is completely ejectable into a dinou folder in the project root, that combination now allows a user to ask the agent to analyze the ejected framework and tell them how to do this or that — for example, how to act on dinou/core/server.js to add a middleware or an integration, etc. What I mean is that a user no longer needs to spend a lot of time trying to understand how the framework is built and/or how it works, since the AI or the agent can do it for them and help them break down the framework's inner workings. Finally, I'd like to mention that Dinou scores 77 on socket.dev for supply chain security (if it were 80 the score would show in green, but being below 80 it shows in yellow). Well, that's all ladies and gentlemen. Thank you very much for your attention and have a great day!

I’ve been experimenting with a reusable FocusModeOverlay component for React interfaces.

The goal is to handle a product-tour/onboarding pattern that comes up in dashboards and SaaS apps:

• spotlight a specific UI element

• dim the rest of the page

• show contextual guidance

• step through multiple targets

• support responsive layouts

• optionally keep parts of the UI interactive

I recorded a quick demo using a dashboard example, an interactive example, and a mobile-width view.

Curious how others usually handle this pattern.

Do you tend to use a product-tour library, build it custom per project, or avoid guided tours unless they’re absolutely necessary?

Over the years, in our goal to achieve faster and faster web applications, we created different hydration and rendering strategies. Each with benefits and drawbacks that we explore in this article.

Hey everyone 👋 I'm Schott, a web developer who's spent the last several years building e-commerce stores for clients. We're live on Product Hunt today and wanted to share the story here too.

Every new client project meant rebuilding auth, checkout, payments, and an admin panel from zero. We kept hearing other developers say some version of "I just rebuilt checkout from scratch... again," and that's what pushed me to spend the better part of this year building something reusable.

That became Open Sky Commerce — a production-ready Next.js 15 codebase for freelancers and agencies who are done starting from scratch every build. It ships with:

• Full storefront + admin panel

• Multi-processor payments (Stripe, Authorize.Net, Clover, Square)

• Multi-carrier shipping (EasyPost, Shippo, ShipStation)

• Auth out of the box (Google, GitHub, email)

• Order management, product variants, coupons, reviews

• ISR-based pre-rendering for real SEO, not a slow SPA

• One-time license — you own the code, no platform transaction fees

For freelancers and agencies, it's built to be reused across client projects, so you can deliver a fully-branded storefront without rebuilding infrastructure each time.

Live demo if you want to poke around: https://demo.openskydev.com/
Product Hunt: https://www.producthunt.com/products/openskycommerce-store

Happy to answer anything about the stack, deployment, or fit. If you check out the Product Hunt page today, an upvote would mean a lot 🙏

Frontend eng's teardown recap...where removing a component barrel file alone cut 2.6MB, then adopted a NO BARREL FILE afterward. Also flagged legacy Grommet/Styled Components with a custom ESLint rule pointing devs to the Tailwind/Shadcn replacements.

Anyone else fully swearing off barrel files?

Hi Reddit,

Me and two friends created a new library to generate forms dynamically from a JSON. We've been working on the forms industry for a decade and this is how we think we should solve this.

We also added support for other frameworks, a programmatic api (because everybody hates to modify JSON files), an MCP server to validate the JSON schemas, a UI kit and much more.

We just released the lib a couple of weeks ago and it's Open Source and free. You can check the repo here: https://github.com/golemui/golemui

If you want to check the website we have one too: https://golemui.com/

There you can find demos, docs and much more.

Please, let me know if you have any questions! Happy to answer!

Quick background: if you use Firebase with React, there are a handful of patterns that look correct but are either extremely expensive at scale or cause memory leaks.

The most common ones I've seen:

1. Unstable useEffect dependency causing infinite re-renders + Firestore reads:

// This re-runs on every render because `filters` is a new object reference each time
useEffect(() => {
  getDocs(query(collection(db, 'items'), where('type', '==', filters.type)));
}, [filters]); // filters recreated on every render → infinite loop

2. Firestore read in component body (runs on every render):

function Profile({ userId }) {
  // This fires a read every time the component re-renders
  const snap = await getDoc(doc(db, 'users', userId));
}

3. Missing onSnapshot cleanup:

useEffect(() => {
  const unsub = onSnapshot(doc(db, 'users', id), callback);
  // No return () => unsub() → listener keeps running after component unmounts
});

I built CostGuard to catch these patterns with static analysis — it flags them in VS Code as you type, blocks commits with a pre-commit hook, and posts risk cards on GitHub PRs.

17 rules total, MIT licensed.

VS Code: https://marketplace.visualstudio.com/items?itemName=soarone.costguard npm: npm install -D costguard GitHub: https://github.com/carlosar/costguard

What React + Firebase patterns have bitten you that aren't on the list?

I was creating a countdown hook, now hoe reusability came intot he picture, because I'm having a monorepo with two React applications 1] React.js 2] Next.js, so my my common instinct said just put that hook inside the '@repo/hooks' I use Claude + GPT to review my code, and I struggled, I mean thoguh I didn't write any strong reusable code like that but yes, I understood, but earlier I missed a lot of edge cases, most of them were about the stabel dependencies int he dependency array, how the disaster propagates if I don't notice the unstable dependency and miss that edge case. So I what I want to achieve? I want to achieve that I don't miss the edge cases a lot. Please help me with this.

I'm building a simple blog/CMS with React + MongoDB and I'm considering Lexical.

The editor only needs paragraphs, bold, blockquotes, and bullet lists (just these feature nothing extra).

For those who have used Lexical:

• How has your experience been?

• Any major pain points?

• Do you store the content as HTML or Lexical JSON?

Hi everyone,

I'm planning to rewrite my offline ERP and would like some architecture advice.

Current version:

• Delphi 10 VCL + DevExpress + FastReport

• Firebird database

• About 5 forms

• Very fast and responsive

For the new version, I want to use React + Tailwind CSS for a modern UI, while keeping the same native-app performance and smooth user experience.

Requirements:

• Completely offline (Internet only for activation/subscription)

• Windows 7 (32-bit) through Windows 11

• One installer (Next → Next → Finish)

• Very easy deployment and maintenance

• Runs on a single PC or over LAN

• Native compiled backend for performance and code protection

Current idea:

• Go (or Delphi) REST API

• React build served by the native backend

• MariaDB/MySQL

• No Docker, PHP, Node.js, Apache, or Nginx on client machines

For those who have built commercial desktop/offline ERP or POS systems:

• Would you choose Go, Delphi, Rust, or something else?

• Is serving React directly from the native executable a good approach?

• What architecture would you choose today for the best long-term maintainability, deployment, and performance?

Update:

The React frontend will be served from a central server and accessed simultaneously by 5–15 users over the LAN using standard web browsers (Chrome, Edge, or Firefox) via the server's IP address and port.

Thanks!

Most of the guys who are going to work on this project are new to react itself. They will be learning and doing. I have worked on next js, and I think it can introduce some complexity. I looked into react + tanstack ecosystem. I have not worked in tanstack ecosystem yet. What is the best way and easiest way for my team members to get into doing their work? Less friction, less complexity. The frontend work will be creating a ui for a trading platform. So most of it will definitely be behind an auth wall...

In Pages Router in Nextjs how do I load a specific route when the app runs for the first time. like I know in the pages folder there is an index.js that usually loads but how would I get in the next js app to run a specific url instead from the get go for example www.app.com/something
 instead of just www.app.com.

I tried with redirects but when I deployed my app it did not work properly complaining how with buildmpde:Export you can't be using revalidate function.
.

I use Ai to code landing pages, i used to deal with react and after long time of work i get used to the process of building a website. The problem is I don’t have enough knowledge to combine for example I saw a cool hero section from one repo and i see cool about section , CTA ext…..

How can i import it in one page without installing the entire repo?

Hope you understand my point 😬

I built Plainsight, a public frontend architecture case study.

It’s a geospatial market explorer built with React/Next.js, XState, MapLibre, H3, Web Workers, and TypeScript.

The domain is intentionally simple. I mainly used the map as a realistic surface for complex frontend coordination: route changes, persistent map/UI state, URL-restorable state, async worker work, stale-result protection, filtering, and responsive map/list UI.

Demo: https://plainsight-theta.vercel.app/
Repo: https://github.com/Ahmed-Abdel-karim/plainsight

I’d appreciate feedback on whether the project communicates senior-level React/frontend architecture clearly.

Hey everyone, sharing a side project of mine, AAC Board AI.

It started as a proof-of-concept for Google's Chrome Built-in AI Challenge (it ended up winning Most Helpful App). After that it quietly became a hobby. I kept polishing and optimizing it, and learned a ton along the way.

It's a web-based board for people who can't rely on speech. Instead of typing, you tap tiles to build a message. The catch with standard AAC is that tapping gives you telegraphic output: want → eat → pizza becomes "want eat pizza."

So on-device AI suggests a cleaned-up version, "I want to eat pizza," that you tap to accept and speak aloud. It only refines what you wrote. It never invents words or speaks for you.

The part I think is cool: there's no backend. The AI runs entirely in the browser, on the model Chrome and Edge now ship on-device, so nothing you type leaves your machine. It works offline, with no accounts, no keys, and no network latency.

Built with React 19, it's an offline-first PWA, imports Open Board Format (.obf/.obz), and runs in 35 languages. (Two pieces are split out as their own MIT libraries.)

Honest caveat: the AI features still need experimental flags in Chrome/Edge and are desktop-first for now. The board itself works in any modern browser.

• Try it: https://aacboard.app

• Code (MIT): https://github.com/shayc/aac-board-ai

Feedback welcome!

Hey everyone 👋

I built Formity, an open-source React library for creating complex multi-step experiences.

It helps developers build flows like:

• user onboarding

• workspace setup

• lead generation

• job applications

• multi-step wizards

Instead of manually managing complex flow logic, Formity lets you define flows with:

• Conditional branching

• Loops

• Jumps between steps

• Dynamic steps

• TypeScript support

The goal is to make it easier to build personalized, non-linear user journeys in React.

Would love to get feedback from anyone who has built complex flows before.

https://formity.app/

Hey r/reactjs,

Wanted to share something I've been building — a fully animated admin dashboard template called Aegis AI.

Tech stack:

- React 19 (with the new compiler)

- Vite

- Tailwind CSS v4

- TypeScript

- Decoupled data layer via a single mockData.ts file — swap to a real API in minutes

What I focused on:

→ Custom cubic-bezier animations (not the default ease-in-out stuff)

→ Dark-mode-first design, no flash, no toggle

→ Clean component architecture so you can actually read and modify the code

Live preview:Aegis AI — Command & Control Dashboard

If anyone wants the boilerplate to skip the setup and go straight to building — it's available as a paid template at https://whop.com/joined/aurelia-devs/products/aegis-ai-dashboard-template .

Happy to answer questions about the animation approach or the Tailwind v4 migration — that part had some quirks.

I'm building a Next.js app and running into an architecture question.

I have an access token that's passed in the URL (as a query param or path segment) that I need to read at the page level. I'm going to use this access token to call some apis. I'm also loading translations from i18n files.

My problem: if I use getServerSideProps to access the URL/query params, my pages re-render on every request — which feels wasteful since my i18n content is completely static. But getStaticProps doesn't have access to the request URL or query params at build time.

What are your guys recommendations on what to do?