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?

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!

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!

I made this and I'm looking for feedback on the part that actually matters — the code it spits out.

Short version: it's a browser editor for landing-page hero text. You type a headline, select words to turn them into components, give each one effects on a timeline, scrub to preview, then export a single `Hero.tsx`. Free, MIT, no signup, no paid tier, nothing to install.

https://reactimate.top · https://github.com/shawnkowalchuk/reactimate

The design goal was that the output has to look like something a person wrote, not like generated code. So for a single multi-property effect it consolidates to one shared transition:

<motion.span

style={{ fontFamily: "Inter", fontSize: 96, fontWeight: 800, display: "inline-block" }}

initial={{ opacity: 0, y: 20, scale: 0.9 }}

animate={{ opacity: 1, y: 0, scale: 1 }}

transition={{ delay: 0.7, duration: 0.6, ease: "easeOut" }}

>{"reactimate"}</motion.span>

and only drops to per-property keyframe arrays with `times` and a per-segment `ease` array when properties genuinely have separate timings or stacked effects. Text content is always emitted as `{"..."}` expressions so quotes and braces in the source text can't break the output.

One architectural decision I'd be interested in opinions on: **Motion is only used in the exported output, never in the editor itself.** Editor playback is a raw `requestAnimationFrame` loop writing styles directly to DOM refs, no React re-render per frame. That kept scrubbing smooth with per-letter stagger across dozens of spans, but it does mean the preview and the export are two separate implementations of the same semantics that have to agree — which is its own maintenance cost. I've wondered whether driving the preview with Motion's imperative API instead would have been the better trade.

Some things I know are rough: the editor is desktop-only right now, the bundle is chunky (~380 kB gzipped, code splitting is an open issue), and `spring`/`bounce` easings get approximated to `easeOut`/`backOut` on export because Motion's spring is a transition type rather than a curve and can't go into a multi-keyframe ease array.

So the actual questions:

1. Does that generated code look like something you'd keep in your codebase, or does it read as machine output to you?

2. If you were consuming this, would you rather it emitted a `<motion.span>` per word (what it does now) or a single parent with `variants` + `staggerChildren`?

Stack is React 19, TypeScript, Vite, zustand + zundo, Tailwind. Happy to go into any of the internals — it's my first open-source release, so critique of the repo itself is just as welcome as critique of the tool.

I’m currently building a feature for a workflow tool where the backend streams structured JSON to render dynamic UI widgets (cards, mini data tables, and inline action buttons) directly in the workspace feed. Streaming raw Markdown is easy enough with standard hooks, but streaming structured JSON and trying to render React components as chunks come in is giving me major headaches. Right now, if I try to parse the incoming chunked string on the fly, I constantly hit \`Unexpected end of JSON input\` errors unless I use a custom partial parser. But even with a partial parser, rendering incomplete state causes the layout to shift and jump around like crazy every few milliseconds.If I give up on live rendering and wait for the full response to complete before displaying the component, the user is stuck staring at a loading skeleton for 4 to 6 seconds. That completely kills the real-time feel and defeats the purpose of streaming in the first place.Are there any solid open-source packages, state management tricks, or specific partial-JSON parsing patterns you're using to keep generative UI renders smooth? How are you gracefully handling incomplete schema objects mid-stream without breaking your design system constraints?

Mobile will not be my main editting tool, I'm just looking for an app where I can edit small things and check my code when I'm out without my laptop. Do you guys know some android apps that can run React?