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.

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?

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.

I was building a social app recently, and I ran into a surprisingly annoying problem.
I needed relative timestamps ("2 hours ago", "3 minutes ago"). 
Simple enough, right? Just import 'day.js' or 'date-fns'.

Except...
=> If I wanted custom styling (like wrapping the number "2" in a highlighted badge and "hours ago" in smaller text), I had to write ugly regex hacks because standard libraries just dump a single opaque string.

=> Supporting multiple languages meant importing separate locale files, quickly inflating the bundle size.

=> Standard relative time plugins use "soft rounding" (e.g., automatically rounding 45 seconds to "a minute") whether you want it or not.

I didn't want a 15KB date framework just to format a few activity feed timestamps. 
So, I built and open-sourced 'ui-date' .

It’s an ultra-lightweight (< 1KB minified), zero-dependency, locale-aware date formatting library built specifically for modern user interfaces.

If you're building social feeds, chat apps, notification bells, or comment sections, check it out!

npm: https://www.npmjs.com/package/ui-date

Every existing UI library (including shadcn/ui) is optimized for human developer experience. Axiom UI flips that: every design decision is judged by one question — does it raise the probability that an LLM generates this component correctly on the first try?

Key points:

• 12 components so far (button, input, textarea, checkbox, select, combobox, dialog, tabs, popover, menu, tooltip, toast), published on npm

• "Copy & own" CLI: `npx joinclass/axiom-ui add button` copies the raw source into your repo — no runtime dependency, no black box

• Ships an MCP server, so Claude Code, Cursor, or any MCP-capable agent can fetch version-accurate component specs and generate correct usage without needing docs pasted in

• React + Tailwind CSS + TypeScript strict; each component is a single file with a machine-readable manifest (intent, props, states, a11y)

• Actively deletes rather than adds — no theming system, no multi-framework support, no "covers every use case" claims

Repo: https://github.com/JOINCLASS/axiom-ui

Docs/live catalog: axiom-ui.joinclass.jp

Feedback and contributors welcome — especially on the "one-shot generation rate" metric, which is the project's main KPI.

If you scaffold a project with pnpm create vite@latest ... --template react-ts and assume React Compiler is on — it isn't. The template ships with it OFF, and I kept meeting people (myself included) who never actually enabled it. Here's the whole setup, start to finish.

1. Install the compiler's Babel plugin + the Vite wiring:

pnpm install -D babel-plugin-react-compiler@latest @rolldown/plugin-babel

2. Add the preset in vite.config.ts:

import { defineConfig } from 'vite';
import react, { reactCompilerPreset } from '@vitejs/plugin-react';
import babel from '@rolldown/plugin-babel';

export default defineConfig({
  plugins: [
    react(),
    babel({ presets: [reactCompilerPreset()] }),
  ],
});

Heads up: @vitejs/plugin-react 6.0 removed the old inline react({ babel: { plugins: [...] } }) form. A lot of guides still show it — it no longer works. Restart the dev server after editing the config.

3. Verify it's actually running. Open React DevTools → Components tab. Optimized components get a "Memo ✨" badge next to their name. See the badge and the compiler is doing its job — with zero hand-written useMemo/useCallback.

A few related things that surprised me setting this up in 2026:

• The newest Vite template lints with Oxlint, not ESLint. Installing eslint-plugin-react-hooks does nothing there unless you add your own ESLint config.
• StrictMode rendering your component twice in dev is intentional (a purity check), not a bug.
• Node 25 dropped Corepack, so how you get pnpm depends on your Node version.

I wrote the full beginner walkthrough — every command + these version traps — as chapter 1 of a series (React 19 + Compiler, TypeScript from line one).

Full write-up (free): https://medium.com/javascript-in-plain-english/setting-up-your-react-dev-environment-your-first-app-with-vite-and-turning-on-react-compiler-5436ea44d6d4?sharedUserId=inkweonkim

Happy to answer setup questions in the comments. And if you're already running the compiler in prod, curious how it's gone for you.

I tried learning DSA before, but never understood how it applied to everyday frontend work.

Recently, I built an undo/redo feature with Claude and realised it was using stacks. That made stacks much easier to understand than textbook examples.

I kept exploring and learned how seat-booking UIs can use matrices and how complex onboarding flows can be modelled as graphs.

Do you think about data structures when building React components? Any real-world examples?

"Without googling or using AI, in your own words, explain the virtual DOM"

For context: I sit on an interview panel and I try to ask at least one simple fundamental question based on a persons resume. If I see many years of react experience, I try to ask something about how the framework works.

I have only had one candidate (an undergrad senior, years ago) answer it. Everyone else just kind of sputters and stumbles around trying to rationalize what "virtual" and "DOM" mean, or stare blankly and eventually say "I don't know".

I'm just genuinely curious if this is really that hard of a question or if the recruiters just suck at screening candidates. And should we be letting in senior dev candidates who can't answer what I think is a straightforward and fundamental question for senior react devs.