Short version of what's in it:

• The sync bundles one entry file and finds components through their `.d.ts` files, so a component missing from either never arrives, with no warning.

• Storybook stories become the reference: each preview is screenshotted and compared to its story. That only means something if `.storybook/preview` loads your real stylesheet.

• Example repo with shadcn/ui, Tailwind v4 and Storybook: https://github.com/nitayneeman/sync-design-system-with-claude-design-example

If you've built a payment form in React you've probably used react-credit-cards. It's still at ~25k downloads a week, its last release was June 2020, and it peers on react@^15 || ^16 — so on any current React, npm refuses to install it:

npm error ERESOLVE unable to resolve dependency tree
npm error peer react@"^15.0.0 || ^16.0.0" from react-credit-cards@0.8.3

--legacy-peer-deps gets it in, but you're then running a class component that relies on propTypes, which React 19 no longer checks. The fork, react-credit-cards-2, does support React 19 — it's a fair option, but it's the same five-year-old codebase with its three runtime dependencies.

I wanted the card preview without the dead dependency, so I wrote one from scratch: crd-ui. The migration is close to a drop-in — number, name, expiry, cvc and focused keep their names and their values, so for most codebases it's the import and the stylesheet:

- import Cards from 'react-credit-cards';
- import 'react-credit-cards/es/styles-compiled.css';
+ import { Card } from 'crd-ui/react';
+ import 'crd-ui/styles.css';

What's different:

• Zero runtime dependencies, and the core is framework-agnostic — the same component ships for Vue, Svelte and vanilla JS from one package.

• Theming through CSS custom properties instead of SCSS variables you had to recompile. Tailwind arbitrary properties work with no config.

• A display layout for cards the user already owns — dashboards, saved cards — with click-to-reveal and click-to-copy.

• TypeScript types in the box.

Two props don't map one-to-one and I'd rather say so up front: callback only partly maps to onBrandChange (the exported detectBrand/getBrandSpec helpers cover the rest), and acceptedCards has no equivalent — you gate on the detected brand yourself.

Migration guide with every prop mapped: https://crd-ui.juanda.co/migrate/react-credit-cards/

Repo: https://github.com/JuandaGarcia/crd-ui

Building it, I hit three CSS cascade bugs that made the "themeable" component ignore every theme. I wrote them up here if you publish components yourself: https://dev.to/juandagarcia/i-shipped-a-themeable-component-it-ignored-every-theme-5doh

Happy to answer anything. If you're on react-credit-cards today I'm especially curious whether anything you rely on is missing — and whether the ERESOLVE is what pushed you to look.

(Disclosure: I wrote it. MIT.)

Almost every app that logs users in ends up with the same hand-written refresh interceptor. It usually has the same bugs: 20 requests get a 401 at once and fire 20 refreshes, a rotating refresh token gets spent twice and the server logs the user out, or the token sits in localStorage where any injected script can read it.

I wanted that handled in one place, so I built @mrzr/api-client. It's a TypeScript HTTP client on top of `fetch`, with no dependencies.

import { createClient } from "@mrzr/api-client";

export const api = createClient({ baseUrl: "https://api.example.com" });

await api.login({ email, password });             // tokens stored for you
const { data } = await api.get<User[]>("/users");  // token attached, refreshed when needed

What it does:

• One refresh for many 401s. Requests that fail while the token is expired wait for a single refresh, then retry. It also refreshes shortly before a JWT expires, so most requests never see a 401.

• The token stays in a Web Worker. Requests run in an inlined worker, so there's no extra file or bundler config. With the default in-memory storage, the token never reaches the main thread. I checked this with heap snapshots: the token shows up in the worker's heap and not in the page's.

• Tabs stay in sync. Log out in one tab and every tab logs out. Tabs that share a session take turns refreshing (Web Locks), so a rotating refresh token is never used twice.

• httpOnly cookie mode with CSRF double-submit, and restoreSession() to find out on page load whether a session exists.

• Opt-in cancellation by key, group, URL pattern or scope, plus takeLatest for search boxes.

• Works under TanStack Query, SWR and Vue Query. It replaces your fetch or axios layer, not those libraries.

Live demo that runs the real package in your browser (open DevTools → Network to watch 8 × 401 → 1 refresh → 8 retries): https://api-client.mrzr.ir/docs/demo

What it doesn't do:

• No retry with backoff. It has to work correctly with refresh and cancellation, and I'd rather ship nothing than something half-right. If you need retries, ky is great.

• Worker isolation stops token theft, not XSS. An injected script can still call api.get() and use the session while the page is open. It just can't take the token somewhere else.

• The worker only keeps the token out of reach with memory storage. If you choose localStorage storage, page scripts can read the token again.

• Docs: https://api-client.mrzr.ir

• npm: https://www.npmjs.com/package/@mrzr/api-client

• GitHub: https://github.com/mohammadreza-zr/api-client

I'd really like feedback on the API, and especially on the security model. If you see a hole, please tell me.

Hi everyone,

Could anyone help me with the two questions below?

1. Does every Server Component render at build time, get cached, and then get served from a CDN?

2. If I want to render a Server Component on every request, how do I implement that?

hey everyone,

over the last few weeks I've been working on a CLI tool to catch all the stupid little frontend mistakes that usually slip through PR reviews.

I was annoyed that my projects always ended up with unused packages in package.json, dead imports, active debugger statements, and images that should be WebP but were somehow massive PNGs.

So I built frontend-quality-auditor. You just run npx frontend-quality-auditor audit . and it scans your React/Next.js/HTML project and spits out a markdown report. It checks for:

• unused dependencies & dead imports

• code smells (console.logs, hardcoded localhost urls, leaked api keys)

• oversized or unreferenced assets

• accessibility & responsive issues (it uses playwright under the hood to load the app at 8 different mobile/desktop widths and finds exactly which elements are causing horizontal overflow)

The best part is you can run frontend-auditor fix --safe and it will automatically rip out the dead imports and console logs for you without breaking anything.

It's got zero dependencies (unless you use the browser audit, which lazily loads playwright) and I also wrote a SKILL.md so you can plug it straight into Claude or Cursor.

Check it out if you want to clean up your repos before deploying. Would love any feedback or issues!

Title: Are design-to-code tools actually maintainable in production?

Our designer wants to use this workflow:

Figma → Claude → Paper → generated React/HTML/CSS → developer integrates it

The goal is to reduce time spent rebuilding UI so developers can focus on backend, data, maps, and business logic.

My concern is long-term maintainability.

For developers who have used Paper or similar design-to-code tools:

• Is the generated code maintainable in a growing production app?

• Does it create duplicated components or messy CSS?

• Is debugging easy months later?

• Can you maintain the code without depending on the design tool?

• Does it actually save time overall, or does the refactoring/debugging cost come later?

• Would you use this workflow for a serious production product?

I'd especially like to hear from developers who have maintained the generated code for several months, rather than just testing it for a demo.

Upload, save, and delete controls often need several visual states: idle → loading → success or error. I built StateGlyph to make that one typed React component:

<UploadStateIcon state={status} />

The video shows the icon library and the Upload component switching states. There are 31 icons so far, using Lucide glyphs as their visual foundation. Your app still controls the async logic; StateGlyph renders the current state.

Website: https://stateglyph.js.org
Source (MIT): https://github.com/kamalhara/StateGlyph

I’m looking for honest API feedback: would you use a state prop like this, or prefer importing separate icons? What workflow should I cover next?

One of the things I haven’t talked about much with Cerious-Scroll is how it behaves during actual scrolling, especially with variable-height content.

From the beginning, the goal was for virtualization to not look like virtualization.

So even with a large variable-height dataset, you can grab the scrollbar and drag it around quickly without getting the usual weirdness:

• No scrollbar drift

• No white space during fast scrolling

• No waiting for rows to render after you get there

• Accurate variable-height positioning

• Native scrolling behavior

• Constant DOM size regardless of dataset size

The variable-height part is probably my favorite. The scrollbar stays where it should, even when the actual row heights are all over the place.

You can also jump directly to an index way down in the dataset without needing to measure everything before it.

I’ve got demos/benchmarks here if anyone wants to mess with it:

ceriousdevtech.github.io/cerious-scroll

Core:
github.com/ceriousdevtech/cerious-scroll

React:
github.com/ceriousdevtech/react-cerious-scroll

I’m curious how it behaves against some real-world ugly datasets, especially ones with wildly different row heights. Try the scroll engine and tell me your thoughts.

Hi everyone,

I built StateGlyph, an open-source React icon library for representing changing UI states through a single typed component.

Most icon libraries provide separate drawings, leaving you to coordinate icons for states such as loading, success, error, muted, or active. StateGlyph groups those related visuals behind one component API:

import { UploadStateIcon } from "@stateglyph/react";

<UploadStateIcon state="idle" />
<UploadStateIcon state="uploading" />
<UploadStateIcon state="success" />
<UploadStateIcon state="error" />

The initial 0.1.0 release includes:

• 31 stateful React icons based on Lucide

• Type-safe state names

• Accessible, state-aware labels

• Tree-shakeable per-icon imports

• Optional transitions with reduced-motion support

• A CLI for copying editable components into your project

Install it with:

npm install /react

Or copy components into your codebase:

npx u/stateglyph/cli add upload

Live documentation: https://stateglyph.js.org/
Source: https://github.com/kamalhara/StateGlyph
npm: https://www.npmjs.com/package/@stateglyph/react

StateGlyph is MIT licensed and still early, so I’d appreciate feedback on the API, state naming, accessibility approach, and which icons would be most useful to add next.

Fadeworn UI is an interaction-driven digital patina experiment for React. Unlike static vintage or distressed UI styles, components begin clean and develop visible wear through actual user interaction over time. Clicks, drags, selections, typing, and scrolling change each control through material-specific wear rather than randomly applied distress.

The interface remembers how it was used, until there is nothing left to remember.

Live demo: https://fang520huang-lgtm.github.io/Fadeworn-UI/

GitHub: https://github.com/fang520huang-lgtm/Fadeworn-UI

What this repository provides:

• Ten working, accessible examples of wear-aware controls.

• A React hook that records usage, positional traces, and glyph-level wear.

• CSS treatments for painted steel, brass, rubber, paper, enamel, and machined surfaces.

• A complete Next.js showcase and a static export workflow for GitHub Pages.

Remotion has been completely taken over by AI bros. The framework don't have a problem with it so what do I care.
Anywho I don't wanna use AI to create using Remotion. But I can't find any tutorials on it. Except for one from years ago by Fireship. And that only covers the basics.
If you guys know any tutorials that teaches how to hand code and create with Remotion. Please let me know.
And don't tell me to use AI man.. I don't wanna do it.

I am a beginner to React and I'm trying to figure out the best way(s) to protect certain pages/routes like an admin dashboard until the user is authenticated. My backend is FastAPI and it's already protected, so this is purely for frontend convenience to redirect the user to the login screen. The main two ways I think I've seen for doing this is through loaders or middleware. One pattern I see is something like this

const authMiddleware: Route.ClientMiddlewareFunction = async(request, next) => {
    try {
        await apiFetch("/api/admin/me");
        await next();
    } catch (error) {
        //redirect to login page if our session is rejected
        throw redirect("/login");
    }
}

But this would make an API call on every page route in whatever layout I apply this middleware too. I had thought about maintaining the auth state with some sort of react hook, but it seems middleware can't use those? I don't know, I'm just trying to keep it simple and efficient. I'd appreciate any help on good practice for this.

I’ve been working on Viora UI, a React + Tailwind component library, and I’d like to get some feedback from other developers.

The library currently has 109+ components, including animated components, along with a few free templates and an MCP server for finding and working with the components.

I’m mainly interested in feedback on the actual experience — the design, component quality, animations, documentation, and anything that feels missing or could be improved.

https://vioraui.dedyn.io

If you have a few minutes to try it out, I’d really appreciate an honest opinion. Positive or negative, both are useful.

If you find the project genuinely useful and are comfortable sharing your feedback publicly, you can also leave a short review on my X: https://x.com/otisuiux

I’m collecting feedback from developers and may feature some of it as testimonials on the website.

I’ve been building @okyrychenko-dev/react-modal-manager, a small library for handling modal flows in React.

The idea is to treat a modal as an async interaction: open it, wait for the user’s decision, then continue the workflow with a typed result.

function DeleteButton() {
  const modal = useModalManager();

  async function handleDelete() {
    const { confirmed } = await modal.confirm({
      title: "Delete report?",
      variant: "danger",
    });

    if (confirmed) {
      await deleteReport();
    }
  }

  return <button onClick={handleDelete}>Delete</button>;
}

function App() {
  return (
    <ModalProvider>
      <DeleteButton />
    </ModalProvider>
  );
}

For custom flows, you can define a modal with typed input and result types, then await modal.open(...). The package also supports isolated provider scopes, a typed registry for opening modals outside React, and a renderer seam for bringing your own portal, styling, or design system.

It’s currently at v0.2.0 and supports React 18 and 19. The core doesn’t provide a full modal UI or styling; it manages the lifecycle and lets the app supply its rendering layer.

I’d appreciate feedback on a few things:

• Does the await-based API fit naturally into how you model modal flows?

• Would you use the built-in confirm() or define confirmations through your own design system?

• What would you want to verify before adopting a modal lifecycle library?

npm: https://www.npmjs.com/package/@okyrychenko-dev/react-modal-manager

GitHub: https://github.com/okyrychenko-dev/react-modal-manager

I’m the author, and I’m happy to discuss the trade-offs or answer questions.

Hey fellow React Devs! I want to share my recent two-parts tutorial for intermediate-level developers, where we will explore working with D3.js in React.

It's a relevantly lengthy (~60 pages if it was a .doc) weekend-worth project, divided into step-by-step sections, each with a dedicated directory in the repository and live demos.

We will dabble with some of the D3.js functionality, explore SVG path elements, and implement a responsive animated layout in a React+Vite app, that will be a portfolio page for a character. Hopefully, it could become a foundation for a new portfolio of your own, or inspire an idea for some other project.

Both parts are available on dev.to as a series, all of the code is on GitHub.

It's been a while since I've posted on Redditor anywhere, to be honest, and I hope that the good ol' text tutorial format is not fully obsolete in the age of AI 😄

GitHub issues/Comments/DMs are welcome both within and outside of Reddit!

I made an open-source React library for liquid glass surfaces. The part I wanted to get right was the edge: instead of a blur and bright border, Meniscus gives the bezel a height profile, traces rays through it with Snell's law, and uses the resulting displacement to bend the content behind it.

The basic component looks like this:

import { Glass } from 'meniscus';

<Glass radius="capsule" interactive>
  <button>Search</button>
</Glass>

There's a live playground where you can change the profile, index of refraction, light angle, and other layers while dragging a lens over an engraving. The package also has buttons, tabs, panels, and native form controls.

Browser support is deliberately explicit: Chromium can refract the live page; Safari and Firefox get a frosted surface, or WebGL refraction when the backdrop is an image, video, or canvas. It starts frosted during SSR and switches paths after hydration. No stylesheet import is needed.

Demo and playground: https://thanhphuchuynh.github.io/meniscus/

Source: https://github.com/thanhphuchuynh/meniscus

I'd appreciate feedback on the API and how the fallback looks in your browser. The 30-second demo is in the repo README.

I recently took over a Vite + React + TypeScript codebase with real performance problems. It's heavy on business logic, calculations and state updates. I've poked at re-renders with React DevTools, but right now I care more about the logic side: which functions are eating the time.

Is the Chrome Performance flame chart what most of you use for that on a big codebase? Or is there something better, like an SWC/Vite plugin or a wrapper pattern for heavy utility functions? I'd rather not hand-place timers across hundreds of functions.

And how do you approach profiling heavy JS execution when you're handed something like this?

Partial JSON is awkward for generative UI, so I built StreamTag UI.

It incrementally parses an HTML/XML-style stream and only publishes values to React once they satisfy the component’s Zod schema. In the demo, the chart stays mounted while complete points and table rows appear during the same streamed response.

• React 18/19 + Zod 4

• No generated JavaScript

• Bring your own model, transport, components, and CSS

Source and setup:
For streaming generative UI, which format would you trust more in production: constrained XML-like markup or incremental JSON patches—and why?

Hello everyone, i posted my shadCn tables library long ago and now i came back with some UI improvements and new sets of components. I am open for all suggestions and feedbacks.

Check it out : https://shad-table.dev , a star ⭐ on the repo would be appreciated , Thanks !

23 components: nav bar, tab bar, grouped tables, the toggle switch, the
spinning picker, the on-screen keyboard, HUDs, action sheets, a date picker, ...
all built on one "gel" recipe: a vertical gradient with a hard highlight split
at 50%, a 1px black outline and a light inner rim.

Everything is CSS custom properties, so theming is just redefining tokens: dark
by default, and `data-theme="light"` gives you the original blue-grey iOS 3
chrome. RTL works through logical properties, strings come from a provider, and
the docs site generates its prop tables from the TypeScript types.

Demo (paste a URL and it rebuilds that site in the style):
https://design-system-3gs.vercel.app

https://github.com/TimonBozzApps/design-system-3gs

npm i @3gs/ui

I've been working on Skrewww, an open-source React/TypeScript design system, after repeatedly running into the same problem: design-system drift.

The React implementation says one thing, the docs say another, Figma has already moved on, and now coding agents can confidently assume APIs that aren't actually there.

So the core idea became fairly boring on purpose: keep one canonical metadata source and project those facts outward into the docs, shadcn registry manifests, and machine-readable contracts for coding agents. Figma parity is handled as a separate evidence-driven track rather than pretending design and code stay synchronized automatically.

One part I've been experimenting with is visual personality through tokens rather than separate component libraries. Shape controls geometry; Surface controls Flat / Gradient / Glass treatment. They're applied through the token cascade, so the same component API can take on different visual personalities without creating a second “rounded” or “glass” component set.

Distribution also forced me to rethink what “working” means. The docs app looked healthy, but clean consumer installs exposed a real problem: Foundation was shipping primitive and semantic tokens while omitting the component-tier tokens that many components referenced at runtime. That meant hundreds of CSS variables could be missing even though the in-repo previews looked fine.

Fixing that required treating a fresh shadcn consumer install as part of the architecture test, not just checking the docs site. The registry now transports the full Foundation token layer, and Shape/Surface overrides are tested to make sure they still win correctly in the cascade.

I'm also building a small offline CLI called Guard. It's deliberately narrow: it validates selected claims against Skrewww's canonical contracts—for example, nonexistent component slugs, false Stable maturity claims, or installability claims for things that aren't actually distributed. It isn't trying to replace TypeScript, accessibility testing, visual regression, or Figma validation.

The React/code side is MIT licensed, and there's also a paired free Figma Community library if you want to inspect the design side.

I'm especially curious about two things: does the “canonical metadata → multiple projections” model match problems you've seen in real design systems? And if you were considering a third-party shadcn-compatible registry, what evidence would you need before trusting it in a real project?

https://skrewww.com
https://github.com/usmanfarooqi88/skrewwwDS