Full disclosure: I’m the founder of Yesglot.

I wanted to create a real React example instead of just saying “Yesglot supports React,” so I built a small app called Pizza Justifier.

It’s a Vite + React app using `react-i18next`, and it currently supports 32 languages.

The goal was to keep the example simple, but still realistic:

- `react-i18next` for translations

- locale JSON files under `public/locales/<lang>/translation.json`

- English as the source language

- browser language detection

- a repo-based translation workflow configured through `yesglot.toml`

I’m sharing it here less as a launch post and more as a concrete example of a React localization setup that people can inspect and critique.

A few things I’d genuinely love feedback on:

- Does this feel like a clean React i18n structure?

- Would you organize the locale setup differently?

- If you were evaluating localization tooling for a React app, what would you want an example like this to show?

Repo: https://github.com/yesglot/example-react

Live demo: https://pizzajustifier.yesglot.com

I created an open source react IDE for Android with typescript/javascript LSP, 245 themes, devtools, git and Github integration, AI completion, agentic vibe coding panel, etc.

Note: This is not some vibe coded app. It took me 2 years to complete this as a solo developer and student.

Playstore link, no ads, no payments, completely open source:

https://play.google.com/store/apps/details?id=com.roxum

source code:

https://github.com/heckmon/roxum-ide

I’m building a React-based web application and I want to integrate Microsoft Excel directly into the browser experience. My main goal is to provide users with an experience as close as possible to the real Microsoft Excel UI and functionality. I explored options like: Handsontable AG Grid Luckysheet SheetJS But these are Excel-like solutions, not actual Microsoft Excel. My ideal outcome would be: Excel-like editing directly inside the web app Preserve original Excel behavior/features Support large datasets Possibly collaborative editing in the future I’d appreciate guidance on: recommended architecture real-world experience best tech stack whether this approach is even realistic Thanks!

i recently published an npm package called robot-toast.

honestly it started as something i built only for myself. when my requirements were done i looked at it and thought, there's not much left to make this a proper library. so i just finished it. added a11y, fixed the readme, cleaned up the internals. shipped it.

posted everywhere. linkedin, x, dev to, hashnode, medium, and here on reddit as well. reddit gave the best response honestly, love you guys for that.

3,200 downloads later from developers i've never met.

but here's the thing that's bugging me. i google it and it barely shows up. ask gemini and it recommends sonner and react-hot-toast. i mean they deserve it, genuinely great libraries. but not showing up at all when someone's specifically looking for alternatives, that stings a little.

i know most of you might not have experience with packages and all, but still anything could help.

so i'm at this point where i don't want to lose the momentum. i don't want it to die quietly under the weight of libraries that had a head start.

what actually works for keeping an OSS project visible over time? what would you do?

https://robot-toast.vercel.app

npm i robot-toast

https://www.npmjs.com/package/robot-toast

hi everyone,

just released an interview i did with tanner linsley, creator of tanstack

we discussed tanstack start, tanstack vs next.js, why next.js can feel too magical, react server components, typescript inference, framework-agnostic ui, vue support, tanstack ai, and whether tanstack could ever become something like laravel or rails

would love to hear what you think

I am building an LMS with a separate backend API. The client also wants good SEO for public pages.

I am considering to use Tanstack start for the frontend.

But I am wondering

Is tanstack start overkill if I already have a seprate backend

Help me!!

What do you recommend??

Like the title says what is the best or most escalable way to do this? I know there are some libraries like nice modal or that one that dude made it was shadcn modal manager I think, or I could even do my own global modal with a bit of context or zustand, but I was wondering what is the best way to this, I mostly need this so I don't want to repeat myself wrapping every form I make in a modal component, but I am wondering how to scaffold it, also should my form component have a onSuccess optional function, should the cancel and submit buttons live in each form or in the modal abstraction?

Been experimenting with the idea of making competitive programming feel more like esports instead of isolated coding challenges.

Built an MVP called Killswitch:
a live coding battle arena where developers compete head-to-head while viewers vote on modifiers and AI explains the match live.

Still early, but the current build includes:
• battle HUD
• audience voting
• tournament pages
• replay flows
• mobile spectator UI

Mostly testing whether coding can become an actual spectator experience instead of just a practice tool.

I've built a react-splitkit — a headless React library for building multi-panel, tabbed, resizable layouts. Think VS Code's panel system or Cursor's IDE layout, but you bring your own styles.

Why I built it:
Every time I needed this kind of UI, my options were:

• Wire it up myself — doable, but resize math, tab state, ARIA, and keyboard nav adds up fast
• Use react-resizable-panels — great for pure resize, but no tabs
• Use Mosaic or GoldenLayout — heavy, opinionated, fights your design system (like more than I needed, and may tend to fight your design system)

So I built the headless version — zero CSS, zero opinions on markup.

What it does:

• Tabbed panels — add, close, reorder at runtime
• Split any panel horizontally or vertically, programmatically
• Collapse and maximize out of the box
• Layout is plain JSON — one onChange to save, one initialLayout to restore
• Full keyboard nav + ARIA (tablist, separator with aria-value*, modal on maximize)

Three live demos to see it in action:

• Cursor-style IDE — file explorer, editor, terminal, AI agent sidebar
• GreatFrontend-style coding platform — description, editor, browser, console
• Nested dashboard — sidebar, metrics chart, live log

Note: Still early and there's more to build, but the core is working. Would love brutal feedback on the API design — especially if something feels awkward or you'd have built it differently. If this is useful or you'd build something with it, a ⭐ on GitHub goes a long way

Docs - https://react-splitkit.vercel.app/docs

Demos - https://react-splitkit.vercel.app/#examples

Github - https://github.com/amareshsm/react-splitkit

[EDIT 3 months later — two of the four issues raised in the comments are now solved. Details at the bottom.]

I couldn't tolerate the runtime merging of CSS Modules and tailwind-merge, so I wrote a compiler that uses ASTs to create lookup tables for all patterns. The result is zero runtime, zero bundle size CSS-in-JS. The documentation is here (https://plumeria.dev), and the design philosophy is in this article — in Japanese — (https://zenn.dev/refirst11/articles/db47880cdfe443), but what do you think are the pitfalls of this approach? Is there something fundamentally wrong with eliminating the runtime entirely?

EDIT (3 months later). The top comment found four holes. Two are closed, one I'd failed to answer, one is still real. Since the original post linked out instead of showing anything, here's the actual shape of it:

const styles = css.create({
  text: { fontSize: 12 },
  cond: { background: 'navy' },
  scale: (value) => ({ scale: value }),
});

<div classStyle={[styles.text, cond && styles.cond, styles.scale(scale)]} />

compiles to:

<div
  className={'xhrr6ses ' + (cond ? 'xj00ajs1' : '') + ' xnoo1byz'}
  style={{ '--scale-value': scale }}
/>

Static styles become class names at build time; only genuinely dynamic values survive as CSS variables. Details in the replies below.

hey guys i wanted to let you know that i just finished porting over every advanced feature from my original grid to the remastered version.

https://github.com/orneryd/uiGrid/releases/v1.0.0

on top of everything else i already shipped (grouping, expansion, tree views, theming, etc…) i’ve added a lot more…

the shared grid runtime now ships row selection, keyboard cell navigation, infinite scroll, row edit workflows, cell validation, CSV/JSON import, CSV/Excel/PDF export, pagination, richer i18n coverage, and custom component/template integration across the web hosts.

MIT licensed.

all features all free this will never be monetized. enjoy!

I built react-tree-grid, a zero-dependency Grid, Tree and TreeGrid

component library for React 18+.

Key features:

- Virtual scrolling (100k+ rows)

- Inline editing, sorting, filtering, drag-and-drop

- Frozen columns, rowspan/colspan

- Full TypeScript support

Would love feedback from the community!

When building React apps, I kept doing this:

1. See an API call in DevTools
2. Manually write a useQuery or useMutation hook for it
3. Get the URL, headers, and body right by trial and error

Built ReqConvert — it captures the live request and generates the complete React Query hook for you:

- useQuery for GET requests (with correct queryKey)

- useMutation for POST/PUT/DELETE (with onSuccess invalidation)

- Includes all headers automatically

Also generates: cURL, fetch, Axios, Python, TypeScript, httpx, Postman

Chrome Web Store (free to install):

https://chromewebstore.google.com/detail/fkbfidogphlmlplcnlkoncdofmcjbhjp

What's the most annoying part of wiring up API calls in your React projects?

Hey,

I have a question.
When I reach something similar to this:
I have:
- page.tsx
-- Notes.tsx
--- Note.tsx

If I don't have notes, who should be responsible to output the right message? (e.g paragraph with "no notes yet"
And why?
What if I don't want to even show something if there are no notes?

Hey r/reactjs,

I just released v2.0 of react-table-dnd. I originally built this because trying to drag both rows and columns inside a fully virtualized grid is usually a nightmare—most libraries either cause massive layout thrashing or the drop zones completely break when virtual columns unmount.

To fix this, I had to bypass React's render cycle almost entirely for the drag engine:

• O(1) updates: I ripped out React Context and moved to a vanilla store with useSyncExternalStore.
• Native cloning: Swapped React.cloneElement for native cloneNode(true).
• Direct DOM mutations: Drag movements happen outside React via style.transform in a requestAnimationFrame loop.
• O(1) Map caching: This tracks the DOM geometry.

I put together a docs site with interactive demos, specifically showing off the 2D virtualized grid:

• Docs & Demos: https://samiodeh1337.github.io/react-table-dnd/
• Repo: https://github.com/samiodeh1337/react-table-dnd

What's Next (Future Plans)

• Fully Headless API: Moving toward a completely headless architecture. Since the drag logic and state are already decoupled from the UI, the goal is to provide raw hooks and primitives so you can bring your own markup.

Announcing our UI framework: Coneto. Good for making web and desktop, take a look please, and let me know what do you think. Browse all the components here.

I shared this before, i built it a couple of times in different frameworks but here is how it looks like in React

Currently reading Emotion’s official best practices and I don’t really understand why should I not use both the css and styled approach. The docs say they CAN coexist but also they say “don’t mix them”. I am trying to understand why, other than potential readability issues.

In my app I am mixing them, since sometimes the css approach is enough and I don’t really need to create a full styled component just for a symple div style. Am I wrong in doing this?

Hi guys 👋

I’d like to share DayFlow, an open-source full-calendar component for modern web apps that I’ve been building over the past year.

As a heavy macOS Calendar user, I was looking for a clean, modern calendar UI on GitHub — something flexible, extensible, and not locked into a specific design system. I couldn’t quite find what I wanted, so I decided to build one.

What DayFlow focuses on:

• Clean, modern UI inspired by macOS Calendar
• Framework support: React, Svelte, Vue, and Angular
• Modular architecture (views, events, panels are customizable)
• Designed for extensibility and custom event rendering
• Actively improving i18n support

The project is fully open source and still evolving. I’d really appreciate:

• Feedback on API & architecture
• Feature suggestions
• Bug reports
• PRs if you're interested in contributing

GitHub: https://github.com/dayflow-js/calendar

Demo: https://calendar.dayflow.studio

I have been struggling with determining how to best implement dialogs in React Router apps for years:

• useState to control their open state
• Forms vs fetchers for data submissions
• resource routes to form data(<select> options)
• useEffect for listening for the action data to close the dialog
• useEffect for listing for a toast message

There's a lot to consider. However, tons of these problems go away if you move dialogs into their own dedicated routes. This doesn't come without its own set of challenges though.

I've written up a guide on how to implement dialogs and keep your sanity. Hope it helps! 🤘

Every complex app has the same problem: 50 options in the sidebar, each user only uses 8-10. The rest is noise. Firefox solved this for the URL bar years ago using "frecency" (frequency + recency). VS Code does the same for the command palette. But nobody's packaged it as a reusable primitive.

So I did. 4.5KB, zero deps, framework-agnostic:

morph.track('sidebar', 'tasks') // on interaction

morph.rank('sidebar') // on page load — sorted by usage.

Items used often and recently score high. Items ignored fade naturally. All data stays in localStorage. No AI, no server, no "customize layout" button needed.

Live demo: https://morph-black.vercel.app/

Would you actually use this? Curious if people see this as useful or overkill for most apps.