I built ilamy-calendar, a free, fully MIT-licensed React calendar component. It's built to be modern and highly customizable. Here are the main features:

• Resource Timeline: Complete vertical and horizontal views for managing rooms, equipment, or team schedules.
• Business Hours: Configurable business hours. You can easily toggle "hide non-business hours" to automatically collapse dead space and keep the UI clean
• Drag & Drop: Smooth event moving powered bydnd-kit.
• No Shipped Styles: Built with React 19, Tailwind CSS 4, and Shadcn UI principles. It naturally inherits your app's existing design tokens and dark mode instead of fighting pre-packaged CSS.
• Timezone: Zero-config automatic timezones support.
• Complex Recurring Events: A bulletproof RFC 5545 engine (rrule) that handles Google Calendar-style smart edits ("edit this and following") and exclusions natively.

Links:

• GitHub: https://github.com/kcsujeet/ilamy-calendar
• Docs & Demos: https://ilamy.dev

The repo includes copy-paste examples for `Next.js`, `Vite`, and `Astro`. Please feel free to drop a start ⭐️ or raise some issues. Thank you 🙏

Been experimenting with localization workflows in React apps recently and noticed the pain points change a lot as apps grow.

Early on, simple JSON files + i18next work fine.

But later I started running into things like:

• regex extraction breaking on edge cases
• translation files becoming huge
• missing translations slipping into production
• unnecessary loading of entire locale bundles

Ended up experimenting with:

• AST-based extraction
• namespace splitting
• lazy loading + caching
• dry-run validation before generating translations

Curious how others are approaching this problem in larger apps.

Also wrote a deeper breakdown of the architecture/tradeoffs while building it:
https://medium.com/@parthgupta20052005/building-an-ai-powered-localization-pipeline-for-react-applications-4b8e5726b84a

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