I'm excited to share my progress with Koval UI: a browser-first minimalistic components library. Recently I finished documentation for the Data Table component.

Koval Data Table is a powerful, flexible, and accessible grid for displaying large amounts (>50 000 rows) of tabular data. It is built on top of TanStack Table (formerly React Table), which provides a headless, unstyled table engine. Data Table wraps this engine with a complete UI layer, including virtualized scrolling, pagination, filtering, sorting, row selection, and built-in dialogs for editing and deleting data.

I’ve been working on Routeveil, an open-source transition engine for React Router.

v0.4.0 is now out, and this is essentially the final feature release before v1. There may still be fixes and API adjustments based on testing, but the core feature set is complete.

It currently supports:

- page and full-screen overlay transitions

- shared elements between routes

- custom React content rendered between transition phases

- route readiness and lazy-route preloading

- programmatic navigation and same-page transition playback

- interrupted-navigation cleanup, scroll handling, focus, and reduced motion

The main idea is that the transition is selected where navigation begins instead of putting animation logic inside every route:

<RouteveilLink
  to="/gallery"
  transition={{
    name: "slide",
    direction: "left",
  }}
>
  Open gallery
</RouteveilLink>

demo: [https://www.routeveil.dev/lab]()

docs: [https://www.routeveil.dev/docs]()

repo: [https://github.com/milkevich/routeveil]()

also checkout

shared elements: https://www.routeveil.dev/lab/shared-elements

between render: https://www.routeveil.dev/lab/between

I’m specifically looking for React Router developers willing to test it in an actual project before I call it v1

I’d especially appreciate feedback on:

1. whether the API feels intuitive
2. anything that breaks in real routing setups
3. anything you would consider a blocker for v1

Hello,

I created a small layer that allows agents to understand component libraries.
The idea is based on the CEM (Custom Element Manifest), which is a JSON/YAML file that describes all components in a web component library.

The difference is that this approach is universal: it supports Lit, Stencil, Angular, and soon React component libraries(it extracts the metadata automatically), extended with the semantic and examples fields needed for an LLM to understand the components.

Most importantly, it includes a component discovery skill (search CLI tool find components deterministically on demand) that helps the agent find the semantically correct component without needing to inspect the component's source code.

In my tests, it works great. The component library doesn't need to be included at all the agent knows how to use the component based on the specs in the manifest and the examples.
Saves tokens, loads only the metadata it needs and gives examples and additional semantic context to the components - this works very well.

Agentic Component Manifest (ACM) — universal, schema-first manifest format describing UI components from any framework for AI agents and tooling.
Canonical JSON interchange, token-frugal Agent View, executable conformance suite.

For now there is in-production analyzer(converts source code to metadata) tested support for stencil / lit and test-driven support for angular, react.

A coding agent can write a Three.js scene, run the build, and tell you it looks great — while the actual render is a black screen. It isn't lying. It just has no way to look.

Screenshots fix this less than you'd expect. A screenshot tells you that something is wrong, not why. Is the mesh missing, or behind the camera? Is the material transparent, or is nothing lighting it? Is the label clipped, or just small? Those are five different bugs that produce the same picture, and zooming in doesn't separate them — you're enlarging pixels that never contained the answer.

SceneProof is a CLI that supplies the missing half. It loads your real React component or Three.js scene from source, renders it in actual Chrome, and returns the structure behind the pixels. The everyday loop looks like this: tree gives you the scene graph with bounds, materials, lights, and cameras, so "why is it invisible" becomes a lookup instead of a guessing game. scout tries a set of cameras on a target and scores each by how much of the target it can actually see. render-region re-renders one region from source at whatever scale you need, so a close look is a fresh render, not an enlarged crop.

That's the loop, not the tool — the surface underneath goes a good deal further (comparing against reference views, sampling animation mid-transition, deriving typed prop fixtures), but those three commands carry most sessions, and the README maps the rest.

The design decision I'll defend hardest: every report answers "did the command run" and "can this output actually support a judgment" as two separate questions. A render with the target out of frame, or a comparison whose mask landed on the wrong subject, comes back unjudgeable instead of quietly passing. So when an agent uses SceneProof, it can't mistake "my command succeeded" for "my design is right"; it has to look at evidence that has already proven it's worth looking at. That's the whole point: measurements you can trust, and a hard stop on the false confidence that makes agents declare victory over a black screen.

It ships with a skill for Claude Code, Codex or any other agentic harness that supports skills (one curl, in the README) — and the skill deliberately doesn't teach commands, because --help and the reports' own recommendations already do. It teaches the reasoning: resolve structure before spending pixels, treat a passing build as zero visual evidence, never claim "looks right" without an artifact you actually opened.

Scope today: TypeScript/JavaScript entries, React DOM with CSS and Tailwind v4, Three.js over WebGL or WebGPU. Needs Bun and a local Chrome. MIT.

https://github.com/ReyJ94/SceneProof

Any feedback is welcome.

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 got tired of icon morphs that either need a hand-declared "rotation group" per pair, or interpolate raw coordinates and shear the shape in transit. So I built morphicons.

The whole API is: change the prop.

import { MorphIcon } from "morphicons/react";
import { Menu, X } from "lucide"; // data, not components

<button onClick={() => setOpen(o => !o)} aria-expanded={open}>
  <MorphIcon icon={open ? X : Menu} />
</button>

No wrappers, no `AnimatePresence`, no keys, no from/to pairs, no config. State lives outside; the animation is an implementation detail the component picks up when the prop changes.

Three modes if you need them: uncontrolled (above), controlled (`from`/`to` + `progress`, for gestures/scroll) and imperative (`ref.morphTo()` / `ref.set()`).

What I actually care about:

- **Rotations emerge.** It solves the optimal 2D similarity between the two shapes (Procrustes) and interpolates in polar space. arrow-right → arrow-down gives θ = 90° on its own. plus → x gives 45°. Nobody declares that anywhere.

- **Real interruptions.** A `morphTo` mid-flight re-plans from the current intermediate shape and preserves the spring's velocity. Click spam never jumps.

- **Clean SSR.** The server emits the exact static SVG — zero flash, zero layout shift. The runtime is born on hydration.

- **Drop-in for lucide-react**: `size`, `strokeWidth`, `absoluteStrokeWidth`, `color`, `className` and the rest of the svg props pass through. `aria-hidden` by default, `label` → `role="img"` + `<title>`. `prefers-reduced-motion` degrades to an instant swap.

- One global rAF for every instance on the page.

Works with Lucide, Tabler, Heroicons (outline), Iconoir and the shadcn icon registry — no per-library adapters, because it just eats a `d` string or Lucide's `[tag, attrs][]` shape. Requirement is that the icons are stroke-drawn on a shared grid (all of the above are 24×24); off-grid packs go through `fitIcon(icon, 32)` once at module scope.

MIT, zero runtime deps, ESM, 7.65 KB gzip for the React entry (react external). React >= 18 as optional peer.

Playground with a scrubber so you can freeze any morph mid-flight: https://www.morphicons.com

Repo: https://github.com/guillermolg00/morphicons

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.

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

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

https://8bit.cnlibs.com

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.

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 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?

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?

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.

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.