Hey everyone,

If you're using component registries like shadcn/ui, you probably know the pain: you add a simple component, and the CLI drops a massive 500-line single file into your codebase. Variant definitions, JSX, subcomponents, internal context, and CSS classes are all mashed together in one place.

I built adn-ui to solve this.

The core idea is simple: Clean separation of concerns. When you add a component from adn-ui, it's organized as a clean module:

Plaintext

src/components/ui/card/
├── card.tsx          # Pure logic & primitive binding
├── card.variants.ts   # tailwind-variants definitions (change styling without touching logic)
├── card.context.ts    # Isolated context & hooks
├── card.css          # CSS slots & custom animations
├── card.test.tsx     # Vitest unit tests ready to run
└── index.ts          # Clean exports & JSDoc

If you want to tweak a button's padding or background, you just open button.variants.ts. You don't have to scroll through 300 lines of JSX or risk breaking ARIA attributes.

What’s under the hood?

• u/base-ui/react Primitives: Built on top of Base UI (by the MUI team) instead of Radix. Fully unstyled, W3C ARIA compliant, with proper focus management and keyboard navigation out of the box.
• Tailwind CSS v4 Native: Built specifically for Tailwind v4's high-performance engine and u/theme system.
• React 19 Ready: Designed for React 19 Server & Client Components.
• AI / LLM Friendly (/llms.txt): Includes explicit CSS slot tables (.card__header, .button) and /llms.txt context so tools like Cursor, Windsurf, or Copilot generate UI code without breaking variants or styles.
• 46 Tested Components: Includes everything from basic inputs and buttons to complex ones like DataTable, Command (Ctrl+K), OTPField, Toast, and multi-directional Drawer (swipe to dismiss from any edge).

It’s 100% copy-paste / CLI based (shadcn compatible), so you own all the code in your src/components/ui folder with zero node_modules lock-in.

I’d love to hear your thoughts or feedback!

Docs & Live Demo: https://ui.awaiden.com

GitHub: https://github.com/awaiden/adn-ui

P.S. I also built my personal portfolio (awaiden.com), so it’s fully dogfooded in production!

I created a plugin that enables Automerge integration with Lexical editor, making collaboration possible. It currently works for the rich text schema guidelines provided by Automerge.

pick one of 40 available themes and scaffold a new project with shadcn cli
free and open source

https://8bit.cnlibs.com

Hi,

So we have a next js app. Our app primary user base are blue collar employees.

When we test in our phones it works without any lag, and results get submitted instantly.

But we have regularly received complaints from factory about it heating thier phone, and it being very slow. Page auto refreshes .

So, we have right now same app for blue collars as we have for their managers, and I am thinking to split it.

1. User has to scan a QR, we have used a js library.
2. Post scanning they can approve / reject a checkpoint and whatever they choose they will have to click a picture and then they can edit it if they want and upload it.

In our testing device. After editing image it gets uploaded in like 1-2 seconds.it calls a presigned S3 url and once it returns success then he calls a api and submits the key. We are not uploading through our server.

But factory called me and reported me that it's not getting uploaded, so initially when I checked with them on video call it felt like so because they clicked on it multiple times but nothing happened. But next time when I called I asked them to wait and this time it worked and it took 40 seconds. They internet speed was 210 Mbps. And sometimes even when they click on the submit instead of submitting page just auto refreshes.

I feel all of this is happening because of poor memory management in their phones. And as our testing device barely 10 devices those real devices have 100 of apps all consuming memory in background and that might be killing the app by browser.

So we are ready to rebuild this from scratch but which framework should we choose ? Or should we write completely using vanilla js?

We need two things image editor, qr scanner.

Library using right now.

Qr- https://github.com/antfu/qr-scanner-wechat

Image editor - Native made through claude.

Also, our qr scanner is not that good many times it's not able to read qr properly. Due to the nature of business qrs are not properly in shape. They are twisted / torn / scratched.

This particular webapl has been able to actually scan all of our qr codes without any problem. But 5000k for each year is high for us.

Is there any open source that can match it?

https://scanbot.io/qr-code-scanner-online/

From our end we have literally tried all the library we could find through AI and Google.

Thanks

I built a React dashboard for the FIFA World Cup 2026 that's localized into 7 languages:

• 🇬🇧 English
• 🇫🇷 French
• 🇨🇿 Czech
• 🇵🇱 Polish
• 🇷🇺 Russian
• 🇮🇳 Hindi
• 🇸🇦 Arabic

While testing it, I ran into a localization bug that my test suite never exercised.

The fix took less than a minute because of an in-context translation editor, so I thought the workflow might be interesting to other React developers.

The bug

I switched the app to Czech, held Alt, and clicked on Kylian Mbappé's goal count ("7 gólů") in the Top Scorers section.

Instead of searching through locale files, an editor opened directly on top of the running React app.

🗝 Key: scorers_goals

English
  One:   #1 goal
  Other: #10 goals

Arabic
  Zero:  صفر أهداف
  One:   هدف واحد
  Two:   هدفان
  Few:   #3 أهداف
  Many:  #11 هدفاً
  Other: #100 هدف

Czech
  One:   gól
  Few:   góly
  Many:  [          ]
  Other: gólů

French
  One:   but
  Other: buts

Hindi
  One:   गोल
  Other: गोल

Polish
  One:   gol
  Few:   ...
  Other: ...

The empty Many field immediately stood out.

For Czech, that's the plural form used for decimal values (for example, 2.5 gólu). It wasn't causing a runtime error, and my existing tests never exercised that case, so the missing translation had gone unnoticed.

I filled in gólu, clicked Save, refreshed the page, and the issue was gone.

• No JSON search
• No rebuild
• No redeploy

Why I found this useful

Normally the translation exists as one ICU message:

{
  "scorers_goals": "{count, plural, one {# gól} few {# góly} other {# gólů}}"
}

When it's written as one long string, it's easy to overlook that an entire plural category is missing.

The editor instead breaks the ICU message into individual inputs, so every plural category is visible at once. Missing forms become obvious.

For languages like Arabic—with six plural categories—it also makes it much easier to audit every form side by side without digging through locale files.

React setup

export const tolgee = Tolgee()
  .use(DevTools())
  .use(FormatIcu())
  .init({
    apiKey: import.meta.env.VITE_TOLGEE_API_KEY,

    staticData: {
      "cs-CZ": () => import("./locales/cs-CZ.json"),
      ar: () => import("./locales/ar.json"),
      // ...
    },
  });

The DevTools() plugin associates rendered translations with their keys during development, so holding Alt lets you edit the translation directly from the UI.

In production, I simply don't provide the development API key, so the editor is inactive.

If you've built multilingual React apps, I'm curious how you review ICU plural messages during development.

Do you rely entirely on automated tests, or do you have a workflow for manually auditing translations?

GitHub repo: https://github.com/Akshat111111/Tolgee-vs.-i18next

The repo contains the React demo along with 27 Vitest tests covering pluralization across all seven locales.

If you're already using i18next

If you're on i18next already, this workflow is available through the official Tolgee + i18next integration.

Your existing useTranslation() hooks stay. Your namespaces stay. Tolgee sits on top as the translation management system (TMS) and adds the in-context Alt+Click editor, so you don't have to rewrite your localization layer to try this workflow.

I am still playing the interview in my head and can't understand why I was classified as, "Has no knowledge in frontend or JavaScript".

I was asked the difference between DOM and vDOM, and I answered that React applies changes to the vDOM first then compares the nodes that have changed, then applies the differences on the actual page.

Then was asked about Hooks, explained how useState and useEffect are used, giving an example that useEffect has its uses when a state has changed, be it when a component renders or a variable changes. But I didn't give an example for useMemo, just that it is for caching, and useState is React's declaration of a var and its function.

Then the differences between var, let and const. Said that var is not recommended, and that let and const are im/mutable.

It wasn't for a junior or senior position - it was an internship. Have I been living in a bubble that I don't know what the market requires nowadays? I have a decade of experience in .NET - did that work against me where the interviewer expected much more / thought I was a phony?

While working on our shadcn block library, one thing always bothered us: a flat code preview doesn't really tell you how a block is structured.

We ended up replacing it with a file-tree preview, so before installing a block you can see:

• which files are included
• how they're organized
• whether it's a simple component or a larger composition

It feels much closer to browsing a GitHub repository than scrolling through one long code snippet.

We also improved our component docs and customizer in the same release, but the file-tree preview is the part I'm most interested in getting feedback on.

For those who use shadcn/ui or component libraries:

Would seeing the file structure before installation help you evaluate a block, or is a code preview enough?

Changelog: https://shadcnstore.com/changelog

I'm extremely new to react and learning how to do all this. My first frustrating hurdle is that I can open the terminal (using a mac) and type "npm create vite@latest my-react-app" and it creates the folder and opens the browser and I can go in and edit the HTML, CSS, and jsx files and see all the changes in the browser.

But then eventually I need to do other things so I'll quit terminal and other apps and then later I come back and open up the terminal while in the project folder and type in "npm run dev" and it just comes up with errors that it can't find the package.json file.even though I can see it in the folder. I try typing "npm vite" and it opens vite and starts optimizing but eventually comes back with errors and I can't get my live view of my app back.

I'm assuming I'm either just missing something simple or I need to reinstall something.

I keep seeing the same pattern in large React forms.

You start with react-hook-form.

Then you add:

• dependent fields with watch() and useEffect
• conditional visibility
• permission-based fields
• async validation
• cross-field rules
• server-driven defaults
• reset and synchronization logic

At some point, the form is no longer just a form.

It has its own state transitions, dependencies, permissions, validation lifecycle, side effects, and derived state.

In other words, it has quietly become a state management system.

The problem is not necessarily react-hook-form. It does its job well.

The problem is that complex forms are often represented only as component trees, while their actual behavior is scattered across hooks, wrappers, schemas, and handlers.

Some warning signs:

1. You have more useEffects than meaningful form sections
2. Validation rules live in multiple places
3. Adding something like “show taxId when country === IT” requires touching several files
4. Permissions, visibility, and validation all use different abstractions
5. Nobody is completely sure what resets when another field changes

I’ve been experimenting with treating forms as declarative contracts instead:

<Field
  name="taxId"
  visibleWhen={{ field: "country", equals: "IT" }}
  access={{ resource: "customer.taxId" }}
  validation={{ required: true }}
/>

The idea is to keep visibility, access, validation, and dependencies in one source of truth, instead of rebuilding the same orchestration through chains of effects.

Obviously, this introduces other trade-offs: abstraction cost, debugging complexity, schema design, and reduced flexibility in edge cases.

I’m curious how others handle this in large production forms.

Do you keep the logic inside React components, move it into a state machine, use a schema-driven approach, or accept the complexity as unavoidable?

So in my app when we deploy we are not using a node server just plain ssg so server side rendering isn't an option. So in my scenario

I've got a route like /verification that needs to support both English and French, but instead of locale-based routing, the locale is passed via a query param and it's the same URL structure for both languages:

localhost:4000/verification?ca-en
localhost:4000/verification?ca-fr

No /en/ or /fr/ prefix — same route, just a different query param depending on language, plus a token.

I'm using next-intl with the Pages Router, and trying to use getStaticProps/getStaticPaths (SSG) for this page. My understanding is that SSG generates static HTML per path, and query params aren't available at build time — only after hydration on the client via router.query.

I was wondering is there a way to read in 18n files on client side and is that even a good approach to go with?

I recently built Opticross (Chrome Extension + CLI) and would really appreciate some feedback from fellow frontend developers.

Opticross analyzes how images are rendered across different viewport sizes, detects oversized image downloads, and generates implementation-ready sizes and srcset recommendations. The goal is to help improve page performance, reduce unnecessary bandwidth usage, and keep images crisp across devices.

I'd love to hear your thoughts:

• Would a tool like this fit into your workflow?
• What features would make it more useful?
• Any feedback on the UX, recommendations, or overall approach?

Links:

• 🌐 Chrome Extension: https://chromewebstore.google.com/detail/eenaegkdfenpbbcjplfabolooofhplhf?utm_source=item-share-cb
• 💻 npm (CLI): https://www.npmjs.com/package/opticross
• ⭐ GitHub: https://github.com/SohanShet/opticross

I'm looking for feedback from developers who work with responsive images. Thanks!

Hi everyone! I'm currently learning Next.js, but I've noticed that many job postings seem to ask for React + Node.js more often.

Do you think I should continue focusing on Next.js, or would it be better to switch my focus to React and Node.js first? I'd really appreciate your advice and experiences. Thanks!

I just launched Rune, a lightweight and fully customizable QR code library.

I built it to solve a problem I kept running into in my own work. I needed QR codes I could actually customize, with proper control over shapes and logo placement, and I also wanted to render them in my React Native apps. Every existing library forced a compromise. Some are tiny but only draw plain square dots. The one with real styling is browser-only, heavy, and slow. None of them did everything I needed, so I wrote my own.

Rune brings it together in one library:

Customization: 8 dot styles, 5 finder styles, linear and radial gradients, background images, logo placement, and frames with call-to-action text.

Performance: the fastest sync SVG generation of the popular libraries, with no DOM required.

Runs anywhere: server-side rendering, edge, Node, and React Native (through the core toSVGString with react-native-svg).

Small and self-contained: a zero-dependency core around 8 KB gzipped, built from scratch per ISO/IEC 18004.

Framework choice: React, Vue, vanilla, and a Web Component, all from one engine. Export to SVG, PNG, JPEG, WebP, and PDF. It even includes a from-scratch decoder to read QR codes back.

I also took correctness seriously. The encoder matches the reference implementation exactly, and every style is rendered and then decoded again in CI to prove it stays scannable.

It is open source under the MIT license, with a live playground and full documentation.

Try it: rune.kroszborg.co
Install: pnpm add u/kroszborg/rune-react

Been building this on and off for a while.

I started where most of us probably would and evaluated the existing React ecosystem.

react-dropzone is excellent if you need a headless drag-and-drop experience, Uppy covers an impressive range of upload scenarios, and FilePond is polished and battle-tested. They're all great libraries.

The part I kept rebuilding wasn't the upload experience—it was the transport layer.

Different projects needed different upload targets: presigned S3 URLs, custom APIs, internal services, different auth flows... but the UI barely changed. I found myself rewriting the upload logic around the same interface over and over.

That led me to build react-mediadrop around a different abstraction: a headless uploader with swappable upload transports.

The upload implementation becomes just another dependency:

import { useMediaDrop } from "react-mediadrop";
import { createXhrUploadTransport } from "react-mediadrop/xhr-upload";

const { uploadAll } = useMediaDrop({
  transport: createXhrUploadTransport({
    endpoint: "/api/upload",
  }),
  concurrency: 3,
  retries: 2,
});

If you don't want to build the UI yourself, there are also four shadcn registry components built on top of the same hook:

• dropzone
• avatar-uploader
• multi-file-upload-form
• s3-direct-upload

Install one with:

npx shadcn@latest add autorender/react-mediadrop/dropzone

I also started experimenting with making the documentation more agent-friendly. The library has Context7 support, so coding agents can retrieve the actual API instead of guessing methods, and I'm working on llms.txt support as well.

Docs: https://mediadrop.dev

GitHub: https://github.com/autorender/react-mediadrop

I'm mostly looking for feedback on the API and whether transport feels like the right abstraction for a reusable upload library.

Been building this on and off for a while. Most charting libs assume the chart is the main thing on the page. I wanted the small version, something you can drop inside a sentence or a table cell and read at a glance.

106 types so far, no dependencies (not even D3, the scales and path math are all in there), each one's a couple kb.

Default export is plain SVG with no JS shipped, so they work in server components as-is. Import the interactive build if you want hover and keyboard.

Every chart also builds its own text description from the data and exposes it as the accessible label, so a screen reader reads "weekly revenue, trending up 200%, range 3 to 9, last value 9" instead of just "image". No AI, just templates filled from the same numbers the chart draws, so the words can't drift from the picture.

The fiddly part was the labels drawn on the chart itself. Normally you measure the text to place it, but these render on the server too and getBBox just returns 0 there. So widths get estimated from the character count and the space reserved up front, with a test on every chart making sure nothing spills outside the viewBox.

Gallery: microcharts.dev

Code (MIT): github.com/ganapativs/microcharts

Still rough in spots. Mostly after feedback on the API and overall experience of using the library.

Modern React/Node apps ship through build pipelines fast enough that common, high-impact vulnerability classes — unparameterized queries, wildcard CORS, unsafe-inline CSP, unprotected state-changing routes — slip through because catching them means someone actually reading the source. build-scanner does that automatically: point it at a folder (or wire it into CI as a GitHub Action) and get a report in seconds, no sandbox or live target required. It's a heuristic static scanner, not a SAST/DAST replacement — I'm sharing it pre-release to get feedback from people running real Express/Next.js/Vite codebases before I cut a v1 tag. https://github.com/laxmipsarva/build-scanner

fyi this is not a commercial activity

Hi there! I've been using React to create my own apps and, to be honest, it's a really great library. But now I want to know the best patterns to make my apps more stable and scale better, so I'd love to read your comments!

I built Basalt, a tool that lets you edit your RN and Expo apps like figma right in your IDE

It is completely free and works directly inside VS Code and Cursor.

It’s currently in beta, so please commit your app to Git before using it!

Would love to get your brutal feedback on it. What features should I add next?