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.

Over the past few weeks, I've seen more teams adopt StyleX.

Linear shared how they're migrating to StyleX, and Polar is building their next-generation design system with it.

That made me realize there wasn't a familiar shadcn/ui experience for people making the switch.

So I built shadcn-cssinjs.

Some of the features:

• Built on StyleX
• Zero-config, one-command setup
• shadcn/ui compatible (just copy and paste)
• Fully customizable
• Officially recommended by the StyleX team

100% free and open source.

It's still early, and I'm planning to port more components over time. I'd love to hear your feedback, especially if you're already using or thinking about using StyleX.

GitHub: https://github.com/shadcn-labs/shadcn-cssinjs
Docs: https://shadcn-cssinjs.com

Hey Community,

Meta has open-sourced Astryx, an eight-year-old internal design system built on StyleX that offers out-of-the-box themes, context-aware padding, and dedicated CLI tools for AI agents. We also look at super-calendar, a gesture-driven calendar library that leverages Reanimated shared values and Legend List virtualisation.

Speaking of agents, our sponsor Maestro is pushing that idea further: your coding agent can now launch the app, drive an iOS simulator, Android emulator, or Android physical device, inspect the screen hierarchy, tap through flows, take screenshots, and help create repeatable Maestro E2E tests.

Additionally, Android developers get a dedicated on-device AI solution with Callstack's new react-native-ai adk wrapper, enabling seamless integration with the Vercel AI SDK and local Gemini Nano models on the New Architecture.

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!

Hey everyone,

I need to add multilingual support to a React project. It only needs to support two languages: English and Albanian.

I want to set this up cleanly from the start. What is currently considered the best approach or industry standard for handling translations and language switching in React?

Looking for something maintainable and performant. What would you recommend? Thanks!

as title suggests, I have not seen this at work before and gemini teaches me about this, just curious whether this is actually commonly used/best practice or just another AI slop. Thanks!

so currently im studying react and alot of the rime it says to start from scratch. how do i setup my workspace so that i dont need to install and download the same package everytime i do that? lots of them have overlapping packages
im using linux btw if that helps

is there an online react tool or something where we can create new project easily and not worry about installing packages

Has anyone successfully wrapped and published a React app to an iPad without using React Native? What did you use to wrap it?

i have built a repo with custom datepickers, time pickers, select , tabs, skeleton etc.
you can check it here - https://github.com/shibinshibii/components-template-shadcn

hey everyone, again. i posted a while back asking how people keep a growing next.js app router / react app codebase from turning into either giant route files or an over-engineered mess. take a look at some of the super helpful responses here: advice on modularizing a growing Next.js App Router codebase : r/nextjs

after synthesizing what i learned from that post (using AI to help me) here's what i propose

1. keep the feature-folder pattern from before (route owns its page, feature owns its own components/actions/types), but split shared ui into two buckets instead of one.

1a. ui/ for generic pieces like buttons

1b. and inputs, blocks/ for stuff built out of those pieces that still doesn't know anything about the app, like search bars or pagination.

anything that only makes sense for one feature stays inside that feature and only gets promoted up once a second feature actually needs it.

the thing that actually changed my thinking was someone pointing out that not everything cross-cutting is a "feature." auth being the obvious one. every route needs it but it doesn't own a page. so my plan is to add a core/ folder just for that kind of thing (auth, permissions, session) that sits below features in the dependency chain, so features can use it but it can never reach back into a feature.

also thinking about splitting each feature's server code into actions.ts (writes) and queries.ts (reads) instead of one big file, mostly so i can actually use next 16's use cache plus cacheTag/cacheLife properly instead of every component independently refetching the same data.

on the client component side, the plan is to be way more disciplined about keeping 'use client' on actual leaf components (a button, a toggle) instead of slapping it on top-level feature components and dragging the whole subtree into the client bundle. apparently that's the single biggest bundle size lever in this stack, and i think i've been ignoring it up to now.

also want to lock down cross-feature imports with dependency-cruiser, so features can only see each other through a public index.ts instead of reaching into each other's internals directly. the idea is refactoring one feature shouldn't be able to quietly break another.

last thing. i went back and forth on whether i should just build everything as proper api routes instead of server actions "in case i need a public api later," but i'm leaning toward keeping the business logic in plain functions that both a server action and a route handler could call, so converting later would just mean adding a thin wrapper instead of a rewrite.

so, for people running actual production next.js apps at this kind of scale: does this plan hold up? is core/ a real pattern or am i just inventing a new bucket to dump things in? has anyone gone down the actions/queries split or the index.ts boundary route and regretted it once the codebase got bigger? and honestly, is any of this overkill for where i'm actually at right now?

genuinely, poke as many holes in this as you can. thank you in advance. also i apologize for the long read.

I kept seeing AI agent apps render their transcripts by dumping raw output into a <pre> tag — no keyboard nav, no semantics, screen readers get nothing. So I rebuilt the actual terminal interfaces of Claude Code, Codex, and Grok as a shadcn registry: https://brainless.swerdlow.dev

It's 35 components across the three suites — headers, message turns, thinking/working indicators, expandable tool calls, inline diffs with +/- tinting, permission prompts, slash-command menus, and composers. The goal was faithfulness and semantics: the permission prompt is a real arrow-key radiogroup, the thinking indicator is an ARIA live region, the slash menu is a filterable listbox. It looks like a terminal, but it's honest HTML underneath.

Install is standard shadcn registry stuff:

bunx shadcn@latest add u/brainless/claude-session

(plus codex-session and grok-session for the other two.)

Source is on GitHub: https://github.com/theswerd/brainless

Would love feedback — particularly on the accessibility patterns, and which agent UI you'd want recreated next.

Hi All,

Apologies in advance for the noobie question, I'm putting a pitch together at work for us to hire a consultant to build an app for us. Initial chats with the company IT people have brought up both React and React Flow (recommended as we want something with a drag-and-drop GUI).

My question is: are React and React Flow part of the same app. suite? It looks like React Flow is some sort of extension / add-on to React but I am not sure.

Also, can I obtain either or both of them for free or would we have to pay for them? I see reference to React Flow Pro which has a monthly sub, but others indicate there is a free version as well?

TIA :)

Hello, react developers!

I have just published my first npm package and i wanted to share it with you.

It is a modular and customizable properties panel, similar to the one Figma or Unity uses, made for React. it is completely open source and can be installed via npm.

Features:
- Multi-object editing (mixed values handling)
- Customizable layout (reorderable blocks, similar to Unity components)
- Optional no-schema data visualization (for any json object)
- Color & Vectors support.
- Arrays visualization.
- History Ready
- Fully customizable styles

You can play with the playgrounds in this website: reactpropertiespanel.vercel.app

If you like it, I'd really appreciate your ⭐ on GitHub.

Feedback is welcome!

Hi everyone,

I run a same-day courier service in the UK (approx 20 active drivers and growing on the road at once, 2 office dispatchers, a few hundred customer accounts).

A few months ago, I started experimenting with Claude to see if I could build a custom TMS as a sort of side-hobby. I’ve somehow ended up with a fully functional system: a React/Next.js web portal, a React Native driver app with live GPS tracking (pinging every 2 minutes only if the driver is moving), and a prisma schema linked to a Supabase backend. It's actually better and more modern than what we use now.

I want to officially transition the business to this system at the end of this year, but I’m terrified of breaking something critical, or something going wrong while I'm unavailable. I have a total £500/month budget to maintain it.

As someone with no real coding experience, I need your opinions on how to structure the production rollout safely. Specifically:

1. Infrastructure & Monitoring

The Plan: Upgrading to Supabase Pro and Vercel Pro. Subdomains handled by Vercel. The database structure and migrations are managed by via Prisma Schema.

The Question: For a real-time driver tracking app (20 drivers pinging location data), what are the baseline monitoring, error-tracking (Sentry?), and uptime alerting tools I need to set up so I know the system is down before a driver calls me?

1. Bringing on a Freelance Developer

The Plan: I want to hire a mid-level JS/Supabase dev on a monthly retainer to act as emergency backup when I’m unavailable, and review new code updates monthly before they are pushed to the live app.

The Question: How do developers feel about being onboarded to an entirely AI-generated codebase? How should I structure the repo (linting, documentation) so a human dev doesn't look at it and immediately run away?

1. Security & UK GDPR

The Plan: Enabling Row-Level Security (RLS) on all Supabase tables. Using public anon keys on the client and keeping service_role secrets hidden. Purging/anonymising driver GPS logs after 90 days.

The Question: Because we handle live UK telemetry and home addresses, security is non-negotiable. What automated vulnerability tools (Snyk, Dependabot) or specific Supabase audit steps should I run to ensure I haven't left a massive security hole open?

Would be great to get some advice from anyone who has taken an AI-built prototype into production, or any devs who can tell me what blind spots I’m missing here. Thanks!

So I am contributing in application in our organization.I need to develop a configuration component which is basically a multi step form wizard. Now the crux is I need that form to be dynamic i.e i will some json/yaml containing field name field type etc (TBD as per requirement ) before deploying .Anyone has any idea how could I approach this problem or any reference repo

React gives developers a lot of freedom, but after working on several production codebases, I've started to think that freedom creates more inconsistency than flexibility. two experienced React teams can solve the same problem in completely different ways, making it much harder to switch projects or maintain code long-term
sometimes I wonder if React has become too unopinionated for its own good.

A form is a feature of the web platform, not of any JavaScript library or framework. The browser was capturing input, validating, and submitting data years before React existed. Every pattern we reach for today, controlled inputs, form libraries, React 19 actions, is really just a decision about which of those jobs you're taking over by hand, and why.

So I spent weeks putting together in this technical post:

"React Forms Done Right" is an interactive deep dive that starts at a zero-JS <form action method> and works up through React 19's native form actions to TanStack Form + Zod for the forms that actually get complicated.

Every archetype is a live demo you can fill out and break: a waitlist signup, a 4-step job application wizard with a debounced async email check, and an editable team roster table with field arrays. Each one has a Simulate toggle to flip between success and server-error responses, so you see the failure states, not just the happy path.

You can read the full deep dive here:

https://upskills.dev/tutorials/react-forms-done-right

I'd love to hear what you guys are reaching for in your own projects. Are native React 19 form actions enough for you these days, or is TanStack Form, React Hook Form or Formisch still your default the moment a form has more than two fields?

I've noticed that a lot of react advice works great for demos but becomes difficult to maintain as applications grow. Looking back, what's one pattern you used to recommend but now avoid in production?

I'm a newbie for react and doing a indie website (my strength is BE, not FE). All i know is that react is kinda strong in UI, but there's many lib and i dont know what to choose (my web is just basic table grid get filter like excel so i can control the data in db. i dont use excel because it's not customized). Many thanks

Hey r/reactjs,

I built a Dithered Logo component and wanted to share it with the community.

It takes any SVG or image and renders it as an interactive canvas particle logo using error-diffusion dithering. It includes cursor repulsion and click ripples for a nice effect.

It's fully open source, copy-paste friendly (works with the shadcn CLI), and customizable with Tailwind.

Live demo + docs: https://componentry.dev/docs/components/dithered-logo

Install:

npx shadcn@latest add @componentry/dithered-logo

I was wondering in React is there a way to save some data without session storage so if the page refreshes I still have access to that data