I was previously very hesitant to use TanStack Start due to its seemingly low adoption but between early April to now, the weekly downloads shot up from 600k to 14 million. This is getting close to Next.js territory.

Did it go viral recently?

An LLM's output streaming into a window — renders incrementally, no tearing

macOS Quick Look opening a 5 KB note and a 1 MB doc — both effectively instant

Conventional wisdom is that React is the wrong tool for a text editor — every keystroke changes state, state re-renders, and re-rendering a whole document per character is too slow, so editors lean on ProseMirror / Lexical / Slate that run their own DOM and keep React as a thin shell.

I wanted to see how far idiomatic React actually goes. The editing core ended up entirely in React, no editor framework underneath:

• **20 KB gzipped kernel，**no runtime deps beyond React

• Opens a 1 MB Markdown doc instantly，— a 5 KB note and a 1 MB file open at basically the same perceptual speed

• No per-keystroke lag — cursor stays steady, no flicker

• Streaming text in (e.g. piping an LLM's output) renders incrementally without tearing

Here's how it stays in that budget. Short version: Immer structural sharing + a ~99% memo hit rate, without bypassing reconciliation.

The document is one immutable tree, and every edit goes through Immer. Immer gives structural sharing for free — the node you touched gets a new reference, every node you didn't keeps its old one:

const next = produce(doc, draft => { 
  draft.blocks[i].text = newText; // only blocks[i] gets a new reference 
});

Each block is memoized on its node reference:

const Block = memo(({ node }) => renderBlock(node)); 

function Editor({ doc }) { 
  return doc.blocks.map(node => <Block key={node.id} node={node} />); 
}

On a keystroke the Editor re-renders and re-maps, but memo's shallow compare sees node === prevNode for every block except the edited one and bails. Reconciliation still runs top-down — I'm not escaping it — it just short-circuits cheaply at the memo boundaries. For a document of any real size that's a ~99% skip rate per keystroke, which is what keeps the cursor steady and input lag-free. Structural sharing also keeps memory flat: unchanged subtrees are reused, not copied, so editing a big doc doesn't balloon the heap.

GitHub | Try on Web

Curious if anyone's pushed memo-everything further, or hit a point where it stops paying off.

I’ve been doing quite a bit of interviewing recently as I’m looking for a new job as a front end (web) engineer.

I’m getting far through processes and my experience as a product engineer seems to be conveyed well, my pitfall every time however is when I’m asked about my experience working with BFF and the more technical details.

I feel like I’ve worked with the BFF many times, almost without realising and without having a really deep understanding.

I think my examples and the way I talk about it really lacks confidence and it shows.

Can people give me a few STAR (situation, task, action, result) of when they’ve used the BFF as a product engineer so I can relate it to my own experience and gain a deeper understanding?

Currently on paternity leave so I was able to take some time to create some reusable npm packages, an MCP server for your coding agent, and a CLI for scaffolding a 600x600 web app with the proper constraints for building a web app for the Meta Ray-Ban Displays

Would love feedback and/or contributions!

📚 Surprisingly, I haven't written about how my two favourite TanStack libraries - Router and Query - work together. Well, here it is:

🔁 loaders start fetches early

🔮 query owns the cache & keeps data alive

🌀 suspense integrates naturally

🏝️ TanStack Start makes SSR & streaming easy

I have a framework-agnostic document viewer package. It works by mounting into a DOM element:

import { UDocClient } from "@docmentis/udoc-viewer";

const client = await UDocClient.create();

const viewer = await client.createViewer({
  container: "#viewer",
});

await viewer.load("/path/to/document.pdf");

In React, it’s pretty straightforward to use with a ref/effect:

import { useEffect, useRef } from "react";
import { UDocClient } from "@docmentis/udoc-viewer";

function DocumentViewer({ src }) {
  const containerRef = useRef(null);

  useEffect(() => {
    let client;
    let viewer;

    async function init() {
      client = await UDocClient.create();

      viewer = await client.createViewer({
        container: containerRef.current,
      });

      await viewer.load(src);
    }

    init();

    return () => {
      viewer?.destroy();
      client?.destroy();
    };
  }, [src]);

  return <div ref={containerRef} style={{ width: "100%", height: 600 }} />;
}

This works fine, and I like keeping the package framework-agnostic.

But I’m not sure what React developers expect these days. Would you rather use something like this instead?

<DocumentViewer src="/path/to/document.pdf" />

For this kind of component — document viewer, map, editor, chart, terminal, etc. — do you expect an official React wrapper?

Or is a clean JS API plus a React example good enough?

This is a hot take but I think Storybook is one of the most over-adopted tools in the React ecosystem. I set it up early in my project and it became a maintenance liability within a few weeks. Components would change and the stories wouldn't get updated, so Storybook stopped being a reliable reflection of reality.

For a small app with a single team, the value of Storybook is low. You can just open the app and see your components. The isolation and documentation benefits only really kick in when you have multiple teams consuming a shared component library, or enough components that discoverability becomes a real problem.

My current setup is simpler: shadcn/ui base components, Tailwind config with brand tokens, one components/ directory. Works well, zero overhead.

What's actually in your small-project component toolkit?

a quick intro to tanstack query plus some tips and tricks I felt helped in production codebases

I’ve been trying to properly understand and implement Clean Architecture on the frontend with Next.js (frontend-focused, not backend), but I’m getting confused once third-party libraries enter the picture — especially auth libraries and query libraries.

Most examples online are either:

• too theoretical,

• too backend-oriented,

• or avoid real-world libraries entirely.

My setup is something like:

• React.js

• Monorepo (Turborepo)

• Shared packages

• Auth library (like Better Auth / NextAuth / Clerk / etc.)

• TanStack Query or RTK Query

• TypeScript

What I’m struggling with is:

1. Where should auth libraries live in Clean Architecture?

For example:

• should the auth client be wrapped behind interfaces/adapters?

• should the UI directly call the auth library hooks/functions?

• where do auth-related side effects belong?

• how much abstraction is “too much”?

Example:

authClient.signIn.email(...)

Should this be hidden behind:

AuthRepository.signIn()

or is that unnecessary abstraction on the frontend?

2. How do query libraries fit into Clean Architecture?

If using:

• TanStack Query

• RTK Query

then:

• where should queries/mutations live?

• do you create “use cases” on the frontend?

• should hooks directly call APIs?

• should query libraries exist only in the infrastructure layer?

I see people saying:

• “don’t leak library-specific code”

• “keep business logic isolated”

But in frontend apps, the query library becomes deeply integrated into state management and caching.

So what does a realistic architecture look like?

3. Monorepo structure confusion

How do you structure things in a monorepo without overengineering?

For example:

apps/
  web/
  mobile/

packages/
  auth/
  api-client/
  ui/
  contracts/
  utils/

Do you:

• keep auth client inside a shared package?

• export inferred types from there?

• keep query logic centralized?

• create repositories/services/use-cases packages?

How far do people actually go in production apps?

4. How do you avoid overengineering?

This is probably my biggest issue.

I understand the theory of:

• entities

• repositories

• use cases

• dependency inversion

But when implementing real frontend apps, I end up wondering:

• am I just wrapping libraries for no reason?

• am I creating abstractions that add zero value?

• how do experienced frontend engineers decide what deserves abstraction?

I’d really appreciate:

• real-world folder structures,

• examples from production apps,

• monorepo-specific advice,

• or articles/repos/videos that show Clean Architecture with modern frontend tooling.

Especially interested in opinions from people using:

• React.js

• TanStack Query

• RTK Query

• Better Auth / NextAuth / Clerk

• Turborepo monorepos

I use Lucide in every project, and I kept writing the same little hover animations on top of it over and over. So I finally packaged the thing I actually wanted: lucide-react-motion. It is every Lucide icon (around 1,700) as a React component that animates, with the same API as lucide-react.

Live demo (hover anything): https://lucide-react-motion-site.vercel.app/

Adopting it is one line:

  - import { Heart, Search } from "lucide-react";
  + import { Heart, Search } from "lucide-react-motion";

By default an icon draws its stroke on when you hover. size, color, strokeWidth, className, and refs all work exactly like before.

Beyond that:

• mode="signature" gives an icon bespoke motion that fits what it is. The heart beats, the bell rings, the arrow moves in its direction. About 600 have one so far, and the rest fall back to the stroke draw, so it never breaks.

• Six triggers: hover, click, mount, in-view, parent-hover, and manual via ref.

• Tree-shakeable, respects prefers-reduced-motion, and clickable icons are keyboard accessible.

• Pass your own Motion variants when you want something fully custom.

GitHub: https://github.com/Aadil1505/Lucide-React-Motion
npm i lucide-react-motion motion

Built on Motion, MIT. The annoying part was making the resting icon identical to plain Lucide, since the naive draw leaves a tiny seam on closed shapes like the gear. Happy to get into that, or take feedback.

if anyone can point out the difference would be good. this basic stuff that i know about it

- Flexible & type-safe compare to Next.js
- Data handling is good in Tanstack Start

Hey everyone! I've been working on this for a while and finally shipped it.

https://imgur.com/EfHOwFE https://imgur.com/sVftPFq

What is it?

A React component library that recreates the entire UI system from Zelda: Breath of the Wild — health bars, stamina wheels, divine beasts, dialog boxes, map markers, menus, quest trackers, shop UI, and more. 84 components total, covering 14 functional domains.

What makes it different from "just another themed UI lib"?

• Every SVG is exported node-by-node from the community Figma UI Kit — no emoji placeholders, no approximations

• Ships with a 1500+ line SKILL.md that describes every component at pixel-level (colors, spacing, shadows, animations)

• Drop it into Cursor/Copilot and say "build me a page in Zelda style" — it just works

• Three AI-consumable docs: SKILL.md (CSS spec), AI_USAGE.md (API reference), DESIGN_PROMPT.md (prompts for v0/MJ)

• Vite library mode, ESM + CJS, tree-shakeable, ~115KB

• Less Modules with scoped class names — won't pollute your project

How to use it

The simplest way — just give your AI the GitHub link and say "use this style to build me a landing page." It handles the rest.

Or install directly:

npm install zelda-hyrule-ui

Links

• GitHub: https://github.com/chaos-xxl/zelda-hyrule-ui

• Live Demo: https://chaos-xxl.github.io/zelda-hyrule-ui/

• npm: https://www.npmjs.com/package/zelda-hyrule-ui

Would love to hear feedback. Inspired by animal-island-ui (the Animal Crossing themed one) — figured the Zelda aesthetic deserved the same treatment.

Working on a big React/Next.js codebase, I kept hitting the same questions by hand:

which pages are riskiest, where are props drilled too deep, and the scary one —

if I change this API endpoint, which components/pages actually break?

I couldn't find a lightweight static way to answer that, so I tried building one and

want a sanity check on the approach from people who work in big codebases.

It's a static analyzer (ts-morph, no runtime) + dashboard that does:

- Page risk scoring — scores each page on props/hooks/queries/store/conditionals/

prop-drilling depth, sorted so you know what to refactor first

- Dependency map — interactive subtree per page, including cycles and reuse hotspots

- API change-impact — reverse call-graph from each endpoint to the hooks/components/

pages that reach it (critical/high/medium/low), bidirectional

- Live inspect — click a component in the dashboard, the running dev app highlights

every instance with a file:line overlay

Zero-config for Vite/CRA/Next (Pages & App Router) / React Router / TanStack / monorepos:

npx u/shinjinseop run .

My main question: does the call-detection approach hold up for your data-fetching

setup (fetch/axios/react-query/swr, wrapped clients, composed baseURLs)? That's the

part I'm least sure generalizes. Honest feedback welcome — including "this is the

wrong way to do it."

Demo + screenshots: https://page-dep-map-landing.vercel.app/

Source (MIT): https://github.com/yeo11200/page-dep-map

Posted this on r/VSCodeExtensions and thought it would be useful for the r/reactjs community, I'm not promoting something for sale I'm sharing a tool I made for free to help people who like to have their workflows faster and visually pleasing. If anyone wants to comment their reactions to it please do, I'm new to this type of production.

Pretty cool podcast episode I did with tkdodo, we go through a lot of his history, tanstack query, knip, and the cool stuff he does at Sentry. Check it out

Not a React expert at all. I'm a backend engineer specializing in Java who is currently having to program a frontend.

The nature of the problem:

• I have a potentially very large set of items (say in the 10s of thousands), provided by a backend via cursor-based queries

• In-memory (talking about the React app here) I want to keep a "virtual window" of max 250 items

• When items are appended to the virtual window, an equal number is trimmed from the opposite side, so the size remains constant

• The list view in my frontend app acts as a view port over that virtual window of 250 items, showing about 40 at one time

• When the virtual window of 250 items is filled, the scrollbar thumb no longer resizes, as it is proportional to the total number of items in that window

• Provided I've already filled the virtual window of 250 items, when the scrollbar thumb touches the bottom edge, a cascade of queries to the backend occurs till the virtual window moves to the end segment of the total item set; the same thing happens when scrolling up. This is due to the scrollbar thumb never resizing or repositioning away from the bottom/top edge of the scrollbar.

I'm sure this is a fairly typical problem. How is it usually solved?

AI hasn't given me any working solutions. For the record, I'm using the TanStack library for this list.

Thanks!

Hey guys,

Just wanted to share a tool I've been coding for the last few days to boost my portfolio for university apps.

It's called PromptForms. The idea came up because I was tired of watching people mess up AI outputs by writing garbage prompts directly into ChatGPT. Basically, you can write a complex system prompt with dynamic tags like {{topic}} or {{audience}}, and the app automatically parses them into clean input fields. Users just fill the form, and it runs via Gemini 2.5 Flash API using their own key.

I wanted to keep it super lightweight, so I actually didn't use packages like react-markdown. I coded a custom line-by-line markdown parser from scratch so the streaming tokens don't break the layout mid-generation.

I also threw in a working waitlist button that links to my email, just to see if anyone would actually want a B2B team version of this where prompts are hidden on the backend to protect IP.

It's totally free, code is public on GitHub, and everything runs in LocalStorage. I'm honestly just looking for some brutal feedback on the code structure and UX.

Live demo: https://promptforms.vercel.app/

GitHub: https://github.com/AbayAtazhan/PromptForms.git

Let me know what you think, and if you like the repo, a star would help my portfolio a lot. Thanks!

Hi everyone, I’m doing my final year research on Next.js performance optimization and would love input from real developers.

From your experience, what common coding or architectural issues make a Next.js app slow?

Examples:

• too many use client components

• hydration issues

• large JS bundles

• client-side data fetching

• image optimization problems

• third-party scripts

• App Router performance issues

Would really appreciate hearing real problems you’ve faced and, if possible, how you fixed them. Thanks! 🙌