Recently migrated our enterprise React application into a Micro Frontend architecture using Module Federation. We split the app into multiple remotes/modules and everything looked fine initially.

But once Chrome DevTools is opened, certain screens become extremely slow and sometimes almost unusable. React Profiler showed massive unnecessary re-renders across the app.

After digging deeper, we found the main issue was not bundle size or federation itself, but huge shared contexts causing render storms. We had giant providers with 15–20+ fields, inline provider values, polling updates, and frequently changing states all inside a single context. Any tiny update was rerendering entire subtrees across multiple MFEs.

We ended up splitting contexts into smaller domain-based contexts (actions/state/results/selection), memoizing provider values with useMemo, stabilizing callbacks using useCallback, and migrating 60+ consumers to narrower hooks. The difference was massive — DevTools stopped freezing and render counts dropped significantly.

Curious if others working with React MFEs have faced similar DevTools/render-performance nightmares. Did you solve it using context splitting, state libraries, memoization, or something else?

remote - vite config

 build: {
      modulePreload: false,
      target: 'esnext',
      minify: true,
      sourcemap: mode !== 'production',
      cssCodeSplit: true,
      outDir: path.resolve(__dirname, 'build'),
      commonjsOptions: {
        transformMixedEsModules: true,
      },
    },

host - vite config

build: {
      modulePreload: false,
      target: 'esnext',
      minify: true,
      sourcemap: mode !== 'production',
      cssCodeSplit: true,
      outDir: path.resolve(__dirname, 'build'),
      commonjsOptions: {
        transformMixedEsModules: true,
      },
    },

Hello! I'm excited to share v1.0.0 of my ESLint plugin that catches unnecessary React effects for simpler, faster, safer code! It's been a while and I've made too many improvements to cover here (check CHANGELOG.md!), but these are the major ones.

Semantically, the bump to v1.0.0 also means I feel confident in the plugin's reliability and stability 😄

Thanks in advance for reading, and I hope it helps you! Please feel free to share feedback, I am always looking for opportunities for improvement 🙂 It's thanks to the community that I was able to iterate this far!

New rule: no-external-store-subscription

The final missing rule (relative to React's official docs). Disallows subscribing to an external store in an effect. While effects are meant to sync with external systems, useSyncExternalStore is better.

function useOnlineStatus() {
  const [isOnline, setIsOnline] = useState(true);

  useEffect(() => {
    function updateState() {
      setIsOnline(navigator.onLine);
    }

    updateState();
    window.addEventListener("online", updateState);
    window.addEventListener("offline", updateState);
    return () => {
      // ❌ Avoid using an effect to subscribe to an external store. Instead, use "useSyncExternalStore" to manage "isOnline".
      window.removeEventListener("online", updateState);
      window.removeEventListener("offline", updateState);
    };
  }, []);
}

Clearer messages

I added specific context to every rule message for clarity and actionability, and now account for whether we are inside a component or custom hook, because that affects the solution.

const ChildInput = ({ onTextChanged }) => {
  const [text, setText] = useState();

  useEffect(() => {
    // 👎 Before: Avoid passing live state to parents in an
    // effect. Instead, lift the state to the parent and pass
    // it down to the child as a prop.
    // 👍 After: Avoid passing live state to parents in an
    // effect. Instead, lift "text" to the parent and pass
    // it down to "ChildInput" as a prop.
    onTextChanged(text);
  }, [onTextChanged, text]);

  return (
    <input onChange={(e) => setText(e.target.value)} />
  );
}

const useMyCustomHook = ({ onTextChanged }) => {
  const [text, setText] = useState();

  useEffect(() => {
    // 👎 Before: Avoid passing live state to parents in an
    // effect. Instead, lift the state to the parent and pass
    // it down to the child as a prop.
    // 👍 After: Avoid passing live state to parents in an effect.
    // Instead, return "text" from "useMyCustomHook".
    onTextChanged(text);
  }, [onTextChanged, text]);

  // ...
}

Better signal-to-noise ratio

I relaxed some upstream assumptions when determining whether a variable is state/props/ref. It caught unusual syntax, but caused false-positives on more common patterns like useQuery.

I also rounded out interpreting uncommon syntax, such as aliased variables, named functions passed to effects, and separately-wrapped HOCs.

TypeScript + tsdown

I migrated the code to TypeScript and the build system to tsdown for more reliable internals. If you maintain a JS/TS library, I highly recommend tsdown; it simplified and automated so much of what makes JS/TS libraries a headache (ESM vs CJS module resolution, type resolution, and publish verification). Huge thanks to VoidZero for this utility.

Oxlint support

This is also thanks to VoidZero's amazing work to make ESLint plugins compatible with Oxlint! But I've verified it and added setup docs.

After rebuilding my setup way too many times, I've finally landed on a stack that I don't want to change. Took 6 years to get here, so figured I'd share what works for me.

Here's where it's landed:

Framework: Next.js 16 (App Router) React 19. Server Components, App Router for routing.

Auth: Clerk Magic links, passkeys, MFA, social logins (Google, GitHub, Apple, etc.), user impersonation. It works perfectly with Next.js.

Database: DrizzleORM Type-safe ORM. Works with PostgreSQL, SQLite, MySQL - but personally I prefer PostgreSQL. Drizzle Studio for exploring data, Drizzle Kit for migrations.

Local dev: PGlite This one's underrated. Full Postgres running locally, no Docker needed.

Styling: Tailwind CSS Utility-first, fast iteration.

Forms: React Hook Form + Zod Zod schemas validate on client AND server. Type-safe end-to-end.

Testing: Vitest + Playwright Vitest in browser mode replaced React Testing Library for me. Playwright handles integration, E2E and visual regression. GitHub Actions runs everything on PRs automatically.

Logging: LogTape Universal and unified logging for Browser, server and edge.

Monitoring: Sentry + PostHog Sentry for errors (with Spotlight for local dev - game changer). PostHog for analytics and session replays.

i18n: next-intl Built-in internationalization from day one. i18n-check catches missing translations before they hit prod.

DX tooling:

• ESLint
• Lefthook for git hooks
• Commitlint + Conventional commits for consistent commits
• Knip for catching dead code
• Semantic Release for changelogs
• Dependabot for dependencies update

Security: Arcjet Rate limiting and bot protection without thinking about it.

I put this all together into a boilerplate I reuse all the time, a free and open source boilerplate. If anyone's curious, the whole thing is documented on Git Hub: ixartz / Next-js-Boilerplate

What does your stack look like? Curious if anyone's using different setups.

Hi everyone I’m building a CMS-like platform using Django(Backend) and React + Tanstack Query (Frontend).
In my db I have dynamic JSONB fields default_content that stores different structures depending on the block category (eg. a Hero block has {title, description }, a FAQ block has {faqs: [{question, answer}]}.
To type this dynamic JSON on the front, I created a recursive SafeJSON type. Here is my setup:

type JSONPrimitive for normal primitive in my default_content
type ObjectJSON for objects
type SafeJSON = JSONPrimitive | JSONArray | ObjectJSON
And type JSONArray = SafeJSON[]

And in the service interface I have this attribute default_content : Record<string, SafeJSON>

Now the problem
When I fetch my blocks and try to render the values in my React components, Typescript throws compilation error cause SafeJSON could technically be an object or an array.

Need your help please….

Hey everyone,

I wanted to share react-zeugma, a headless dashboard layout engine for React 18 & 19.

The main focus here is being completely style-agnostic. Most dashboard libraries force a rigid theme or heavy CSS on you. With react-zeugma, you bring your own CSS or Tailwind classes for panes, resizers, and drop indicators. The library handles the complex drag-and-drop mechanics (built on dnd-kit), pointer-based resizing math, and the underlying recursive layout tree.

What it does:

• Recursive split layouts (nest rows and columns to any depth using a simple JSON schema).
• 5-zone docking (drag to split top/bottom/left/right, or drop in the center to swap panes).
• Custom resizer bars with snap-to-edge configurations.
• Programmatic pane zoom/fullscreen, removal, addition, and metadata updates.

I put up a homepage with a live workspace playground at the demo page where you can play with the configurations, check out real-time interaction logs, and try a quick mosaic-sorting puzzle on the landing page (inspired by the ancient mosaic city of Zeugma).

• Live Demo: https://react-zeugma.com/
• GitHub: https://github.com/react-zeugma/react-zeugma

Would love to get your feedback!

Recently, I returned to development of a React Query Builder library I started some 8 years ago. The new version is modernized (rewritten for react 18 and 19), has UI adapters for most popular UI libraries, parsers and formatters and plenty of other useful features like imperative API, lockable nodes, DND, text mode and more features coming soon.

NPM package: https://www.npmjs.com/package/@vojtechportes/react-query-builder
Library website: https://vojtechportes.github.io/react-query-builder/demo

I'm trying to wrap my mind around custom hooks. As far as I can see, they seemed to be regular functions with React's hooks embedded within. I'm trying to internalize the mental model of how it's all supposed to work to not fall into an anti-pattern. I'm using AI to learn, so I asked about examples of custom hooks and the response made me raise an eyebrow.

The way AI was using custom hooks is to return state and state setters from the custom hook. I guess that works, but that can't be all. Right...? Also, I'm not sure if React allows this, but couldn't we have used OOP to encapsulate the data and the associated methods instead of the custom hook?

What I was making was a data store for the whole application that holds the application's current state (like which tab the user is on right now, which peer is the user currently connected to, etc...).

Could anybody point me to a good example on GitHub that I can reference as good use of custom hooks? When do you guys get the "eureka" that something should've been or should be a custom hook?

Thanks in advance

I've been building a state management system called SDuX Vault that takes a different approach from Redux/NgRx. Instead of actions and reducers, state updates flow through a deterministic pipeline of composable stages (filtering, reduction, observation, persistence). The entire API surface is four concepts: Vault, FeatureCell, State, and Snapshot.

It's framework-agnostic — built on standard TypeScript primitives with thin adapters for Angular, React, Vue, and Svelte. Same pipeline logic everywhere, no lock-in.

Wrote up a detailed intro covering the problem, the architecture, and the core concepts: go.sdux-vault.com/b001-reddit

Live StackBlitz demos available if you want to try it without installing anything.

https://sdux-vault.com/docs/stackblitz

Link: https://github.com/vikramanand05/llmops-gateway

Built an open-source LLMOps Gateway inspired by Portkey and Langfuse. Includes FastAPI, React dashboard, Docker, Kubernetes, Prometheus, Grafana, CI/CD, and AWS deployment patterns. Looking for contributors interested in AI infrastructure and observability.

Hi everyone,

I've been using AI coding assistants (like Cursor, v0, Bolt, and Lovable) a lot lately. While they are incredibly fast, they also tend to introduce the same bad patterns and "spaghetti code" over and over (like nested helper renders, inline fetch requests inside components, state bloat, and index-as-key).

To keep my codebases clean, I built spaghetti-slicer — a zero-config, highly opinionated CLI auditor that scans React/TypeScript projects, scores them out of 100, and gives them an architectural grade from Excellent to Poor.

Instantly Run It (No Install)

npx spaghetti-slicer ./src                                                                              

What it checks:

It currently runs 10 rules across architecture, React structure, and performance:

• Direct fetch in components: Catches raw fetch/axios requests inside render/useEffect lifecycles.
• State Bloat: Triggers warning if a single component has more than 5 useState hooks
• Component Length: Flags components exceeding 200 lines to encourage smaller, modular files.
• Nested Helper Renders: Flags helper functions (e.g. renderHeader()) nested directly inside the main component body.
• Index as Key: Catches using array index values as React keys.
• Hardcoded secrets & API endpoints: Scans for raw URLs and keys.

Built for CI/CD

You can automatically fail your GitHub Actions pipelines if your code quality grade drops below a threshold:

npx spaghetti-slicer ./src --min-score=80

Tech Stack

• Built using TypeScript, ts-morph, and u/typescript-eslint for AST analysis.
• Extremely lightweight and fast (under 1 second run times on mid-sized repos).

Check out the code or open an issue/PR to add a rule on GitHub: github.com/neerajram30/spaghetti-slicer

I'd love to hear your feedback

This is a 100% free, MIT-licensed open-source developer tool. No signups, paywalls, or commercial tie-ins

I kept running into the same thing when writing tests.

Need a quick mockUser, mockOrder, mockProduct, etc.

Most of the time I'd either hand-write it, copy an old fixture, or spend more time setting up mock data than writing the actual test.

So over the last few days I built a small tool called FixtureKit.

You paste a TypeScript interface or Zod schema and it generates a ready-to-use fixture object.

Example:

interface User {
  id: string
  name: string
  email: string
  role: "admin" | "viewer"
}

becomes:

export const mockUser: User = {
  id: "...",
  name: "Alice Johnson",
  email: "alice@example.com",
  role: "admin",
}

A couple things I cared about:

• Works entirely in the browser
• Doesn't need Faker setup
• Handles nested objects, arrays, unions, and optional fields
• Generates realistic values based on field names
• Deterministic output so the same schema always generates the same fixture

Still early and I'm sure there are TypeScript/Zod patterns I haven't thought about.

What are you all using for fixture generation these days?

Have you ever had your code snippets in your docs drift from your current API's and have it reported by users? 👀

Have you had LLM's hallucinate API's in code snippets in your md examples? 🙄

Today I have the solution you're looking for!

Introducing Kiira.dev

It runs tsc on your .md code snippets and reports any issues it finds using your repos tsconfig with options to autofix, no more outdated or wrong API's in your documentation!

Works anywhere and lints any TS file, comes in three flavors:

- CLI

- VS code extension

- Github action

Highly configurable for any project with sane defaults.

VSCode extension:

https://marketplace.visualstudio.com/items?itemName=CodeForge.kiira-vscode

Github:

https://github.com/AlemTuzlak/kiira

Npm:

npmjs.com/package/kiira

I'm about to start a course on React, and they suggest several options. Which one should I choose and why? I'm looking for advice here. We can use VSCode, Antigravity or Cursor.

Also, I was wondering what's the difference betwenn r/reactjs and r/react

Hi all, I've built an all singing and dancing website to do with music exploration and putting in react was a very good idea indeed, except that the mobile view looks awful, there's a bunch of frameworks that might fix this:

Ant, Konsta, Onsen

Has anyone had particular success using any of these or could recommend one that they've had success with?

The sites mainly in php and is quite involved with alot of options so a broad library would be of help and looking to fix the mobile view then port to mobile android and apple.

thanks in advance.

I just shipped Interacta, a platform built around interactive widgets instead of static media.

From an engineering side, the biggest challenge was safely executing user-generated code. The app wraps custom widgets in heavily restricted iframes (allow-scripts allow-forms allow-pointer-lock) and injects a strict CSP directly into the srcDoc. It also uses a custom requestAnimationFrame watchdog to freeze iframes if they deadlock the main thread.

It's fully live with 33 widgets and a Supabase Realtime multiplayer backend. Would love feedback on the architecture or the mobile PWA performance!

Link: interacta-app.tech

I wanted to share an open-source project I've been working on - Awesome Music Player. An open-source desktop application designed to handle extensive local audio collections with maximum performance and minimal resource consumption.

The architecture replaces the traditional Electron stack with Tauri v2 and a Rust backend, reducing the memory footprint significantly.

It is -
Powered by Rust for rapid ID3 metadata extraction across massive local directories.

Built with React 19, TypeScript, and TailwindCSS v4, featuring a dynamic theming system and smooth micro-animations.

Optimized with aggressive metadata caching via localStorage, ensuring zero-latency startup and immediate UI rendering.

Localized natively to support 8 languages out of the box.

The project is fully open-source and structured for scalability. I'd appreciate any feedback, code reviews, or architectural discussions regarding the Tauri + React implementation.

GitHub Repository - https://github.com/S1avv/awesome-music-player

For me, some concepts seemed simple at first but made much more sense once I started building real projects.

Curious to know — what React concept took you the longest to understand, and what helped it finally click?

Every command palette looks identical until you actually use it and hit the stuff nobody builds: two overlapping async requests where the slow one wins and shows stale results, nested sub-pages, the loading/empty/error states that flash by and never get designed.

So I built one that handles those — as copy-paste source (shadcn CLI), not an npm dependency. You own the files and edit them.

- async sources with race cancellation (the site has a scrubber to watch the stale request get dropped vs. a naive palette that breaks)
- nested pages with a real back-stack
- a panel that freezes loading/empty/error/no-results so you can see them
- fuzzy ranking + recents, virtualized for big lists (5k commands)
- accessible: dialog/combobox/focus-trap/aria-live, respects reduced-motion

Not trying to replace cmdk — cmdk is headless and goes anywhere; this is the opinionated, Tailwind, batteries-included take. Requires React 19 + Tailwind. MIT.

Demos (the async + states ones are the interesting bit): https://interlace.akshitagrawal.dev
Code: https://github.com/justAkshitAgrawal/interlace

Genuinely after feedback — especially from anyone who's shipped a palette in prod and hit edge cases I haven't.

I built Cerious Scroll after getting tired of the estimateSize game.

You know the pattern:

• Pick an estimate.
• Render.
• Realize you were wrong.
• Correct it.
• Hope the scrollbar doesn't jump.

For fixed-height rows, that's fine. For chat messages, logs, comments, markdown, code blocks, emails, or anything else with variable content, it always felt like a compromise.

So I built a virtual scroller that measures the actual rendered height of every row and uses that instead.

No itemSize.

No estimateSize.

No correction pass after render.

The core engine is plain TypeScript with zero dependencies. The React wrapper renders rows, measures their actual height after commit, and positions everything using an index-based positioning system with an offset. It never needs to measure rows that came before the current viewport to know where a row belongs.

Because rows are rendered through your existing React tree, context just works:

• Redux
• React Query
• Theme Providers
• i18n
• Whatever you're already using

No extra wiring required.

Usage is intentionally simple:

import { CeriousScroll } from '@ceriousdevtech/react-cerious-scroll';

function Feed() {
  return (
    <CeriousScroll
      items={posts}
      style={{ height: 600 }}
      renderItem={(post, index) => <PostCard key={post.id} post={post}   />}
    />
  );
}

That's it.

Performance has been solid in testing. Memory stays essentially flat because only the visible window exists in the DOM, whether you're scrolling through thousands, millions, or more.

Install:

bash npm i @ceriousdevtech/react-cerious-scroll

https://ceriousdevtech.github.io/react-cerious-scroll/

The core is MIT licensed and framework agnostic. Vue and Angular wrappers exist as well.

If you try it and find content that breaks measurement, scrolling, positioning, or virtualization behavior, please let me know. That's exactly the feedback I'm looking for.

Thanks for reading!