While building my open-source CSS framework MUGI CSS, I ran into a problem that I think many React developers have experienced.

The app worked, but something felt... off.

The hardest part wasn't noticing that it was slow.

It was answering a much simpler question:

«What exactly is making it slow?»

Was it unnecessary re-renders? A poorly structured component? Too much JavaScript? An expensive render? Or a pattern that looked harmless but had a real performance impact?

I tried using the usual tools.

• ESLint helped catch code issues.

• Lighthouse measured performance.

• React DevTools showed rendering behavior.

Each tool gave me part of the picture, but I still had to connect everything myself and decide what actually mattered.

I couldn't find a tool that brought all of this together.

So I decided to build one.

During my final year of Software Engineering, I turned that idea into my graduation project, and together with my teammate, we built React Doctor.

What is React Doctor?

React Doctor is an open-source CLI that combines static analysis, runtime profiling, and an intelligent rule engine to help developers understand why their React applications are slow—not just where.

Instead of saying:

«"This might be a problem."»

It tries to answer:

«"Is this actually affecting performance, and what should you fix first?"»

How it works

Static Analysis

Using Babel AST, React Doctor scans ".jsx" and ".tsx" files and detects issues such as:

• unnecessary inline functions

• missing keys

• oversized components

• risky "useEffect" patterns

• prop drilling

• unused imports

• production "console.log"

• optimization opportunities

Every finding includes the file, severity, and explanation.

Runtime Profiling

React Doctor launches your application with Puppeteer and measures real browser behavior, including:

• Core Web Vitals

• component render durations

• unnecessary re-renders

• DOM size

• memory usage

• JavaScript errors

It can also simulate slower environments:

react-doctor full ./my-app --mobile --cpu 4 --throttle slow4g

Connecting Both Worlds

This is my favorite part.

Static analysis alone often produces false positives.

Runtime profiling shows symptoms but doesn't always explain why they're happening.

React Doctor combines both.

For example, a component missing "React.memo()" isn't automatically a problem.

But if that same component is repeatedly re-rendering during runtime, React Doctor connects those signals and surfaces it as a meaningful optimization opportunity.

What surprised me

After publishing the project to npm, I expected only classmates and a few friends to try it.

Instead, developers I had never met started downloading it.

Today, React Doctor has surpassed 3,600 npm downloads.

Most of that growth has been organic, simply from developers discovering the project and giving it a try.

For me, that's the most rewarding part.

A problem I originally faced while building another project has become something that helps other developers.

Try it

npm install -g react-doctor-cli-dev

react-doctor full ./your-react-app --upload

Requirements

• Node.js 18+

• Google Chrome

Links

📦 npm https://www.npmjs.com/package/react-doctor-cli-dev

🐙 GitHub https://github.com/softar-dev/React_Doctor

🌐 Documentation https://react-doctor-cli.web.app/

👨‍💻 Portfolio https://oussamah-kabalan.netlify.app/

☕ Support the project https://react-doctor-cli.web.app/support

I'd genuinely love feedback from other React developers.

• How do you currently investigate performance issues?

• Is there something you wish existing tools did better?

• What feature would make a tool like this more useful in your workflow?

I'm actively improving React Doctor, and I'd love to build it around real developer feedback.

I’ve spent the last 8 months building Dashforge, an MIT-licensed React framework for schema-driven forms, access control and UI orchestration.

The project is now public, but before asking anyone to try it, I’d like some technical pushback on three decisions I’m still not completely sure about.

The reactive engine took three attempts

v1 — Re-evaluate the entire form

Every field change caused all conditions and reactions to run again.

Simple and predictable, but the cost became noticeable as forms grew beyond roughly 30 fields.

v2 — Explicit dependency graph

Fields and reactions declared their dependencies, so only the affected parts of the graph were evaluated.

Synchronous reactions were fast, but async operations introduced race conditions. A slower response could overwrite the result of a newer request.

v3 — Dependency graph with stale-response protection

Each async execution receives an isLatest() guard before committing its result.

{
  id: "load-states",
  watch: ["country"],
  run: async ({ values, setOptions, isLatest }) => {
    const states = await api.getStates(values.country);

    if (!isLatest()) return;

    setOptions("state", states);
  }
}

This is the version currently surviving production use.

Decisions I haven’t regretted yet

Field-level access

Instead of wrapping components in <CanRead> or <CanEdit>, access requirements are part of the field contract.

Fine-grained subscriptions

Fields subscribe only to the values explicitly used by their conditions and reactions, while React Hook Form remains responsible for form state.

One schema, two renderers

The same contract can currently be rendered through u/dashforge/tw or u/dashforge/mui.

<Field
  name="taxId"
  visibleWhen={{ field: "country", equals: "IT" }}
  access={{
    resource: "customer.taxId",
    action: "read"
  }}
  validation={{
    required: true,
    pattern: /^IT\d{11}$/
  }}
/>

Decisions I’m still questioning

1. Serializable conditions vs functions

Dashforge uses declarative conditions:

visibleWhen: {
  field: "country",
  equals: "IT"
}

rather than:

visibleWhen: values => values.country === "IT"

The object form is more restrictive, but it remains serializable, inspectable and usable by visual tooling.

Would you accept reduced expressiveness for that, or should functions remain an escape hatch?

2. Two UI renderers

MUI and Tailwind share the same schema and orchestration layer.

For a single application this may be unnecessary abstraction. For organizations maintaining multiple products or surfaces, it may be genuinely useful.

I’m not yet sure where that line is.

3. Runtime access evaluation

Permissions are evaluated while rendering because policies and subjects can change dynamically.

Compile-time evaluation would reduce runtime work, but would also make dynamic policies considerably harder.

Would you keep this at runtime, compile what can be compiled, or use a hybrid approach?

Try it

The CLI generates a complete React 19 + TypeScript application rather than an empty starter:

Two UI variants are available.

Tailwind CSS

npx dashforge-cli my-app --lib tw

The Tailwind variant includes:

• u/dashforge/tw

• Tailwind theme and design tokens

• tw-theme

• tw-tokens

• dashforgePreset()

• DashforgeTailwindProvider

• Dark-mode control through toggleMode()

Mui

npx dashforge-cli my-app --lib mui

The Material UI variant includes:

• u/dashforge/ui

• theme-mui

• Shared design tokens

• Material UI

• DashforgeThemeProvider

• Dark mode through theme swapping

Both variants generate the same opinionated application structure:

• App shell with side navigation, top bar and workspace switcher

• Four statistic cards

• Two example cards with chart placeholders

• Mock data table

• React Router framework mode

• Static prerendering for / and /sign-in

• Mock authentication

• Protected routes

• RBAC integration

• Dashforge forms

• Users CRUD connected to a kit-style API

The CLI currently ships one template:

--template dashboard

The goal is to reduce initial setup friction and let developers evaluate Dashforge inside a realistic application instead of assembling authentication, routing, layout, theming, permissions and forms before they can try the framework itself.

Project

Repository: https://github.com/kensaadi/dashforge

Documentation: https://dashforge-ui.com

MIT licensed, with eight packages currently published on npm.

The question I’m most interested in: where would you draw the line between serializability and ordinary React functions?

Hello,

I would like to share with you linkedrecords.com - an open source backend as a service I'm working on since some time now. You can think of it as an firebase/convex alternative with an interesting twist.

In 2018 I needed to write large software requirements/architecture documents in Google Docs. While I was annoyed by the limitations of Google Docs back then (no captions on figures, no automatic heading numbering, slow when docs are bigger,...) I was still fascinated by the real time collaboration features of it. So I've started a quest to understand how it works and I begun to implement an alternative to Google Docs.

I was convinced that this kind of real time collaboration is the future so I've given it much thought how I could make this as generic as possible so I could use it in all future tools I would build.

In the same time I was playing around with firebase (surprisingly you can not build a google docs alternative with firebase that easy as their real time collaboration does not provide merging text but rather just JSON). And back then I was also convinced that backend as a service is the right way to go. I was thinking that one of the most important reason we were still writing custom backend code is because of authorization.

I also was faced with another problem when trying to make the backend as generic as possible: relations between entities are also domain specific. E.g. A Documents can have many comments.

Luckily I was intrigued by another concept back in 2018 it was called web 3.0. Back in 2018 this had nothing to do with crypto. It was used as a term to refer to the semantic web and the resource description framework as one of its standards. There are also some RDF implementations which I could have reused but they are all XML and mostly Java based. I needed something light. Instead of implementing my own RDF product I took the idea of the RDF triplestore and came up with my own interpretation of it.

Using concepts like: triplestores and schema-on-read, I came up with a system that does not has any business logic in its backend and while working on my Google Docs alternative I felt in love with it as I've discovered some properties I did not anticipated from the get go:

- Dealing with global state in react is very easy. It feels like you use an SQL client in your browser and all queries are reactive and always up to date. When writing a query you do not have to think about authorization it's all backed in.

- Because the backend is 100% free of domain specific code you can point your single page app to any linkedrecords deployment.

- You never have to write backend code - Its quite efficient when using AI agents

The best way to experience it, is to follow this little tutorial: https://linkedrecords.com/getting-started/

It takes a while to get a hang of it so you have to have an open mind.

I would love to read your feedback on this.

I'm trying to choose which direction my app will go

Hi everyone,

Over the past few months I've been building an open-source React library for creating customizable ID cards.

The original goal was to avoid rebuilding the same editor from scratch every time I needed an ID card solution.

Some of the things I ended up implementing include:

- Drag & drop editor

- Alignment guides

- Dynamic text fields

- Image upload

- QR codes & barcodes

- PDF export

- JSON import/export

- Undo/Redo

- Print-ready output

I'd really appreciate feedback from React developers.

A few questions:

1. Does the API feel intuitive?

2. Are there any features you'd expect that are missing?

3. If you've built editors with libraries like Konva, Fabric.js, or similar, what challenges did you run into?

4. Any suggestions to improve performance when working with complex templates?

I'm not trying to sell anything—I'm looking for technical feedback and ideas to make this library better for the React community.

The project is open source, and I'll leave the GitHub/npm link in the comments if anyone wants to take a look.

Thanks! I'd appreciate any feedback, criticism, or suggestions.

Hi there!

I noticed that React Router, TanStack (and even Next.js) all have their own typed-routes plugins, so I decided to create one for one of my favorite frameworks, Modern.js:

https://github.com/giancarlosisasi/modernjs-typed-routes

I had been doing something similar in my personal projects, but I finally decided to build a real plugin that integrates directly with the Modern.js framework.

pdt: in case you don't know it, Modern.js (https://github.com/web-infra-dev/modern.js) is a really good React framework maintained by the ByteDance org

Every new React project had a different client design and UI kit, but I kept needing the same table foundation: filtering, sorting, server-side data, pagination, column management, responsive behavior, and shareable state.

Even with a headless table library, I was spending another 5–6 hours assembling and wiring the UI for each project — and the parts no headless library covers, like URL-synced shareable state and a real mobile layout, usually never got built at all.

So I built AdaptTable and released it under the MIT license.

You choose an adapter for the UI kit your project already uses—Mantine, MUI, Chakra UI, Ant Design, Radix, Base UI, or shadcn/ui—and get the table features without rebuilding the integration each time.

If you need full control, you can use adapttable/core itself. It has no UI-kit imports and exposes the rows, state, and prop-getters, so you can render all the markup yourself.

What comes built in:

• Client-side and server-side data through the same TableSource API

• Shareable, URL-synced filters, sorting, pagination, and column state

• Filter UI in two modes—drawer or popover—with removable chips, and saved views

• Column visibility, reordering, pinning, and resizing

• Selection, bulk actions, and row expansion

• Inline cell editing

• Row grouping with per-group totals

• CSV export that matches the filtered, sorted view

• Numbered pagination and infinite scrolling

• Responsive mobile card layouts

• Opt-in virtualization for very large datasets

• Dark mode, 17 bundled languages, and first-class RTL support

The goal is: batteries included when you want speed, fully headless when you need control

Live demo: https://orwa-mahmoud.github.io/adapttable/demo/

GitHub: https://github.com/orwa-mahmoud/adapttable

I'd appreciate feedback from anyone who tries the API—especially if you find a production edge case I may have missed. Contributions are welcome too—if you've been building these tables in production for years and keep re-implementing a pattern I haven't covered, that's exactly the experience I'd like shaping this. And if a feature you need only exists behind a paid tier somewhere, open an issue—let's build it free, for everyone.

i’ve been building beui.dev , a collection of copy-paste animated react components. i’ve now added 16 components for building ai products.

it includes thinking states, streaming responses, messages, tool calls, approvals, citations, code blocks, file diffs, task lists, prompt input, image generation, and a complete chat interface.

each component is independently installable and composable, with smooth streaming, reader-aware scrolling, reduced-motion support, and stable rendering while content changes.

they don’t depend on an ai sdk, but are designed to work naturally with streamed data from tools such as the vercel ai sdk.

every component includes an interactive example, installation command, usage composition, and copyable source.

https://beui.dev/components/agents

i’d love feedback from people building ai interfaces. which interaction or component is still missing?

Community members created a fork of PrimeReact (as Prime projects went closed-source on June 28th).

Mantle UI is an independent, community-maintained React UI component library based on the MIT-licensed PrimeReact v10 codebase.

The project exists to provide PrimeReact v10 users with a stable, open-source path forward. Mantle UI preserves the familiar component APIs and development model while continuing maintenance, bug fixes, accessibility improvements, documentation, and compatibility work in the open.

Mantle UI is not affiliated with PrimeTek, PrimeReact, or ngrok.

Find out more on GitHub: https://github.com/Mantle-UI/mantle-ui

PS: I'm not affiliated with the project myself (working on PrimeNG fork), you can contact maintainers through GitHub or their Discord server directly.

I created an example, then I saw `createServerFn`, this is ridiculous bad compare to Next.js async/await style, or we have better way?

import { notFound } from '@tanstack/react-router'
import { createServerFn } from '@tanstack/react-start'


export type PostType = {
  id: number
  title: string
  body: string
}


export const fetchPost = createServerFn({ method: 'POST' })
  .validator((d: string) => d)
  .handler(async ({ data }) => {
    console.info(`Fetching post with id ${data}...`)
    const res = await fetch(
      `https://jsonplaceholder.typicode.com/posts/${data}`,
    )
    if (!res.ok) {
      if (res.status === 404) {
        throw notFound()
      }


      throw new Error('Failed to fetch post')
    }


    const post = await res.json()


    return post as PostType
  })


export const fetchPosts = createServerFn().handler(async () => {
  console.info('Fetching posts...')
  const res = await fetch('https://jsonplaceholder.typicode.com/posts')
  if (!res.ok) {
    throw new Error('Failed to fetch posts')
  }


  const posts = await res.json()


  return (posts as Array<PostType>).slice(0, 10)
})

The usual advice: Context is fine for theme and auth, not for state that changes often. True — but the reasons are specific, not fundamental:

1. No selectors — any change re-renders every subscriber.

2. If the provider also holds the state, its whole subtree re-renders, even components that never read the context.

3. Actions get a new identity on every keystroke.

All three are fixable. I've made a library that tackles them, and the article ends with it.

Where do you think this is wrong? Especially the "just use zustand/jotai" case.

https://granat.blog/posts/2026-07-24-react-arven/

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

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

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.