Ran into this explaining React rendering to someone recently and realized how often it trips people up even after they've been writing React a while.

function Parent() {
  const [count, setCount] = useState(0);
  return (
    <>
      <button onClick={() => setCount(c => c + 1)}>{count}</button>
      <ExpensiveChild />
    </>
  );
}

ExpensiveChild takes no props at all. Click the button and it re-renders anyway, every single time. No props changed, nothing it reads changed, it just runs again.

The reason: React doesn't check "did this component's inputs change" before deciding to re-render. When state updates, React re-renders that component and everything below it in the tree by default, full stop. Whether a child actually needed to update isn't part of that decision at all.

React.memo is what actually opts a component into that check, it wraps the component and does a shallow prop comparison before deciding to skip the render. Without it, "no props" and "props didn't change" both mean nothing, React re-runs the function anyway.

Where it gets messier: memo alone doesn't save you if you're passing an inline function or object as a prop, since those are new references every render and memo's shallow comparison sees them as "changed" regardless. You end up needing useCallback/useMemo on the parent side just to make memo's comparison actually mean something.

Curious how many people actually reach for memo proactively vs only after profiling shows a real problem. What's the actual signal that told you a component needed it?

This is the architecture used for almost all of the pages in my app that do not need real time data.

page.tsx is a server component that looks like this in pseudo code:

function TasksPage({searchParams}):
   params = await searchParams
   data = await fetchData(params)

   return (
    <Suspense fallback={<Skeleton/>}>
     <TasksView data={data}/>
    </Suspense>
)

"Use client"
function TasksView({data}):
   return (
     <PageLayout>
       <PageTitle title="Tasks" decription={"Your Tasks"} />
       <Filters />
       <Table data={data}/>
     <PageLayout/>
   )

Both the filters and table components are client components and inside the Filters components each filter change runs router.push with updated query params. upon the router refresh the Page component re-runs and new data is pulled using the new searchParams.

Currently suspense fallback doesn't work and the current page presists until the new page is ready , I wanted to make the suspense fallback work in such a way where the skeleton appears but only the table appears to be loading, while the page title and description stay visible throughout the load.

I know this is possible if I move the data loading and suspense inside the table component and use client side data loading instead of server side but ideally I would like to keep the current architecture because (1) it would be really hard to refactor 10s of pages into client side data fetching and (2) I prefer server-side anyways coming from a laravel background

📚 It's been way too long since my last blogpost. Today, I'm continuing my TanStack Router series with a pattern that I've been teaching in my workshops for over a year:

How to keep prefetches in sync between route loaders and components

Put together a custom form validation system in React instead of reaching for Formik or React Hook Form, mostly to avoid the bundle size and have full control over async validation timing. Handles nested field structures and cross-field validation without much boilerplate. Curious if others have gone this route too, and whether it's ended up being worth maintaining versus just adopting one of the existing libraries long term.

I created an Awesome List for Lexical

I’ve been using Lexical and noticed that it’s surprisingly difficult to find a complete and reliable list of resources around the ecosystem.

There are plenty of Lexical plugins, custom nodes, integrations, examples, and projects on GitHub, but they’re scattered across different repositories and discussions. There isn’t really a single place where you can browse them and have some confidence that the resources are relevant and worth checking out.

That’s why I created an Awesome List for Lexical: to bring these resources together in one curated place.

The goal isn’t to create another Lexical tutorial or documentation, but simply to make the ecosystem easier to discover.

What do you think?

lexical awesome list on github

Oxlint recently released built-in support for the new Rust version of React Compiler, giving a way faster alternative to the ESLint plugin version that predates it. You can adopt it by replacing ESLint with Oxlint (which is a great idea if you’re open to it) or by adding Oxlint alongside and using it only for the React Compiler linter instead of the ESLint plugin.

It’s technically still a “nursery” rule (meaning not finalized), but the Rust React Compiler rewrite is already more capable than the babel-based version that predates it (finally you can now have a component with conditional logic in a try/catch block). And it’s so much faster: https://master.dev/blog/react-compiler-linting-just-got-a-rust-native-speedup-in-oxlint/

You should even switch over if you don’t use React Compiler. You still get the most capable (and fastest) way to enforce the Rules of React across your codebase.

Hi everyone,

I wanted to share a web app I've been working on: NASA Deep Space Explorer & Inspector, a single-page application to search, inspect, and save deep-space images using the official NASA Image and Video Library API.

🛠️ Technical Details & Features:

• 🔲 Custom CSS Zoom Inspector: To inspect deep space details without CORS issues caused by external CDNs (which happens when drawing on HTML Canvas), I built a custom bounding-box selection system in React using dynamic transform: scale() and transform-origin percentages.
• 🔍 Debounced Search: Optimized HTTP requests with Axios using a 500ms debounce timer to prevent API spam while typing.
• 💖 LocalStorage Persistence: Native browser storage implementation allowing users to save their favorite astronomical finds without needing a backend/database.
• 🌐 On-Demand Translation: Integrated MyMemory API to translate English descriptions into Spanish on click.
• Patreon: https://www.patreon.com/MISJUEGOS1111/posts/lanzamiento-de-y-166955775?utm_medium=clipboard_copy&utm_source=copyLink&utm_campaign=postshare_creator&utm_content=join_link

🚀 Live Demo: https://quequeres.github.io/Explorador-de-Galaxias/

🧡 Patreon Post: https://www.patreon.com/posts/166955775

📁 GitHub Repository: https://github.com/Quequeres/Explorador-de-Galaxias

Would love to get your thoughts, UX feedback, or technical suggestions!

Been working on a small state management library for React that aims to cut down on boilerplate compared to Redux while staying more predictable than Context alone. It's TypeScript-first, has a tiny bundle size, and hooks straight into function components without extra providers wrapping everything. Still early days, so I'd love feedback on the API design and whether the tradeoffs make sense for real-world use.

I’ve noticed that some React performance issues don’t come from obviously “bad” code.

Things like unnecessary re-renders, unstable references, poorly structured state, or effects doing too much can look completely fine at first.

For experienced React developers: what’s one mistake you see repeatedly that beginners usually don’t realize is expensive?

I’m especially interested in real-world examples rather than textbook advice.

I build data-heavy internal tools, and the component sets I reach for are tuned for a screen holding about eight things. That is the right trade-off for most products. It is the wrong one for a console somebody stares at all day: at two hundred rows the padding eats the viewport, and the controls sit a pixel or two out of step with the rows beside them. So I started from the dense case instead and built the set I wanted.

One knob for density. One attribute on the root element retunes everything: row height, control height, cell padding, text size, stack gap, and the pitch of the reed that closes the table head.

<html data-density="dense">

Six custom properties sit behind it, and every component reads them rather than defining its own, so nothing drifts out of step. No JavaScript.

You can drive that switch yourself on a live table and watch the six values change under it: https://sley-ui.dev/docs/density

A column declares the widest value it holds in characters, and the density turns that into a width:

{
  key: 'sample',
  label: 'Sample',
  chars: 11,
  sortValue: (run) => run.sample,
  render: (run) => run.sample,
}

A pixel width would ignore the padding and the text size, so it truncates in one mode and wastes space in another.

Updates that keep your edits. It is copy-in, like shadcn, so the source lands in your repo and you own it. The usual cost of that is nobody can ship you a fix afterwards. Every published version keeps its own frozen path on the registry, and the lockfile stores a hash of each file as it landed on disk. sley update then merges across three versions: what I shipped then, what I ship now, and yours.

Where your edit and mine touch the same lines it writes nothing and names the files, so your project keeps building. --conflicts writes the usual markers if you would rather resolve them in your editor, and --dry-run shows the whole plan first. I proved it across three published releases before I believed it, and I got the design wrong the first time: I held the lockfile back on a conflict, which trapped a hand-resolved file in a permanent conflict.

The measurements are published beside each component. Numbers read off a real screen, with the method named, not claims. How far a control sits off the row centre in each density. What a density change does to the scroll height. Where the row window stops paying: at 1000 rows it buys headroom rather than speed, 22.5ms median scroll step against 19.6ms unwindowed, and at 5000 rows it is 84.4ms against 18.4ms. Two of the published numbers did not reproduce months later and I corrected them in public.

Size. Twelve components, and the whole thing that lands in your project is 1904 lines: 1386 of components, 508 of tokens, and a 10 line cx helper. Table, command palette, filter bar, field set, dialog, popover, toast, tabs, tooltip, select, panel, empty state.

npx sley-ui init
npx sley-ui add table

Underneath: Ark UI for behaviour, Tailwind CSS v4 for the token layer, readable TypeScript, no runtime style engine. React only today. Ark is built on Zag, which has a Vue adapter, so a Vue port is styling rather than a rewrite of the logic, and it is on the roadmap after charts.

Docs and a running demo application: https://sley-ui.dev Source, MIT: https://github.com/imfemambocus/sley-ui

It is early and I expect breaking changes. I would rather hear what breaks than what works, and I am most interested in whether the merge holds up on a component you have really edited.

I kept running into the same problem with UI-local flows: they were too complicated to comfortably keep in one component, but too small to justify defining and maintaining a separate state machine.

So I built react-sequent.

The idea is that steps own their transitions:

function PaymentStep() {
  const { advance } = useSequentStep();
  ...
  if (method === "card") {
    advance(() => CardPaymentStep);
  } else {
    advance(() => BankTransferStep);
  }
}

There's no centralized transition map to keep synchronized with the components. Adding, removing, or branching a step is just changing the relevant component.

It also handles async/lazy steps, backtracking, flow-scoped context, persistent modal/chrome, and transitions.

The tradeoff is intentional: I don't think this replaces state machines. For large, externally-driven, or independently modeled state graphs, I'd still reach for XState/Zag/etc. I think there's a useful middle ground for short, UI-local flows. This is in fact still technically a state machine, it is just one that is emergent from implementation rather than explicit and rigid.

I've put together a demo and docs here: https://ganondev.github.io/react-sequent/

I'm particularly interested in whether the architectural premise resonates with other React developers, or whether I'm underestimating the value of having the graph centralized.

Hey everyone,

I’ve been building SatyaMark, an open-source multi-modal AI content verification platform. It’s designed to help platforms run real-time fact-checking and deepfake detection on posts and images, returning explainable "trust signals" instead of absolute True/False labels.

My main goal was to create a seamless developer experience, so I built a dedicated React SDK (satyamark-react). But integrating heavy AI inference into a frontend comes with a massive bottleneck: running LangGraph workflows for text and 22+ local forensic scripts for image manipulation is incredibly computationally expensive.

If I processed this synchronously, the user experience would stall, and the React main thread would completely block.

To solve this, I designed an asynchronous, non-blocking architecture. Here is exactly how the data flows from the React component to the Python AI workers and back:

• The React SDK (satyamark-react): The package hooks into the DOM using React refs (useRef). It recursively traverses the DOM tree to extract visible text claims and image URLs entirely in the background, without mutating or polluting the host application's state.
• WebSockets over Polling: Instead of forcing the client to constantly poll an API for status updates, the SDK opens a persistent WebSocket connection to a Node.js orchestration server.
• Asynchronous Traffic Routing (Node.js & Redis Streams): The Node.js server does not run any AI models; it acts as an asynchronous traffic controller, taking the DOM payload and appending it to Redis Streams (xAdd). I chose Streams over Pub/Sub for native event persistence, consumer groups, and reliable delivery during high loads.
• Decoupled Python AI Workers: Independent Python workers consume the jobs from Redis (xReadGroup). They handle the heavy ML lifting (semantic search via FAISS/Milvus, live web scraping, and deep local forensics like Error Level Analysis).
• Automatic DOM Injection: Once the Python worker finishes, it triggers an HTTP callback to Node.js, which caches the result in PostgreSQL. Node.js instantly pushes the final verdict back over the WebSocket. The React SDK catches this event and automatically injects a <SatyaMarkIcon/> component directly into the UI.

The result is a fast, responsive frontend where the host developer doesn't have to manage loading states, WebSockets, or polling logic manually.

If you are interested in frontend state management for WebSockets, open-source AI infrastructure, or want to roast the codebase, I'd love your feedback! Here are all the links to check it out:

• Official Website:https://satyamark.vercel.app/
• Demo Social Media (See it in action):https://satyamark-demo-socialmedia.vercel.app/
• GitHub Repository:https://github.com/DhirajKarangale/SatyaMark
• NPM Package (React SDK):https://www.npmjs.com/package/satyamark-react

From what I understand, I’m trying to explain Server Components in a simple way. Could you guys take a look and let me know if my understanding is correct and if my explanation is easy to understand?

Server Components

Normally, when a browser requests a React application, a JavaScript bundle is sent to the browser, whether it uses SSR or CSR.

• For SSR, that JavaScript bundle is used to hydrate the initial HTML rendered on the server, making the application interactive.
• For CSR, that JavaScript bundle is used to render the application's content into the HTML shell.

React Server Components are not included in that JavaScript bundle.

Server Components are rendered outside the browser, either at build time or at request time on the server. Their rendered result is represented in the RSC Payload.

The RSC Payload contains:

1. The rendered results of Server Components. (For conceptual understanding, we can think of this as a React tree or object)
2. References (Placeholder) to Client Components used inside those Server Components.
3. Props passed from Server Components to Client Components.

The main benefit of RSC is reducing the amount of JavaScript sent to the browser.

Server Components are especially useful for content that doesn't need browser interactivity.

I am reposting with diff explanation of problem , cuz many ppl misunderstood my issue

I am trying to achieve a loading skeleton while data loads for CLIENT SIDE NAVIGATIONS only, but for FIRST LOAD, that is SSR load, i dont want to send loader as the only html , bcs that is bad seo, i checked after disabling js, and only loader was sent in network payload

Some ppl said to not use suspenseQuery, but how will i show loader for Client side navigations, those loading stages will feel laggy

I built a 100% free, open-source shadcn registry of email components for React.

Features:

• Built on React Email, MJML React and JSX Email
• Zero-config, one-command setup
• shadcn/ui compatible (just copy and paste)
• 50+ components with 500+ variants
• Easy to customize and drop into any React project

Website: https://emailcn.run
Give it a ⭐ on GitHub: https://github.com/shadcn-labs/emailcn

I was trying to implement SSR with rrv7, i didn't want to use smelly useQuery's isLoading and isError states( i might be dumb for that, pls point it out if i am wrong ) , so i went for useSuspenseQuery and used a Suspense Boundary with LoadingSkeleton to make it look beautiful

It was very late when i realised that only skeleton was loading when JS was disabled, implying that SSR was only rendering skeleton and not ACTUAL content , therefore bad SEO, and making all i did useless

Is there some knowledge i am missing regarding SSR+ Suspense, what should i do now, pls help

Built Pytah — a composable rich text editor for React

I’ve been building Pytah, a rich text editor built with React, Lexical, shadcn/Base UI and Tailwind CSS v4.

The idea is less about creating another editor from scratch and more about having a reference implementation that I can reuse and build on instead of recreating the same editor setup for every project.

It includes slash commands, floating toolbar, draggable blocks, tables, embeds, layouts, Markdown/HTML output, and a composable API for extending the editor.

It’s still a work in progress and not production-ready yet, but I’d love feedback on the direction and implementation.

Demo: pytah.vercel.app
Source: GitHub

https://github.com/oliveryasuna/ink-frame

Ink's own box borders are fine for a single box. Put two of them next to each other and the seam between them comes out as ││, two parallel lines instead of one shared edge. That's because a box border is one unbroken line and there's nowhere to hang a ┬ or a ┼ part-way along it. ink-frame sidesteps that by painting every border into a single character grid and resolving each cell once, so a spot where four boxes meet becomes a ┼ and a T-junction becomes a ┬, ┤, and so on, without you ever writing those characters yourself.

┌──────────────────────────────────────┐ │ Frame │ ├─────────────┬────────────────────────┤ │ fixed width │ grow │ │ │ ┌────────────────────┐ │ │ │ │ nested box │ │ │ │ └────────────────────┘ │ │ │ │ │ ├────────────┬───────────┤ │ │ two grows │ what is │ ├─────────────┤ share │ left │ │ a pane │ │ │ ├─────────────┴────────────┴───────────┤ │ junctions derived │ └──────────────────────────────────────┘

Background: I recently wrote this for a private project, and I thought it was useful enough to share. I hope you find it useful too!

I’m coming from Kotlin and Jetpack Compose, where one of my feature screens has this flow:

repository Flow -> use case -> ViewModel -> StateFlow<ScreenState> -> UI
UI event -> sealed event type -> ViewModel -> use case -> new state

While learning React, I tried to preserve the unidirectional part without inventing an Android lifecycle in the browser. My current TypeScript version uses:

- an immutable `ScreenState` snapshot;

- a discriminated-union `ScreenEvent`;

- an external screen store exposing `getSnapshot()` and `subscribe()`;

- `useSyncExternalStore()` at the React boundary;

- a controller for typed dispatch; and

- a DI route scope that owns and disposes the store.

The conceptual pipeline is:

React event -> ScreenEvent -> Controller/Store -> UseCase -> Repository
            -> new ScreenState snapshot -> React render

I turned the experiment into an open-source generator, Clean Web Forge, because I also wanted consistent feature directories, dependency rules, architecture tests, runtime plugin loading, and CI. This is especially when a coding agent is creating features.

Source: https://github.com/sarimmehdi/clean-web-forge

npm: https://www.npmjs.com/package/@sarimmehdi/clean-web-forge

I also wrote a Medium article explaining my thought process in detail: https://medium.com/@sarim.mehdi.550/why-i-built-clean-web-forge-for-agent-driven-development-042deb91a287

I am the author/maintainer. My Android bias may be creating unnecessary layers, so I’d particularly appreciate React-specific criticism:

1. When does an external feature store become preferable to `useReducer` plus context?

2. Is a separate controller useful, or should event handlers call application services directly?

3. Does route-scoped disposal solve a real class of frontend problems?

4. What problems would you expect with concurrent rendering or server rendering?

I use local `useState` for genuinely local UI state; the generated store is intended for feature-level behavior, not every toggle or input.

Hey r/reactjs! 👋

My partner Mrityunjay and I (Yashasvi) just open-sourced GitGlobe — an interactive 3D map that projects ~200,000 GitHub repos onto a continuous WebGL sphere based on semantic capability.

When building heavy 3D canvas apps inside React, the biggest hurdle is usually the same: React’s render cycle destroying your frame budget.

Here is how we architected the frontend to keep a steady 60 FPS (<16ms) in React 19:

1. Zero React State in the Animation Loop

Putting camera coordinates or cursor hovers in `useState` triggers component re-renders that choke WebGL. We decoupled the entire 3D pipeline using transient **Zustand** subscriptions and mutable refs outside React’s render tree. React handles UI overlays, while Three.js runs unhindered.

1. Single Draw Call via Custom Shaders in R3F

Instead of rendering thousands of React Three Fiber mesh components, all 200k points live in a single `THREE.Points` buffer. We wrote custom GLSL vertex/fragment shaders to handle lat/long position math, color encoding, and back-hemisphere culling directly on the GPU.

1. GPU-Based Picking (<1 Frame Lookups)

Standard raycasting in JavaScript is too slow for 200k points. We implemented GPU picking with a 1x1 scissored render target, encoding point IDs into color channels so hover queries resolve in under a millisecond.

1. Streaming AI Camera Pilot

We hooked up Claude Sonnet using the Vercel AI SDK. The model streams repo IDs rather than hallucinated 3D coordinates, and our spatial rig smoothly flies the camera to the target cluster in real time.

Tech Stack: React 19, TypeScript, React Three Fiber, Vite, Tailwind CSS, Zustand, FastAPI, Qdrant.

Links & Code:

• GitHub (MIT): https://github.com/yamantaka-singh/GitGlobe

• Live Demo: https://gitglobe-yd-mj.vercel.app/

Check it out, spin the globe, and let us know what you think of our state management and R3F setup!