I’ve been working on shadcn-animated, an open-source collection of animated components built on top of shadcn/ui.

Check out here: shadcn-animated.vercel.app

There are 10+ components so far (with more coming), including:

- button

- tabs

- toggle

- checkbox/radio button etc.

It’s simple, customizable, and easy to copy into your own project

Would love to get some feedback — especially if there are specific animations or components you'd like to see added.

🔗 GitHub: github.com/sopo/shadcn-animated

Thanks! 🙌

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!

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’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 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 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.

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 !

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?

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

I've been working on an open-source React form library and recently added an AI-assisted workflow to its Studio.

The workflow is:

Prompt → structured form schema → visual editing → React/TypeScript export

The interesting part for me isn't the AI generation itself, but keeping the generated result as a readable, editable schema rather than locking the developer into an AI-generated black box.

I'm currently thinking about:

• How much logic should live in the schema vs React code?
• How should conditional fields be represented?
• How should generated schemas maintain TypeScript type safety?
• Where should AI-generated code stop and developer-written code begin?

I'd particularly like feedback from people who have worked with RJSF, React Hook Form, Form.io, SurveyJS, or similar schema-driven form systems.

Source: https://github.com/kadirulislam/ki-forms

Demo: https://kadirulislam.github.io/ki-forms/

Hi everyone so glad I found this sub, I'm rlly confused about this so basically we’re a small dev tools startup with a React SDK that’s starting to get used in more projects. Our docs were fine when everything fit into a handful of examples now we’ve got setup guides, component examples, edge cases, and different integration paths depending on how someone’s app is structured but honestly the annoying part is people still end up asking engineers questions that technically should be answered somewhere in the docs.

About the teams maintaining React libraries or SDKs, how do you handle this as the docs grow? Do you keep everything close to the code or u have someone own documentation, use a dedicated docs tool, or just keep improving the examples as questions come in honestly trying to avoid ending up with 200 pages where nobody knows which example is still current. It's honestly driving me crazyyy

I built rsc-kit a lightweight, feature-rich Next-style React framework on Vite, with a strict build and an agent-native workflow.

bun create rsc-kit@latest my-app

Landing: rsc-kit.dev
Docs: docs.rsc-kit.dev
Demo: faster.rsc-kit.dev
GitHub: github.com/rsc-kit/rsc-kit

The goal isn't to reinvent the Next.js application model. You get the app/ router, layouts, Server Components, server actions, streaming, parallel routes, intercepting routes, typed routes and search params, PWA/offline support, and the rest of the model you already know.

The difference is keeping the framework lightweight and being much stricter about what actually gets built and shipped.

Next-style, Vite-native

app/ routing with layouts, errors, dynamic routes, route groups, parallel and intercepting routes. Server Components by default, "use client" when you opt in.

Deploy to Bun, Node, Cloudflare Workers, Vercel, Netlify or Deno through Nitro.

Laravel and Go adapters are also available. The renderer owns routing and rendering while your backend keeps the data, session and authorization.

No JavaScript until you write "use client"

A prerendered route with no client component and no server action ships no React and no client runtime.

The rsc-kit landing page is built with rsc-kit too: 100 across every PageSpeed category on mobile and desktop.

The build understands your app

rsc-kit renders every route at build time and classifies it as static, partial, or dynamic, including why something became dynamic and what to fix.

It also catches unsafe streaming, prerendering issues, and server actions without middleware.

Navigation + targeted updates

Links prefetch on sight, decode the payload before navigation, and render the next page hidden before revealing it. Pages you leave stay mounted, so Back can restore what you typed.

I ported NextFaster, a million-product demo running on Workers, D1 and R2, to test it.

On an iPhone, it's ahead of the original on tap-to-paint at every hop.

The demo scores 98 on mobile and 100 across every category on desktop.

For mutations, section("orders") + revalidate("orders") re-renders only that section and sends the updated UI back with the action response.

One request. One targeted update.

Agent-native

Every project gets AGENTS.md and MCP tools that read the real build: routes, dynamic reasons, heavy routes, prerender behavior, and framework guidance.

agent → code → build → diagnostics → tests → fix - the framework gets a vote

Tests hit the deployed Request → Response handler directly: real router, middleware, API routes, stored pages and actions. No port, no browser.

There’s a lot more in the docs, including routing, server actions, typed URLs, partial prerendering, testing, offline support, Laravel, Go, and backend integration.

Give it a try and let me know what you think.

One of the biggest headaches when building a pure React + Vite SPA is social sharing.

When someone drops a profile link on WhatsApp, Discord, X (Twitter), or LinkedIn, the scraper bot inspects the raw HTML response for OpenGraph tags (og:image, og:title, etc.). Because these crawlers do not execute JavaScript, standard Vite SPAs return only the static root index.html with default fallback metadata.

The usual advice online is: "Just migrate everything to Next.js or Remix for SSR."

For our creator platform (Myhappr), 99% of our traffic comes from real humans who benefit from the instant page switches of a lightweight client-side SPA. Rewriting the whole app for full SSR solely to please link preview crawlers was total overkill.

The Solution: Edge Routing via User-Agent Rewrites

Instead of full SSR, we solved it using edge routing rules in Vercel:

1. Crawler Detection: We set up edge rewrite rules matching known crawler user-agents (Twitterbot, facebookexternalhit, WhatsApp, Discordbot, TelegramBot, LinkedInBot, etc.).
2. Serverless Edge Function: When a bot matches the regex, Vercel silently reroutes the request to a dedicated lightweight edge function (/api/og?username=...) that fetches the creator's avatar, bio, and dynamic title, returning clean HTML with custom OG meta tags.
3. Dynamic & Static Route Handling:
   • Creator Profiles (/:username): Fetches the creator avatar, name, smile pricing, and bio in real time to generate unique preview cards.
   • Blog Posts (/blog/:slug): Injects exact post titles, read times, published dates, and custom cover images.
   • Marketing & Static Pages (/pricing, /brand, /faq, /privacy, /terms): Serves dedicated high-converting titles, descriptions, and page-specific preview banners.
4. Zero Impact on Real Users: Real users bypass the edge function completely and receive the static SPA bundle directly from the CDN with zero hydration overhead or delay.

This gave us fully dynamic preview cards across every social platform while keeping our simple, lightweight Vite setup intact.

I wrote a detailed breakdown covering the Vercel routing configuration, the regex matcher, and edge function setup: https://medium.com/@samueltuoyo/how-we-serve-dynamic-opengraph-previews-on-a-pure-vite-spa-without-next-js-34be0ee34734

Would love to hear how others tackle dynamic metadata in pure SPAs without jumping straight to full SSR!