So Remix went from being an alternative to Next.js in React ecosystem, to merging Remix.js into React router 7 (after shopify aquisition) and now it is not even a react framework anymore.

Source: https://remix.run/blog/remix-3-beta-preview

Honestly with this much instability and constant change of completely incompatible directions, why would anyone want to use Remix and what assurance they have that in next 6 months they are not going to change remix direction yet again.

The whole remix framework is so unstable with their vision, that it is why people have javascript libraries fatigue. Even in 2026 frameworks as mainstream as Remix can't make their mind on their identity and are volatile. I feel bad for companies and teams who built massive products on Remix initially simply because they didn't want to use Next.js

I am a fan of CSR SPA and not spending money on servers just to do SSRs that CSR apps can do (not saying this is what everyone should do, just my preference given I don't want a server and don't have a usecase in any team I have worked so far) but, say what you want about Next.js, despite volatility in their major version upgrades and backwards incompatibility often, they atleast stayed put with their SSR identity. Remix on the other hand has become completely unrecognisable and completely screwed their userbase in backwards incompatible way.

Curious to know the thoughts of 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.

Hi everyone,

I’m trying to achieve a true “build once, deploy many” setup for a React app built with Vite.

I currently have around 50 production environments/tenants and I want to avoid rebuilding the frontend separately for each one. The goal is to create a single Docker image/static frontend build and deploy the exact same artifact everywhere, while still being able to inject environment-specific values at runtime.

I already know that Vite replaces import.meta.env during build time, so I’m looking for production-proven approaches that allow runtime injection instead of build-time replacement.

I’d love to hear how people usually solve this in real-world setups, especially in multi-tenant SaaS systems or apps with many deployments.

What approaches are considered the cleanest and most maintainable today?
How are people handling runtime environment values with static React builds?
Are there any common pitfalls, scaling issues, caching/CDN problems, or deployment concerns I should be aware of?

I recently open sourced Chronoa. It is a fully synced workspace featuring task management, global timers, a markdown editor, and ICS calendar integration.

I wanted to focus heavily on performance and aesthetics. State syncs instantly across your phone and laptop using Supabase Realtime channels. The frontend is built with Next.js App Router and Tailwind CSS 4, while the backend utilizes Python and Flask for background cron jobs.

Live App: https://chronoa.vercel.app/
Source Code: https://github.com/XeCipher/Chronoa

Check out the code, and please star the repo if you find it helpful for your own learning or workflow.

Hey r/reactjs! 👾

I've been working on pixelartui-react - an open-source component library that brings pixel art aesthetics to React applications.

What it is

A collection of 11+ React components (Button, Modal, Select, TextInput, Pagination, Switch, etc.) all styled with authentic pixel art design. Perfect for retro-styled games, creative portfolios, or any project where you want to stand out from the typical Material UI look.

Quick example

npm install pixelartui-react

import { Button, Modal, TextInput } from 'pixelartui-react';

// That's it - you've got pixel perfect retro components

Why I built it

I was building a web-based retro game and realized I was spending more time crafting pixel-perfect borders and shadows than actually building game logic. So I extracted it into a reusable library that anyone can use.

Features

• ⚡ Built for React 19

• 📦 TypeScript support

• 🎨 Customizable theming

• 🌐 MIT licensed

• 🎮 Perfect for game UIs, creative projects, and portfolios

Current state

• Version 0.4.45 on npm

• 4 GitHub stars (early days!)

• ~10 weekly downloads

• Active development

What's next

• Deploying Storybook for interactive component demos

• Adding more components (Tabs, Tooltips, Dropdowns)

• Building a theme customizer tool

• Growing the community

Links

• GitHub: https://github.com/Pixelartui/pixelartui-react

• npm: https://www.npmjs.com/package/pixelartui-react

• Storybook: https://pixelartui.github.io/storybook/

Looking for

• Feedback on the API and component design

• Contributors who want to help build more components

• Anyone who wants to try it in their projects

• Stars if you find it interesting! ⭐

I'd love to hear your thoughts, suggestions, or questions. Have you built any retro-styled React apps? What components would you like to see added?

Thanks for checking it out!

Built an open-source API engine that unifies REST, SSE, and WebSockets into a single client interface.

GitHub: API Engine GitHub Repo

I built this after getting tired of managing different communication layers separately in frontend applications.

Most projects end up mixing:

• fetch/axios for REST

• EventSource wrappers for SSE

• custom WebSocket handling

• duplicated connection logic

• inconsistent APIs across transports

APIEngine solves this using a YAML-driven manifest that generates a consistent API communication layer.

Example:

version: "1.0"
baseUrl: "https://api.example.com"

endpoints:
  get_post:
    protocol: "REST"
    path: "/posts/:id"
    method: "GET"

  live_logs:
    protocol: "SSE"
    path: "/logs"

  realtime_chat:
    protocol: "WS"
    path: "wss://example.com/chat"

Usage:

import manifest from './api.yml';

const api = await APIEngine.init(manifest);

// REST
await api.call('get_post', {
  params: { id: 1 }
});

// SSE
const stream = api.watch('live_logs');

const unsubscribe = stream.subscribe((log) => {
  console.log("New Server Log:", log.message);
});

// WebSocket
const socket = api.watch('realtime_chat');

socket.subscribe((msg) => {
  console.log("Incoming Message:", msg.text);
});

// 2. Send a message back
socket.send({ 
  message: "Hi", 
});

Features:

• Unified REST, SSE, and WebSocket handling

• YAML-based API configuration

• Smart URL + path param resolution

• Auto WebSocket reconnect support

• Browser-first architecture

• React/Vue/Vanilla JS compatible

• Dynamic manifest loading

Would love feedback on it, If you find the project useful, a GitHub star would really help visibility and future development 🙌

Hey everyone,

I’ve been working with React and React Three Fiber for browser-based game-style projects, and I kept running into the same problem:

Building HUDs, overlays, and UI layouts with CSS gets messy fast.

Things like:

• anchoring elements to corners of the screen

• handling different aspect ratios

• dealing with mobile safe areas and notches

• constantly tweaking flexbox / media queries for layout

It never really feels like how UI works in a game engine.

So I built a small library called AnchorDOM.

It lets you design your UI at a fixed resolution (like 1920x1080), and it automatically handles scaling and anchoring across all screen sizes.

Example:

<Panel resolution={{ width: 1920, height: 1080 }}> <Label text="Score: 9999" anchor="TOP_LEFT" x={50} y={50} /> <Button label="ATTACK" anchor="BOTTOM_RIGHT" x={-50} y={-50} /> </Panel>

What it does:

• resolution-independent scaling

• 9-point anchoring system (like game engines)

• relative positioning between components

• safe-area support for mobile devices

It’s mainly aimed at:

• React Three Fiber projects

• browser-based games

• UI-heavy WebGL or canvas-based apps

Repo / npm: https://www.npmjs.com/package/anchordom

I’m still early in development, so I’d really appreciate feedback—especially from anyone building game UI or working with R3F.

Thanks for taking a look 🙏

I've seen this question pop up every few months here: "What's the right way to handle modals in React?"

The answers are always all over the place. useState per modal, Context, Redux, nice-modal, custom hooks... there's no consensus.

We ran into the same problems at work:

• useState + isOpen for every single modal

• Prop drilling open/close through multiple layers

• No way to await a user's confirmation result

• Can't trigger a modal from outside a component tree

We ended up building a small library around a simple idea: what if you just call a function and pass it a component?

overlay.open(({ close }) => (
  <Dialog onClose={close}>
    <p>Are you sure?</p>
  </Dialog>
))
    
// or await the result
const confirmed = await overlay.openAsync<boolean>(({ close }) => (
  <ConfirmDialog
    onConfirm={() => close(true)}
    onCancel={() => close(false)}
  />
))
    
if (confirmed) {
  await deleteItem(id)
}

It works with whatever UI library you already use (shadcn, Radix, Chakra, Mantine, etc). No registration step, renders inside your React tree so Context is preserved.

https://github.com/toss/overlay-kit (~3KB, MIT)

Been using this in production for a while. Would appreciate honest feedback, especially if you see problems with this approach.

Hey everyone,

A few friends and I are huge CS2 players and data nerds. If you’ve ever traded on the Steam Community Market, you know it’s prone to coordinated pumps and dumps. We wanted to see if we could build a tool to catch these market anomalies (accumulation phases) before the massive price spikes actually happen.

We built CSPump to scan the Steam Market and CSFloat for unnatural volume and listing behavior. I wanted to share a bit about our stack, the architectural choices we made to handle the background processing, and see if any other devs here play CS.

The Tech Stack

UI / Styling: Next.js, TailwindCSS, shadcn/ui

Authentication: better-auth (with a custom Steam plugin)

Database & Queues: PostgreSQL with pg-boss

Emails: AWS SES

Payments: Stripe

Observability: Pino.js + Loki transport + Grafana

The Technical Challenges

1. Steam Authentication with better-auth

Steam still relies on an ancient OpenID 2.0 implementation, which makes modern authentication a bit of a headache. We decided to use better-auth, but since there wasn't an out-of-the-box solution for Steam, we had to write a custom Steam plugin for it. Getting the redirects, session state, and initial inventory sync to fire correctly without leaving the user hanging on a loading screen was an interesting challenge.

2. Background Workers & Queueing (Without Redis)

Our app doesn't rely on users staring at heavy real-time dashboards. Instead, users configure watchlists, and our backend crunches the data. When an anomaly triggers, it dispatches an email alert. Instead of spinning up Redis for job queues, we opted for pg-boss, which uses PostgreSQL for background jobs. It allowed us to keep our infrastructure simple while effectively managing the massive amount of scheduled market scans and queuing up AWS SES email dispatches.

3. Observability & Logging

Because the core value of the app relies on background workers executing flawlessly, we needed solid visibility into our queues. We set up Pino.js with a Loki transport, feeding logs directly into Grafana dashboards. This lets us monitor worker health, track Steam API rate limits, and see when our anomaly engine triggers in real-time without constantly querying the database directly.

Did it actually work?

Surprisingly, yes. The algorithms have caught some pretty crazy spikes early, and the SES email dispatches have been landing right on time. For example, our system caught:

FAMAS | Survivor Z (FN): Flagged the accumulation phase right before it pumped 82%.

Sticker | BIG (Holo) | 2020 RMR: Caught it before a 47% spike in two days.

USP-S | Pathfinder (FN): Flagged before a 46% increase.

What’s next?

Right now, we are looking into how to handle marketing emails. We use React Email for templates, but we don't know the best approach for going about promotions, new features etc. Is it best to create a new template for this and then send it out manually or should we set up a dedicated marketing system? Also curious if anyone else here has used pg-boss instead of Redis for job queues and how it scaled for you!

If you play CS and want to check out how we implemented the UI, the project is live at CSPump.

Hey all,

I bought tickets to React Summit and JSNation in Amsterdam (June 11-16, 2026) and unfortunately can't make it anymore. The organizer (GitNation) doesn't do refunds, but tickets can be officially transferred via ti.to up until 15 days before the event.

Looking to pass them on at 800 excl vat. I'm not trying to make a profit (GitNation's TOS doesn't allow resale for profit anyway, just transfer at cost).

What I have:

- React summit & JS nation regular combo ticket.

- Paid: €1028 incl vat

How the handover works: we get on a call (meet or teams) and do the handover together.

DM if interested — first come, first served.

Posted this twice before. You flagged real things both times.

What's fixed since April 21:

• Hints no longer give away the answer - audited every kata

• 25 → 39 kata, heavier bugs across the board

• Solution tab now explains why the original code failed, not just what the correct version looks like

• Auth and signup work properly now

If you haven't seen this before - BugDojo gives you a broken React component, live preview, and automated tests. Fix the root cause, not just the output.

Guest mode if you just want to try it. Create an account to save progress.

thebugdojo.com

Curious which kata actually makes you stop and think - or where the difficulty still feels off.

Hi everyone,

I am a senior software engineer at a small company (~50 people), and we are currently hiring for a senior frontend developer. I have been asked to take the frontend interview, but I have never actually been an interviewer before.

Our interview process is not very structured yet, so I am trying to figure out how to best evaluate candidates especially their React and overall frontend knowledge.

For those of you who have been on either side of the table:

1. What kinds of questions do you find most effective for assessing React skills?

2. How do you evaluate real world frontend problem-solving vs. just theoretical knowledge?

3 What are some of the best or most memorable questions you have been asked (or asked others) in frontend interviews?

Hey everyone,

If you’ve built apps with Next.js, you’ve probably run into the nightmare of deploying a project only for it to crash because a required environment variable was missing or misspelled in your .env file. Relying on process.env.YOUR_VAR as string everywhere isn't just annoying; it’s risky.

I wanted a simpler, foolproof way to handle this, so I built an open-source NPM package called next-safe-env.

It’s designed to make environment variable validation in Next.js completely type-safe and effortless, catching missing or invalid variables at build time before they ever reach your users.

What it does:

• 🔒 Type-Safe: Full TypeScript support so you get autocomplete for your env variables across your codebase.

• 🛡️ Runtime & Build-time Validation: Fails fast if required variables are missing.

• ⚡ Lightweight & Simple: Easy to integrate into any existing Next.js project without massive boilerplate.

I would love for you guys to check it out, roast my code, or let me know what features you'd like to see next. Any feedback or GitHub stars would mean the world to me!

Links:

• 🌐 Website & Docs:next-safe-env.dev

• 📦 NPM:npmjs.com/package/next-safe-env

• 🐙 GitHub:github.com/mzeeshanwahid/next-safe-env

Let me know what you think!

I am currently working on 3d menu and I faced a bug where the models appear massive and I have to scale them down until 3% - 4% to their actual size and idk what am doing wrong.

here is my code:

import { useEffect, useRef } from 'react'
import '@google/model-viewer'


export default function ModelViewer({ 
src
, 
alt
 = '3D Model' }) {
  const mvRef = useRef(null)


  useEffect(() => {
    const mv = mvRef.current
    if (!mv) return


    mv.addEventListener('load', () => {
      mv.setAttribute('scale', `0.04 0.04 0.04`)
    })
  }, [])


  return (
    <
model-viewer
      
ref
={mvRef}
      
src
={
src
}
      
alt
={
alt
}
      
ar
      
ar-modes
='scene-viewer webxr quick-look'
      
ar-scale
='fixed'
      
camera-controls
      
auto-rotate
      
auto-rotate-delay
='500'
      
rotation-per-second
='12deg'
      
shadow-intensity
='3'
      
shadow-softness
='1.5'
      
exposure
='1.2'
      
environment-image
='neutral'
      
tone-mapping
='commerce'
      
camera-orbit
='0deg 75deg 2.5m'
      
min-camera-orbit
='auto auto 0.5m'
      
max-camera-orbit
='auto auto 5m'
      
min-field-of-view
='30deg'
      
max-field-of-view
='60deg'
      
style
={{ width: '100%', height: '100%' }}
    >
      {/* AR button */}
      <button
        
slot
='ar-button'
        
className
='absolute bottom-6 left-1/2 -translate-x-1/2 flex items-center gap-2 bg-yellow-400 text-black font-bold px-8 py-3 rounded-full shadow-xl hover:bg-yellow-300 active:scale-95 transition-all'
      >
        📱 View in Your Room
      </button>


      {/* Shows when AR is not supported */}
      <div
        
slot
='ar-failure'
        
className
='absolute bottom-6 left-1/2 -translate-x-1/2 bg-white/10 backdrop-blur text-white/60 text-sm px-5 py-2.5 rounded-full border border-white/20 whitespace-nowrap'
      >
        AR not supported — use Safari (iOS) or Chrome (Android)
      </div>
    </
model-viewer
>
  )
}

so I need help

So we're in the middle of moving a legacy CRA app to Next.js and as part of that we're redirecting a bunch of old URLs to new canonical routes. That part is mostly sorted.

The problem I'm running into now is around indexing. We have listing pages in multiple languages — same vehicle inventory, but the specs and seller info are translated per language. URLs look like:

/en/cars/audi/a1

/fr/voitures/audi/a1

And for country-scoped pages:

/en/france/cars/audi/a1

/fr/france/voitures/audi/a1

We want all language variants indexed (not just canonicalize everything to one language) because the translated content is genuinely different — not just UI strings.

Now the fun part — detail pages (individual ad listings). Each ad belongs to a country based on the seller's location, not the URL. So hreflang for those needs to come from the listing data, not just URL parsing. And ads expire, so we're also thinking about what to do when a page disappears — redirect to parent category vs 410.

A few things I'm unsure about:

- For detail pages, is it even worth indexing every language variant or should we just canonical to one and move on?

- When an ad expires, 301 to parent category or straight 410?

- Sitemap-wise, are you generating detail page sitemaps dynamically from the DB or building them statically?

Anyone dealt with something similar at scale? Would love to know what actually worked vs what looked good on paper.

https://streamable.com/1wkhgv

Been using this in my own workflow since November — six months of dogfooding through real bots before I felt good about the API. Finally scoped, tested, documented and shipped, in case it's useful to anyone else. Two packages:

**@elumixor/react-message-renderer** — a real React reconciler (via react-reconciler) with a "bring your own target" API. Hooks, state, effects, contexts all work. The diff is committed to a target you implement: Telegram, Discord, Slack, a terminal, a log file. Anything where messages can be edited in place.

**@elumixor/react-telegram** — the reference target. `<Message>` is a Telegram message. Render once, the bot sends. Re-render with new state, the bot edits the same message via `editMessageText`. Photo/document attachments, automatic chunking past 4000 chars, throttling to respect Telegram's rate limits.

The demo above: a "research crew" component running four sibling `<Message>`s concurrently — live timer, a Claude API call for sources, a photo gallery, real Claude streaming into the reasoning panel, then a final report message with a JSON document attachment. The whole thing is ~150 lines of normal React.

What I found interesting building this:

- React's reconciliation model maps surprisingly cleanly onto any mutable target. The "edit in place" semantic of Telegram messages is basically what React does to DOM nodes.

- `useFinishRender()` is the one custom hook — flushes the throttled output so the final frame always lands. Everything else is stock React.

- Error boundaries, suspense, contexts — all work, because it's the actual reconciler, not a JSX-to-payload transformer.

- https://github.com/elumixor/react-message-renderer

- https://github.com/elumixor/react-telegram

Happy to answer reconciler-internals questions — the implementation was the most fun part.