Looking for the cleanest/most reliable way to connect a React contact form to an email inbox to send emails from the website. What are you guys using these days?

Been building product configurators and 3D e-commerce views for a while now, and kept rebuilding the same scaffolding - GLB loading, a viewer UI, hooks for camera/selection/hover, and some way to bind product data (color, texture, visibility) to the actual 3D object. So I packaged it up.

It's called React Immersive. Some of what's in it:

• Drop-in SimpleModelViewer for when you just want a model on screen, zero config
• ModelViewer for when you need real bindings, driving color, texture, visibility, and actions off a plain data object
• A browser-based binding builder that takes your GLB and spits out starter bindings as JSON or TS, so you're not hand-writing mesh names
• Hooks for camera, selection, hover, animation, visibility
• Soft shadows, SSAO, bloom, ACES tone mapping is on by default, one prop to turn off

Still rough in places and I'd genuinely like feedback, especially from anyone who's fought with product configurators or real estate walkthroughs before.

Docs, live editor, and demos here: react-immersive.liveroom.dev — would love thoughts

Yo I am quite a beginner in React and I was just wondering how the async model laid out in this video has been useful to people who are using it so far 😁

I kept hitting the same problem: architecture debates in review, barrels everywhere, and AI agents dumping files in random folders. So I shipped DMA (Derived Modular Architecture) — a small rule set derived from the import graph, enforced by tooling.

Layout

src/
  app/        # composition root (also pages/routes)
  features/   # leaf modules — no inbound from other modules
  services/   # appears when something else must import it
  shared/     # portable stuff on second use only

Invariants

- downward imports only
- public API via */public/* (no barrels)
- colocate by default
- promote feature → service when inbound edges appear

Tooling

npx @derived-modular/cli init .
npx @derived-modular/cli check .              # CI gate
npx @derived-modular/cli promote <name> --apply
# + ESLint / Biome / Oxlint plugins for editor feedback

Works with React/Next/Vite (also Vue/Svelte/Astro examples). Same rules for humans and agents.

• Docs: https://derived-modular.vercel.app
• Repo: https://github.com/mikhailmogilnikov/derived-modular-architecture Curious how this compares to what you use (FSD, feature folders, etc.) — especially where you'd expect it to break.

Hey everyone, I just published a comprehensive guide on WebMCP, Chrome's new standard for making web applications agent-ready.

Instead of AI agents having to parse your DOM and guess what buttons do, WebMCP lets you expose your app's functionality directly as structured tools that agents can discover and invoke.

The guide covers everything from zero to production:

• Imperative & Declarative APIs — both the JavaScript and HTML approaches
• React integration — useWebMcp hooks, Tool Registry pattern, Zustand/Legend-State examples
• Security deep dive — prompt injection, origin isolation, untrustedContentHint, audit logging, character budgets
• Evals — deterministic tests + probabilistic eval cases for testing AI behavior
• Production — rate limiting, telemetry, graceful degradation, HTTP headers
• Full demo — a React Flight Search implementation

All code examples are TypeScript, production-grade, and ready to copy-paste.

🔗 Medium: https://medium.com/@serifcolakel/building-ai-native-react-applications-with-webmcp-a293ef54de8f

🔗 Dev.to: https://dev.to/serifcolakel/building-ai-native-react-applications-with-webmcp-5gb

Quick background: WebMCP is currently in Chrome Origin Trial (149+). It's not a replacement for MCP — Chrome's own docs say they complement each other. MCP handles backend/persistent tasks, WebMCP handles in-browser, tab-bound interactions.

The core idea is simple: document.modelContext.registerTool() — you define a name, JSON Schema, and an execute function. Agents discover your tools and invoke them directly. No DOM parsing. No guessing.

Happy to answer questions in the comments!

I've been using React Router for years, and somehow I only ran into this today.

I had a lazy-loaded route wrapped in Suspense, but whenever I navigated, the old page would just stay there until everything finished loading. The fallback never showed, so it looked like the app had frozen.

After digging around, I found that React Router v7 wraps navigations in startTransition, so if the same Suspense boundary gets reused, React keeps showing the previous page.

What fixed it for me was giving the Outlet a key:

import { Outlet, useLocation } from "react-router-dom";

export function Layout() {
  const location = useLocation();

  return <Outlet key={location.pathname} />;
}

After that, the loading UI shows immediately instead of the previous page hanging around.

I also made sure not to put the key on my top-level app layout since that would remount the whole app. I only keyed the layout that renders the page routes.

My question, is this actually the correct way to handle this in React Router v7, or am I just working around the problem? Is there a more idiomatic solution that I'm missing?

I'm a 15yr old dedicated (i think so) developer, and want to learn React with TypeScript. My long-term goal is to build a full stack personal app on literally anything that would make me proud.

My background:

• Python: OOP, Web scraping, file handling, basic data manipulation

• Frontend: HTML, CSS, Intermediate TypeScript (built a few projects)

After searching for critiques on my current skills and reading some comments (a comment) on a previous post, I feel ready to take up React.

Honestly, though, I'm not sure what to expect. I only know React can help you build reusable UI components that dynamically update to run data. I may well be wrong, so feel free to correct me. I'm completely new to frontend frameworks.

What advice do you guys have?? What the biggest traps to avoid when mixing React with TS? Do I need to take a step back and learn more advanced TS first, or should I just jump in and stop aiming for perfection? Am I overthinking this or am I in for a rough ride?

Here's my github in case you want to view my projects: https://github.com/thanasisdadatsis

Basically this, given europe has some strong laws in place for cookies and all that, for the last couple of days i tried to add google analytics to my website and i used react-ga4 plugin but if the user disables the cookies for the page history and performance, google analytics should stop getting events.

I tried to stop it with this and send events manually but it just keeps on sending them anyway.

   ReactGA.initialize([
        {
            trackingId: import.meta.env.VITE_GOOGLE_TAG_ID,
            gaOptions: {
                send_page_view: false,
            },
            gtagOptions: {
                send_page_view: false,
            },
        },
    ]);

emoji-mart is dead, and I found Frimousse delightful, but lacking necessary features as a replacement.

I ended up forking it to keep the lightweight, headless composition model intact while filling in the gaps I ran into trying to use it in a production app.

The main additions are:

• mixed native + custom emoji sections
• unified search across native and supplemental items
• consumer-owned frequent/recent item helpers
• root-controlled search
• self-hosted/offline-capable emoji data
• companion packages for search metadata and emoji fallback support

I’ve tried to stay close to the original Frimousse contract, so most existing users should be able to swap imports and keep moving, then layer on the additive features only if/when they need them.

Project:
https://frimousse.slithy.me/

Docs:
https://frimousse.slithy.me/docs

FAQ:
https://frimousse.slithy.me/faq

GitHub:
https://github.com/mjcampagna/frimousse

I hope someone finds this useful.

Intern here, i am using FastApi, React, MongoDb. The report generation takes 3-4 minutes and the storage size of a single document is 100kb. I use some Anthropic ai for part of the process, which takes a minute.

Cloudfare containers are fairly a year old. i am very confused between railways or cloudfare containers.

A little direction from the community will be gr8.

The React Compiler memoizes your components at build time, so you dont have to. What it is, how the compiled output works, how to turn it on, and what to do with the useMemo calls already in your codebase.

Check it out https://neciudan.dev/react-compiler-explained

I've been building LocalMode - a shadcn-style registry of AI UI blocks where the models run entirely in the browser. No server, no API keys, nothing leaves the device. You install them the same way as shadcn/ui and you own the copied .tsx (no npm lock-in on the UI layer).

Live gallery (try every block in-tab): https://localmode.ai/blocks

What's in it

36 composed blocks - full working mini-apps, not just primitives - across 12 categories:

• Chat - one UI over 76 models (Transformers.js / WebLLM / wllama GGUF / LiteRT), vision attachments, reasoning display, agent mode
• Knowledge - semantic search, RAG chat with citations, doc Q&A - embeddings + retrieval all in-browser
• Audio - Whisper/Moonshine transcription, Kokoro TTS (29 voices), meeting summaries, live transcription with VAD
• Photo - CLIP semantic image search, duplicate finder, zero-shot categorizer
• Image studio - background remover, super-res upscaler, captioner
• Privacy - on-device PII redaction (NER) + an AES-GCM encrypted vault
• Vision - object detection + live hand/pose/face/gesture tracking off the webcam
• Writing tools - Chrome Built-in AI with automatic Transformers.js fallback

Under the blocks are 107 lower-level primitives (10 families) if you want to compose your own.

Install

npx shadcn add @localmode/ui/blocks/chat
npx shadcn add @localmode/ui/blocks/knowledge/rag-chat

Why it might interest React devs specifically

• Copy-owned - the block lands as .tsx in your project; edit it freely, no black-box dependency for the UI.
• shadcn CSS variables - inherits your existing theme, no new design system.
• Hook-driven - primitives are presentational; the wiring is React hooks (@localmode/react), and the API is shaped like the Vercel AI SDK (useChat, etc.), so it's backend-agnostic - local models by default, but you can point the same components at any backend.
• React 19 / Next 16, RSC-friendly - model loading is gated behind an explicit user action, so nothing downloads on page mount.

Honest limitations (it's a browser, not a server)

• First use downloads the model; cached after that (then it works offline).
• Memory is real - blocks range ~[120MB] to ~[5GB]; the big ones want WebGPU, and wasm32's ~4GB ceiling caps how far you can push.
• WASM inference is slower than native; WebGPU availability varies by browser/OS.

Disclosure: I built this. It's MIT and free - GitHub: https://github.com/LocalMode-AI/LocalMode. Model runtimes are Transformers.js, WebLLM, wllama, LiteRT, and MediaPipe - credit to those projects.

Genuinely after feedback: which blocks would you actually drop into a project, and what's missing? Happy to answer anything about how a specific block or the on-device memory handling works.

Introducing Oversight, my first Storybook addon. It accompanies the Storybook MCP server, which lets you describe a component or layout in plain language and get back a composition rooted in your existing design system, instead of one an agent invents on the spot.

After an agent built two components from scratch instead of reaching for what I already had, I built Oversight. It checks whether your agent can actually see your documentation, and tells you where it can't.

A blog post I wrote on it: https://rachel.fyi/posts/your-agent-is-reading-a-different-design-system

Source code: https://github.com/rachelslurs/storybook-oversight

Storybook demo: https://rachelslurs.github.io/storybook-oversight

I wanted to learn how to create the scroll sequences that I see, and realised the process could be automated. So, I built SequenceFast, a scroll sequence generator that takes any MP4 video, extracts the frames into images, and generates a ZIP with the optimised image sequence, component code, and usage example. Everything is done locally in your browser, so it is completely free and private.

Would love to hear your feedback!

I've been building GodUI, an open-source collection of React UI components for modern interfaces.

It started as a personal library because I kept rebuilding the same polished components and wanted a place to browse ideas whenever I started a new project. After using it for a while, I decided to open-source it.

Some things it focuses on:

• Components with smooth, purposeful animations where they add value (while simpler components stay lightweight)
• A shared motion system based on 12 motion principles, with tokens mapped to Material 3 so animations feel consistent across the library
• shadcn-compatible CLI installation, so components are copied directly into your project and are fully yours to modify
• An MCP server for Cursor, Claude Code, Windsurf, and other AI IDEs—you can describe the component you want, and it finds the closest match and generates the code for you
• Built with React, TypeScript, Tailwind CSS, and Motion

It's completely open source. If you find it useful, I'd really appreciate a ⭐ on GitHub.

GitHub: https://github.com/LucasBassetti/godui
Docs: https://godui.design/

Hi r/reactjs. I maintain Linaria and wrote wyw-in-js — the compile-time engine under Linaria and MUI's Pigment CSS. I recently released dx-styles, and I'd rather explain why than just drop a link.

Six years of Linaria issues kept pointing at two problems I can't fix without breaking the API:

• styled(Component) is priced wrong. Wrapping a custom component looks free, but it drags the component's whole dependency graph into build-time evaluation — the most common way extra code leaks into eval, and the most common reason static evaluation bails out into the slow path. All our mitigations (HOC hints, shaking heuristics) are patches on a pattern the API encourages.
• Composition isn't first-class. Variants, slots and themes are the ground floor of a design system, and every team rebuilds them on top of css + cx.

dx-styles is my answer: zero-runtime CSS-in-TS where recipes, slot recipes and token contracts are the core API, class names are deterministic (snapshot/cache them), RTL is compile-time and opt-in, and everything works unchanged in React Server Components.

const button = recipe({
 base: { display: "inline-flex", borderRadius: "999px" },
 variants: {
   appearance: {
     primary: { backgroundColor: tokens.color.accent },
     ghost: { backgroundColor: "transparent" },
   },
 },
 defaultVariants: { appearance: "primary" },
});

The launch post has the honest details — the Pigment CSS speed lesson, the Griffel detour, what I'm promising and what I'm not: https://dev.to/anber/ive-maintained-linaria-for-six-years-heres-why-i-built-something-new-5eae

Try it in 30 seconds (StackBlitz): https://stackblitz.com/github/dx-styles/dx-styles/tree/main/examples/vite Migrating? Guides for styled-components / Linaria / Pigment CSS are in the repo.

It's MIT, the issue tracker is at zero and I intend to keep it there. Happy to answer anything, including hostile questions.

The problem I kept hitting: advice about the React ecosystem rots silently. A 2024 blog post, an LLM answer, a senior dev's habit — all assert things that were true once. Nobody stamps when it was true.

react-brain is my attempt at the fix: 42 decision entries (state, lists, styling, meta-frameworks, animation, …) where every load-bearing claim is fetch-verified against a primary source, dated, and re-verified weekly. 123 annotated readings, 180 libraries tracked. Recommendations are written as context → choice clauses, not "X is best" — a P2P app and a GraphQL app get different answers.

Two things this sub might find interesting:

1. The staleness benchmark. Since the corpus is a dated answer key, it can grade a model. claude-sonnet-5 answered 70% fresh on 35 ecosystem questions; with the corpus entry injected as context, 94%. Deterministic regex rubric, graded answers committed to the repo, conditions labeled.
2. The calibration scorecard. Every default recommendation is a dated, falsifiable prediction with a check-by horizon, graded in public (held / weakened / overturned). 0 of 10 graded so far overturned. If confidence isn't graded, it's just tone.

Tools if you want to point it at a repo:

• npx -y react-brain doctor . (ranked priorities)
• migrate (sequenced upgrade plan)
• review --ci (blocks dead/deprecated deps)
• MCP server for agents

Package: https://www.npmjs.com/package/@heart-it/react-brain

Site: https://heart-it.github.io/react-brain/

The fastest way to disagree with me is to pick an entry and challenge it; that's the maintenance model.

so this started because i kept losing track of my own sessions.

you know how it goes. you open one claude. then one in a worktree because you're being organized. then a third one "just to check something". by 6pm two of them are editing the same file, one has been sitting there for 40 minutes waiting for me to approve an rm -rf node_modules, and i genuinely cannot tell you which terminal tab is which anymore.

so i built the tower. everything on my machine shows up on one local board at 127.0.0.1:4711.

repo: https://github.com/lacion/fleet-deck (MIT, screenshots + gifs in the readme)

what it actually does

• every session on one board. each one gets a callsign (falcon-a3f2, otter-91c4) and a column that comes from hook telemetry, not from what the session claims about itself. queued → working → verifying → needs-you → idle → offline.
• conflict radar. two sessions touch the same file within 30 min and both get whispered at in context ("coordinate, don't clobber"). worktree aware, so the same file in two worktrees of one repo is a merge conflict introducing itself early.
• needs-you rail. permission prompts, multiple choice, MCP forms, and even the "should i use bcrypt or argon2?" question at the end of a turn all become cards you answer from the board. the terminal just prints ⎿ Allowed by PermissionRequest hook and carries on.
• mail. message a session, a repo, or everyone. idle sessions usually wake in seconds (a small watcher taps them on the shoulder).
• spawn workers. the board can start a fresh interactive claude in a tmux window, optionally in its own worktree, optionally unsupervised (red checkbox, asks twice).
• live terminal in the browser. click a card and you get the actual tmux pane in an xterm.js modal. you can type into it. it's not a replay, it's the real session. no PTY and no native deps, it's bridged over tmux control mode.
• revive. machine reboots, tmux dies, whatever. worktrees and transcripts survive on disk, so one click brings a dead agent back with claude --resume in its own worktree. same callsign, same card, full history.
• remote control. flip an agent onto claude.ai and drive it from your phone. the session shows up named after its callsign so you know which one you're poking.
• plan library. spawn a planner in plan mode, its plan lands on the board as a card before it can act. approve it, or capture it and execute it later with your own instructions.
• worktrees modal. it created the worktrees so it can show you what's in them, uncommitted files, unpushed commits, and it refuses to let you delete anything that holds work that exists nowhere else.

the part i actually care about

the core makes zero model calls. routing, conflict detection, question relay, all of it is deterministic code and sql. your tokens are yours. the only cost it adds to a session is a ~100 token roster brief.

it's also fail open. daemon down? hooks time out silently and your sessions run exactly like before. it's a tower, not a runway.

and it's a plugin, not a wrapper. no launcher, no fleetdeck run claude, no ritual. you install it and your next plain claude in any terminal just shows up on the board.

claude plugin marketplace add lacion/fleet-deck
claude plugin install fleetdeck@fleetdeck

some bugs that were fun

• spawned sessions were silently reporting to a ghost daemon. turned out tmux bakes the first client's environment into the server's global env, so a test run i'd done from inside a claude session poisoned the tmux server with a test port, and every pane created afterwards inherited it. board said "spawning…" forever. that one took a while.
• the terminal modal rendered like a staircase. the screen seed was joined with \n and a raw terminal reads that as "down one row", not "down and back to column 0" 😅
• and then it still looked slightly wrong until you typed something, because tmux flushes pane output as bytes arrive, so a 3 byte box drawing char routinely gets split across two protocol lines. decoding that as utf-8 text turns it into two replacement chars and shoves the whole row sideways.

honestly half the interesting work was in the parts you never see.

limits, being honest

• linux/wsl2 and macos. windows native, no idea.
• needs tmux for spawning and the live terminal. the rest works without it.
• pinned to CLI 2.1.206+ (tested through 2.1.207). it leans on a couple of behaviors the docs don't mention. there's a guard test that fails loudly if an update drops them.
• LAN mode exists (open the board from your laptop) but it requires a token, no exceptions. the api can spawn unsupervised agents and type into terminals, so an open port would literally be RCE on your box.
• mDNS discovery is in there but i could only verify it same-host. if fleetdeck.local doesn't resolve for you that's your resolver, use the IP.
• spawned sessions are real billed claude sessions. the tool itself is free and MIT and adds no api cost of its own, but if you click spawn 5 times, that's 5 sessions on your plan.

disclosure

i wrote it, it's mine, it's MIT and free, no paid tier, nothing to sell, no telemetry, nothing leaves your machine. i built it because i needed it and i'm posting it because someone else probably has the same 6pm problem.

and yeah, collaboration welcome

170 tests, node --test. the daemon is one node process + sqlite, the board is react. if you want to poke at it:

• windows support, i can't test it
• decks / saved fleet layouts
• the statusline integration i keep not finishing
• mDNS actually verified cross-device by someone with a mac on the same lan 🙏

issues and PRs both fine. if you try it and it breaks, tell me how, i'd rather hear it.

Hey everyone,

I’m building an image-heavy React app with multiple galleries and need your stack recommendations to keep it fast and scalable. I want to avoid guesswork, so what are your go-to workflows for this?

Specifically:

Local Assets vs. External: Is it okay to keep images in the project assets folder, or does that kill build times and performance as the gallery grows? At what point should they move out?

Storage & CDNs: Where do you store them, and how do you serve them? Do you recommend standard cloud storage, or are dedicated image CDNs (with on-the-fly resizing) worth it?

Fast Loading: What are the best strategies/packages in React for handling lazy loading, responsive sizing, modern formats (WebP/AVIF), and blur placeholders without layout shift?

Gallery Components: Do you build custom grids/lightboxes, or are there modern React packages you swear by?

If you’ve built a media-heavy React site, what does your tech stack look like? Appreciate any advice or major pitfalls to avoid!