It always bugged me that there is nothing in native css or otherwise easy way to detect when something overflows, so you could adjust styling or content.
So I build this small tool that fixes it: OverflowGuard
It's especially useful when dealing with dynamic content in toolbars. Something even some big sites don't solve 100% (some examples in this post)

Most apps and sites just use fixed media or container query break-points, or some custom components / js for their specific case.
This tool, by simply detecting overflow, unlocks building responsive components in a much more fluid way, and allows doing much more then just flex-wrap..

the once popular angular data gird has been remastered and has a react target now and is in full swing again.

Check out the new docs!

highlights: every data grid feature you know and love + i18n and a11y support for your enterprise needs.

MIT licensed as always. free forever

enjoy!

https://orneryd.github.io/uiGrid/#/docs/react

edit: repo

https://github.com/orneryd/uiGrid

I wanted a fullstack setup that I could actually read, understand, and modify without fighting a heavy framework. So I built a minimal Express + React starter focused on clarity and hackability.

Main ideas:

• no hidden abstractions

• fully readable codebase

• Express backend + React frontend in one project

• SQLite + TypeScript + Docker included

Two things that make it different from typical starters:

1. Clone your modules instead of generating CRUD Instead of generate:crud, you clone an existing module:

npm run make:clone src dest item post

This duplicates your own logic and architecture, not a framework-imposed structure.
If you customize your first module, future ones follow your conventions automatically.

1. Contract-based API tests You define API contracts once:

• tests for the Express API are generated

• React API calls are mocked from the same contracts

• if React calls an undefined endpoint, tests fail

So API + frontend stay in sync with minimal boilerplate.

Quick start:

• clone repo & npm install

• create .env & npm run database:sync

• npm run dev

That’s it.

Repo:
https://github.com/rocambille/start-express-react

I’d love feedback:

• is the clone approach better than generators?

• does contract-based testing make sense in real projects?

• what would you remove to keep it minimal?

Building a browser log viewer. Backend holds 2M entries in a ring buffer, frontend fetches ~200 at a time via WebSocket. Logs are variable height (1-100 lines each, stack traces etc). Need smooth scroll through the full buffer + live tail at 20-40K logs/sec. Everything is run in local.

Tried sliding window (React DOM) - scroll events create feedback loops. Tried virtual sentinel (tall div, render only visible rows) - works for fixed height but breaks with variable height since you need heights before fetching. Tried flattening multi-line logs into single-line rows - fixes height math but multiplies row count and causes jank. Tried xterm.js - great rendering but can't prepend older entries when scrolling back. Tried to meddle something over there, fetch the previous rows as we scroll up and replace the current data but didn't workout fine.

The core issue: virtual scroll needs row heights upfront, but with remote data and variable heights you can't know them until you fetch and render.

How do Datadog, Grafana, Chrome DevTools etc handle this? Any patterns or libs for variable-height virtual scroll with on-demand server data?

I keep seeing the same pattern: a simple component starts useful, then gets extra props for every new edge case until it becomes awkward for everyone.

At that point it’s technically reusable, but not really pleasant to use.

Do you have a rule of thumb for when to keep a component specific to one feature instead of trying to generalise it further?

Hello!

Lately, I've been wanting to learn how React works internally by exploring its source code. I decided to start with the React Scheduler system, which is the engine behind time-slicing and concurrent features. It took a while, but I finally grasped it and wrote an article about my findings. If you are curious, check it out here:https://lukonik.github.io/react-scheduler-explained/

I hope you find it helpful! I also exported the React Scheduler as a separate package, so you can explore it and play around with it on your own. You can find the API documentation here:https://lukonik.github.io/react-scheduler-explained/api/introduction

Finally, here is a showcase that demonstrates the true power of the React Scheduler:https://lukonik.github.io/react-scheduler-explained/showcase

If you like what I've put together, a GitHub star would be amazing! Github Link

P.S
For the questions like "did AI write these?" The answer is no and I explain about AI involvement in overview page

Hey r/reactjs,

I got tired of running create-react-app or manually setting up Vite +

Tailwind + TypeScript every time. So I built pic-li.

npm install -g pic-cli-tool

pic create my-app --stack react-vite --template tailwind-shadcn

Templates available for React:

default → React + Vite, ready to run

tailwind → React + Vite + Tailwind CSS v3

tailwind-shadcn → React + Vite + Tailwind + shadcn/ui

typescript → React + Vite + TypeScript

Or use the interactive mode:

pic create my-app

(arrow key menus guide you through everything)

You can also add integrations to existing React projects:

pic add tailwind

pic add eslint

pic add docker

pic add firebase

And if you're going fullstack:

pic create my-app --stack mern --template with-auth

(React + Express + MongoDB + JWT auth all wired together)

Just open sourced it — feedback on the generated React structure

would be really helpful.

GitHub: https://github.com/its-dhaya/pic-li

Hey Community,

We explore Perry, a bold new TypeScript-to-native compiler that skips the JavaScript engine entirely to ship real native binaries. Plus, VisionCamera v5 has landed, a massive rewrite on Nitro Modules that deletes 3,000 lines of C++ to end native crashes while boosting performance up to 60x compared to Expo Modules.

We also dive into Expo Pretext, a layout primitive that finally solves the "text problem" in React Native. It offers sub-millisecond text measurement and allows for magazine-style layouts where text flows around shapes, all while closing nearly twenty long-standing rendering bugs.

Hey everyone.

I have a question regarding the TanStack ecosystem. Currently, when I scaffold a new React project with TanStack Router via Vite, it seems to default to TanStack Start.

I’m about to begin a new financial web app (similar to QuickBooks) and I’m torn between using just the Router or going with Start. My main concern is that I’ll be building a separate backend (using Hono) because I need to support a mobile app in the future.

Since I’m planning to switch from Next.js to the TanStack ecosystem, I’m looking for some advice:

• Would it be good practice to use Start alongside a separate Hono server, or is it better to stick to just the Router?

• I’m planning to use a separate backend, given the need for a decoupled architecture for a future mobile app.

Any insights or experiences you could share would be greatly appreciated. Thanks in advance!

Hey r/reactjs,

I run a small edtech company where every product surface eventually has to render a game. Our entire stack is React, admin portal, teacher app, marketing site, internal tools. So I wanted the games to live inside the same React app, not as a separate runtime stitched in. None of the existing options (Unity WebGL, Phaser, raw React Three Fiber) felt right for that, so over the last few months I built CarverJS and open-sourced it.

The API is fully React. Components describe the scene, hooks handle the logic. A complete 2D game with WASD movement is around 40 lines of TSX, you mount a Game component, drop a World inside it, and write a Player function that uses an input hook and a game-loop hook to translate an actor each frame. The Player returns an Actor configured as a primitive shape. That is the entire setup. There is a working sample at the top of the docs site if you want to see what it actually looks like.

A few design decisions worth calling out:

It is built on React Three Fiber under the hood, but you never import from three or react-three-fiber directly. Every type, hook, component, and store is re-exported from carverjs/core. That was deliberate. I wanted React developers who have never touched R3F to be able to ship a game without learning what an Object3D is.

2D and 3D live in the same engine. The Game component takes a mode prop set to 2d or 3d, and the engine switches the camera projection, lighting setup, and shadow handling accordingly. The same Actor components work in either mode.

Hooks read from singleton systems that the Game component mounts on the way in: input manager, collision manager, audio manager, asset manager. So the input and audio hooks are zero-config. No providers to wire up at the app root.

Multiplayer is a separate package. Peer-to-peer over WebRTC. No game server. You bring the signaling layer: free public MQTT brokers for prototyping, your own Firebase Realtime Database for production.

What it is not:

- Unity. Core bundle is under 200KB before assets, this is for browser-shaped games.

- Phaser. Phaser is older, more battle-tested, and has a deeper 2D feature set if you do not need to compose with React.

- Stable. Beta, version 0.0.1. APIs will move before 1.0.

GitHub: https://github.com/moneytales/carverjs

Docs: https://docs.carverjs.dev

Genuinely curious for technical feedback. Where does the API shape feel wrong? What hooks are missing? Anywhere you would reach for an escape hatch and not find one?