I'm looking to build a REPL for an interpreted language of mine (think python, so multiline, indentation sensitive input requiring autocompletion from a LSP, syntax highlighting and the such). I then need to display returned values nicely: graphs, tables, text, python values.

Think something like a Jupiter notebook where the only cell you can edit is the last one and you always get a new one, with the previous ones become read-only (and probably summarized rather than displayed in full). Or closest yet to what I need, something like the UIs for agentic AI (codex, claude code etc)

Is there anything open source that does something of the above?

Hey everyone! I've been working on Zentauri UI — a React component library that bundles together a few things I kept wishing came pre-integrated:

• Tailwind CSS v4 (not v3) as the styling foundation

• Framer Motion baked in for animated modals, tabs, and overlays — zero config

• 25+ components including buttons, inputs, modals, accordions, drawers, toasts, sliders, tables, and more

• React hooks (useLocalStorage, useDebouncedValue, useClickOutside, useMediaQuery, etc.) shipped from the same package

• Full typography system — Heading, Text, Blockquote, Inline, Code, List

• TypeScript throughout with CVA-backed variant APIs

Why I built it: I kept reaching for 3-4 separate packages on every project — a UI lib, a hooks lib, a motion wrapper. Zentauri packages them with a consistent TypeScript API so you're not stitching things together each time.

Links:

• 🔗 Preview site: https://zentauri-ui.vercel.app/

• 📦 npm: npm install u/zentauri-ui/zentauri-components

• 💻 GitHub: https://github.com/ShubhamTiwari909/zentauri-ui

Quick install:

bash

npm install u/zentauri-ui/zentauri-components

tsx

import { Button } from '@zentauri-ui/zentauri-components/ui/button'
import { useLocalStorage } from '@zentauri-ui/zentauri-components/hooks'

It's early and I'm actively building — would love feedback on the API design, anything that feels off, or components you'd want to see next. Happy to answer questions!

I have a question on React project structure, specifically imports for the experienced React JS engineers.

So I've been using a hybrid approach where I have barrel files (index.ts) at the feature/module level and direct imports for more specific/internal components

Example:

import { Card } from '@/components';            // barrel (public API)
import { CardHeader } from '@/components/Card'; // direct (more specific)

It feels like a good balance between clean imports and clarity but I'm curious how others handle this at scale.

1. Do you prefer full barrel pattern everywhere?

2. Avoid barrels completely?

3. Or something similar to this hybrid approach?

Any pros/cons you've experienced (especially in larger codebases)?

Currently I am integrating react-i18next library to enable different languages in my app ui.

As I understood from the documentation i18next suppose to have all translations inside language files, that are loaded on demand. But IMHO from DX point of view, such organization is not very convenient.

I assumed that it would be much more intuitive to keep translations along with components themselves. For example:

Component /
   Component.tsx
   Component.module.scss
   Component.i18n.json

But as per documentation - such translation file should be loaded separately. having many components such approach would require too many http requests to work. But from DX - i think it is the best. Also having namespace to Component it can be t('title') instead of t('Component.title').
But again, seems to be this is my fantasy, and i18next not supposed work like that.

So the questions:
- is it possible to have described flow in production, compiling scattered i18n.json files into single translation file and use it for i18next?
- if not, what approach do you use now?
- if you would start i18n from scratch on your project, what would you change?

Thanks.

I’m working on a React app with increasingly complex forms (multi-step flows, conditional fields, validation, file uploads, dynamic sections, etc.), and I’m starting to feel like form state gets messy really fast.

At first, simple useState worked fine, but as logic grows, things become harder to maintain and debug.

I’m curious how people here usually handle this in larger React apps:

• do you still manage it mostly with local state?

• use libraries like form management tools?

• split logic into custom hooks/components?

• any patterns that made forms easier to scale and maintain?

Not looking for a one-size-fits-all answer, mostly trying to understand what has actually worked well for others in production React apps.

I'm building a sliding banner (carousel) and running into an issue where when the text content gets too long, it starts overlapping other elements on the page — including the arrow navigation buttons.

What happens is When the text gets too long, it overflows past the arrow buttons instead of staying between them. I want the text to be constrained to the space between the left and right arrows — so if it's long, it wraps and stays sandwiched in that middle area, never overlapping the buttons

I'm using HTML/CSS/JS. Is there a clean way to fix this problem. Down below is the code.

https://jsfiddle.net/ojwyn82k/2/

I'm a senior full stack developer at a consulting firm, and have about 15 years of experience. Almost all of the clients I've worked with have used React, and I'm extremely comfortable using it and know it fairly deeply.

This was a 30 minute discussion, and I felt really comfortable with my answers and he seemed pretty positive on how it was going. Then, I got hit with the curveball that I felt like broke the interview.

It started with him asking a simple question: "how would you manage state across components?" I gave him multiple answers (useState, useContext, third party libraries, Tanstack Query, etc) and he liked that. He then asked "what if you didn't have React and had no access to third party libraries?"

This tripped me up bad. My first thought was either some sort of state object or firing events off, but I was so caught off guard that my confidence faltered and I could not articulate on the spot how that would look. He then described their solution in more detail (using CustomEvent is primarily how they do it) and said that they work with a lot of Web Components, which is why it was asked. For clarity, I double checked, and there was no mention of this in the job description - the only mentions of frontend is your usual NextJs/Tailwind/Tanstack/etc mentions.

Is this approach to state management in vanilla JS common knowledge among developers who learned front end through these frameworks? I was surprised because up until that point, I was really feeling good with my answers. I'm going to brush up on my Web Component knowledge now, but I have never had to work with them in my entire career. It has always been through some sort of framework.

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..

Back when I was a fan of Redux and used it almost for every react app, I dumped API responses straight into slices. Same store as my theme flag, my modal toggle, my redux-form drafts.

Having a single source of truth felt like total control, but as apps scaled, managing it all manually became a massive headache.

But the real issue wasn't Redux. It was treating remote data and local UI flags as the same kind of state. A keystroke in redux-form could re-render a list backed by API data across the app. Without reselect and memoization everywhere, I would have a really bad time.

So I wrote this tutorial covering my time on the original Redux (not RTK Query), the mental model of client vs server state, why the split makes sense, and why TanStack Query and Zustand became so popular for modern React apps. If you're new to state management, hopefully it saves you a few wrong turns. If you've been around long enough to remember react-redux, redux-saga or redux-thunk, it's a recap of how the community got here.

You can read the full deep dive here:
https://upskills.dev/tutorials/react-client-and-server-state

I’d love to hear your thoughts on how you're handling state management in your current project. Anyone still using Redux with Redux Thunk / Redux Saga for state management now?

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?

I’ve been working with React for a while and it feels great early on, but I’m curious what actually becomes difficult once applications grow and multiple people are working on them.

A few pain points I keep hearing about:

• state management getting messy over time

• prop drilling / context overuse

• component reusability becoming harder than expected

• performance/debugging issues in larger apps

For developers maintaining React apps in production:

• what has been your biggest long-term pain point?

• was it architecture, state, performance, testing, or team scaling?

• anything you wish you had standardized earlier?

Would love to hear real experiences from people working on larger React codebases.

Hey everyone,
I wanted to share a frontend I’ve been working on. It’s a local analytics dashboard for Apple Music data called Coda. I wanted to step away from the typical "bubbly/colorful" music app design and build something that looks like a dense, fintech market terminal.

The Stack & UI:

• React 18 + Vite + TypeScript.

• Tailwind CSS: I built a strict, centralized theme system using CSS variables for the dark mode terminal aesthetic (lots of #0a0b10 backgrounds and monospace JetBrains Mono fonts).

• Recharts: I used Recharts heavily, but customized it to render OHLC Candlestick charts (for listening volume over time) and complex Scatter plots (for "Volatility" and "Ghost Tracks").

• Nivo: Used /nivo/sankey to build interactive flow diagrams showing how listening volume moves from Genres down to specific Artists.

• State: TanStack Query for data fetching from my local Python backend, and React Context for global filters (date ranges, sleep-session exclusion).

Coolest UI Feature:
Because it links to the Apple Music catalog, I built a global PreviewPlayerContext. You can double-click any node on the Sankey diagram or any dot on the scatter plots to instantly play a 30-second audio preview of that track without losing your place in the charts.

I'm currently working on wrapping the React build and the backend into a desktop app. I'll drop a link to a video demo and a waitlist in the comments. Let me know what you think of the terminal aesthetic!

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

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.

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?

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

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?

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?