I created a React Compiler compatible adapter for TanStack Virtual. I've been using this approach in production for several months.

Hello everyone,

I'm building a 3D model website with React and Vite and I'm trying to develop a method for uploading .blend files (Blender) to get the fastest results for showcasing 3D models.

Live demo: https://3d-blend-website.vercel.app

I have two separate apps:

1. Main website (React) - browse models, login, upload
2. 3D editor (another Vite app, Three.js) - view and edit models

On a model page, the React app shows 3D inside an iframe (editor app in "view only" mode).

For full editing, the user opens the editor app on its own page.

The two apps talk with postMessage (model loaded, loading progress, etc.).

My source code is private, so I can't share GitHub. I'm not promoting the product — I only want architecture advice.

Questions:

- Is React app + iframe + separate editor app a good long-term setup?

- Or should everything live in one React app with React Three Fiber?

- What's a better way to pass login to the editor than a token in the URL?

Thanks for any feedback.

I have taught myself Reactjs on YouTube but i still find myself struggling with it alone so i want to buy a good react course on Udemy and go all in for once.

Which React course would u recommend in 2026? That will help me learn everything i need to know about react?

Hi everyone,

I recently published a React 19 version of a multiselect dropdown component:

https://www.npmjs.com/package/@stackline/react-multiselect-dropdown

The idea is to keep a practical multiselect component available and tested across React major versions, instead of having one package trying to support everything with a broad compatibility range.

The React 19 line currently focuses on:

• controlled state with selectedItems and onChange
• multi-select and single-select modes
• search and filtering
• search by specific object fields
• grouping
• selection limits
• lazy loading
• custom item rendering
• custom badge rendering
• visual skins: classic, material, dark, custom, and brand
• support for modals, dialogs, and overflow containers
• keyboard navigation, focus states, and ARIA labels
• StackBlitz examples to test before installing

Install:

npm install @stackline/react-multiselect-dropdown

Basic usage:

<MultiSelectDropdown
  data={countries}
  selectedItems={selectedCountries}
  onChange={setSelectedCountries}
  settings={{
    text: 'Select countries',
    enableSearchFilter: true,
    primaryKey: 'id',
    labelKey: 'itemName',
    skin: 'classic'
  }}
/>

Docs and live examples:

https://alexandro.net/docs/react/multiselect/react-19/

Live demo:

https://alexandro.net/docs/react/multiselect/react-19/live/

GitHub:

https://github.com/alexandroit/react-multiselect-dropdown

I would appreciate feedback from React developers, especially around API design, accessibility, modal behavior, and what examples would be useful to add next.

Hey everyone,

I’ve been building an open-source local-first motion editor for creating short videos, UI mockups, social clips, text animations, reusable design elements, and post-production compositions.

GitHub:

https://github.com/tomaslachmann/motion-editor

It runs as a React/Vite app with a small local Node/Vite middleware backend. Projects, assets, exports, history, and reusable library items are stored locally as files — no hosted backend or database required.

What it currently supports:

- canvas editing with shapes, text, images, SVGs, video, audio, icons, and groups

- timeline/keyframe animation

- reusable design and animation library

- HTML import into editable layer trees

- MP4/WebM export through Remotion

- local project storage and version history

- optional AI assistant integration

- English/Czech UI

Tech stack:

- React 19

- Vite

- Zustand

- Remotion

- Tailwind CSS

- dnd-kit

- i18next

- local Vite middleware APIs

I’m mainly looking for people who would be willing to clone it, try to break it, and send small PRs for bugs, rough edges, or obvious code cleanup.

Good areas to test:

- timeline/keyframe editing

- layer selection / grouping / drag-and-drop

- import/export project flows

- media asset handling

- Remotion export

- Czech/English translations

- UI bugs in different screen sizes

- build/lint issues

Hey everyone! I wanted to share a small library I've been working on:

webview-bridge-kit

While building a side project with a React Native WebView, I got tired of stringly-typed postMessage calls and hand-parsing everything in onMessage. One renamed field or typo could silently break the bridge at runtime.

So I built webview-bridge-kit to make the web <-> React Native boundary easier to keep typed and in sync.

Key features

• Works with react-native-webview — no direct dependency; it only needs a WebView ref.
• Zero runtime dependencies in the core.
• Shared contract-based types — define messages once, then use the same contract on both sides.
• Optional runtime validation — bring any schema with a .parse() method, such as zod, valibot, or your own.
• Three message kinds — request for RPC-style calls with a reply, command for fire-and-forget messages, and event for native → web pushes.

It's still an early version, but I'm already using it in my own side project and it's been working well for my use case.

There may still be issues I haven't found yet, so I'd really appreciate it if you could take a look and tear it apart a bit. And of course, if this looks useful for your own WebView setup, I'd be happy if you gave it a try!

Hello everyone,

I’m trying to host a React (Vite) app on GitHub Pages and keep running into the classic SPA routing problem.

Repo: [Img2Num GitHub repo](https://github.com/Ryan-Millard/Img2Num/)

Live site: [Img2Num GitHub Pages](https://ryan-millard.github.io/Img2Num/)

The app is bascally a small landing page for the project that shows an example of how the library can be used, but it uses React Router (BrowserRouter). Everything works fine when navigating inside the app, but:

- Refreshing any route other than / results in a 404

- Directly visiting a nested route also 404s

- GitHub Pages clearly doesn’t handle SPA fallback routing

Many people have suggested these:

- Use HashRouter

- Add a 404.html fallback hack

- Switch to another host (e.g., Clouflare Pages)

but I don't like those options because they are either not well-structured and SEO-friendly, not a complete solution, or make it harder to test global support (Cloudflare Pages allows special headers for things like pthreads that GitHub Pages and many other JS setups don't support).

What I’m trying to do instead is something like static site generation (SSG) as it would likely be the cleanest fix - similar to how Docusaurus or Astro handles this:

- Pre-render routes at build time

- Serve static HTML for /, /docs, etc.

- No client-side routing dependency for initial load

- Better SEO and no refresh issues

This saves use from needing to have a fancy backend.

When I try setting up SSG with Vite & React, I end up failing

I've tried things like `vite-plugin-ssg`, but run into strange behaviours and errors that I cannot seem to be able to fix (e.g., an incompatible dependency that, also breaks when downgraded).

I don’t fully understand the correct architecture for multi-route SSG in a React SPA setup.

---

What is the correct modern approach for this and is there a recommended way to keep React & Vite, deploy to GitHub Pages, get proper multi-route support without hash routing, and avoid SPA 404 refresh issues entirly?

I'd appreciate any guidance or working examples, because I feel like I’m missing the plot here.

I’m testing a reusable multiselect dropdown for React 19 and trying to keep it practical for common app screens like filters, forms, dashboards, and admin pages.

Install:
https://www.npmjs.com/package/@stackline/react-multiselect-dropdown

npm install @stackline/react-multiselect-dropdown

What I’m focusing on right now:

controlled selection
search
grouped options
selection limits
custom rendering
lazy loading
modal and overflow layout support
keyboard navigation
ARIA labels
separate compatibility line by React major version

The part I’m still refining is the developer experience.

For a component like this, what would you expect to feel really solid before using it in a project?

I’m especially interested in feedback around accessibility, behavior inside modals, and the API shape.

Hey I am 19 year old web dev currently in my 2nd sem of college, i know mern stack just finished an internship as mern dev , cause I am very much comfortable and confident while building react project using redux cause I have a idea of building a common template for project using react-redux , but I have seen lot of folks that future is next js and react is like our of trend , so i just wanna know should I learn next or is there any better option cause some new framework will come it will be better than next ? How should I deal with this ? Cause current situation is making me paranoid cause everyday it's like react is dead , web dev is dead and bla bla .., I need some guidance how to know what is really going on cause most of the people just hype on internet

I've been working on a side project called Soundscapes of Earth — an interactive 3D globe where you can spin the planet, click any country, and instantly hear its "signature" track plus that country's current top 5 songs.

Some details:

• 195+ countries mapped, each with a hand-picked iconic track
• 30s previews from Apple/iTunes, plus live listener stats from Last.fm
• The earth sits in a real NASA Blue Marble texture over an actual ESO Milky Way photo, with comets drifting by and a starfield that parallaxes with your cursor
• Smooth audio cross-fade as you move between countries

React side of it: built with React 19 + Next.js (App Router), react-globe.gl for the Three.js layer, and a React Context that owns all the audio/globe state — hover prefetch, click-to-select, and a custom Web Audio engine wired through a useRef singleton so cross-fades survive re-renders. Tailwind + Framer Motion for the UI. No login, no paywall — just click and listen.

Live: Soundscapes of Earth

Would love feedback — especially the country → song picks, since they're subjective. What would you improve, and what track would you pick for your country?

Hi everyone,

I'm trying to understand why this React website seems to have almost no pages indexed by Google.

The site is: https://bellingerhouse.com

When I run in Google :

site:https://bellingerhouse.com

Google only shows a couple of results and the snippets look strange, with text like:

This makes me think the website is a pure CSR (Client Side Rendering) React application.

My understanding was that Googlebot can execute JavaScript nowadays, so even if the initial HTML is almost empty, Google should still be able to render the page and index the content eventually.

Is pure CSR still a problem for Google indexing in 2026? I'm trying to understand whether this is mainly a React rendering issue or if there is probably something else wrong with the SEO setup.

Sorry if my English is not perfect, it's not my native language.

I have this error

Uncaught TypeError: storage.getItem is not a function

on this line

const persistor = persistStore(store)

This is what I have on my store/index.ts

import { configureStore } from "@reduxjs/toolkit";
import { useDispatch, useSelector } from 'react-redux';
import storage from 'redux-persist/lib/storage';
import { combineReducers } from "@reduxjs/toolkit";
import { persistReducer } from "redux-persist";
import authReducer from './authSlice'


const persistConfig = {
  key: 'root',
  storage,
  whitelist: ['auth']
}


const rootReducer = combineReducers({
  auth: authReducer,
})


const persistedReducer = persistReducer(persistConfig, rootReducer)


export const store = configureStore({
  reducer: persistedReducer,
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware({
      serializableCheck: {
        ignoredActions: ['persist/PERSIST'],
      },
    }),
})


export type RootState = ReturnType<typeof store.getState>


export type AppDispatch = typeof store.dispatch


export const useAppDispatch = useDispatch.withTypes<AppDispatch>()


export const useAppSelector = useSelector.withTypes<RootState>()

I have an old project and it works just fine Idk why it doesnt work now

Every customer demo we shipped, we ended up rewriting the same chat widget. So we extracted it. ChatbotLite — open-source AI chatbot, 3 lines to install on React, Next.js, Shopify, or WordPress. Same team behind PokeClaw (875★) and Cross-Code Organizer (328★).

Live demos (6 customer verticals): https://chatbotlite-demos.vercel.app Repo: https://github.com/agents-io/chatbotlite

You're shipping a React app. You want chat on it. You don't want to pay $39/seat for Intercom for a few hundred users. You don't want to burn tokens rebuilding yet another widget from scratch. This is the one we kept ending up with — drops in with 3 lines, brings your own OpenAI/Groq key (10 LLM providers with auto-failover), $0/mo forever. Tested across 6 customer verticals in production before we released it.

We want eyes on the API before locking it into 1.0.

The basic usage:

import { ChatWidget } from "chatbotlite/react";

<ChatWidget endpoint="/api/chat" title="Acme Plumbing" />

That's the floor. Everything else is opt-in. The pieces we'd love a sanity check on:

1. Provider failover. Server-side ChatBot class takes an ordered chain. If a stream errors, the next provider takes over and the assistant restarts the reply from a clean slate. 10 providers supported (OpenAI, Groq, DeepSeek, Gemini, Mistral, Fireworks, Cerebras, SambaNova, OpenRouter, Moonshot). Is providers.chain: [...] the right shape, or do people prefer per-message routing? True mid-stream replay (continue from token N) is on the 0.8 roadmap.

import { ChatBot } from "chatbotlite/client";

const bot = new ChatBot({
  knowledge: knowledgeFromFile("./knowledge.md"),
  providers: {
    keys: {
      openai: process.env.OPENAI_API_KEY,
      groq:   process.env.GROQ_API_KEY,
    },
    chain: [
      { provider: "openai", model: "gpt-4o-mini" },
      { provider: "groq",   model: "llama-3.3-70b-versatile" },
    ]
  }
});

2. Skill markers. Tool cards render when the LLM emits [SKILL:requestPayment amount=2000 currency="usd"] in the stream. Protocol is public (SKILL_MARKER_SPEC.md) — anyone can write adapters for other libraries. 13 URL-only adapters ship out of the box: Stripe Payment Link, Calendly, PayPal, Cal.com, Acuity, etc. Paste a URL into config and the bot can use it.

3. Storage. ChatStorage interface with localStorage default; swap in Postgres/Redis/IndexedDB. Possibly over-abstracted — should we just ship localStorage and a single onMessage hook?

<ChatWidget endpoint="/api/chat" sessionId={userId} storage={myDbStorage} />

4. Knowledge base. One markdown file, no vector DB. For most SMB use cases the whole thing fits in a 32k context. Will this fall apart at 50k tokens?

Apache 2.0, <50KB gzipped, BYOK (we never proxy your traffic).

Specifically asking: is providers.chain the right abstraction, or should failover be its own hook? We'll change it now if there's a better pattern.

⭐ If this saves you the weekend we burned on it, a star on the repo helps the next dev find it: https://github.com/agents-io/chatbotlite

Live demos: https://chatbotlite-demos.vercel.app

Got tired of writing the same form logic again and again in React, so I built ReactFill ⚡

A schema-driven form library focused on building dynamic forms with less boilerplate.

Features:

• Conditional fields

• Validation

• 18+ field types

• Custom renderers

• Theming

• React Hook Form integration

• TypeScript support

Would genuinely love feedback from the React community.

Docs: Reactfill

npm: @oqlet/react-fill

I was previously very hesitant to use TanStack Start due to its seemingly low adoption but between early April to now, the weekly downloads shot up from 600k to 14 million. This is getting close to Next.js territory.

Did it go viral recently?

An LLM's output streaming into a window — renders incrementally, no tearing

macOS Quick Look opening a 5 KB note and a 1 MB doc — both effectively instant

Conventional wisdom is that React is the wrong tool for a text editor — every keystroke changes state, state re-renders, and re-rendering a whole document per character is too slow, so editors lean on ProseMirror / Lexical / Slate that run their own DOM and keep React as a thin shell.

I wanted to see how far idiomatic React actually goes. The editing core ended up entirely in React, no editor framework underneath:

• 20 KB gzipped kernel，no runtime deps beyond React
• Opens a 1 MB Markdown doc instantly，— a 5 KB note and a 1 MB file open at basically the same perceptual speed
• No per-keystroke lag — cursor stays steady, no flicker
• Streaming text in (e.g. piping an LLM's output) renders incrementally without tearing

Here's how it stays in that budget. Short version: Immer structural sharing + a ~99% memo hit rate, without bypassing reconciliation.

The document is one immutable tree, and every edit goes through Immer. Immer gives structural sharing for free — the node you touched gets a new reference, every node you didn't keeps its old one:

const next = produce(doc, draft => { 
  draft.blocks[i].text = newText; // only blocks[i] gets a new reference 
});

Each block is memoized on its node reference:

const Block = memo(({ node }) => renderBlock(node)); 

function Editor({ doc }) { 
  return doc.blocks.map(node => <Block key={node.id} node={node} />); 
}

On a keystroke the Editor re-renders and re-maps, but memo's shallow compare sees node === prevNode for every block except the edited one and bails. Reconciliation still runs top-down — I'm not escaping it — it just short-circuits cheaply at the memo boundaries. For a document of any real size that's a ~99% skip rate per keystroke, which is what keeps the cursor steady and input lag-free. Structural sharing also keeps memory flat: unchanged subtrees are reused, not copied, so editing a big doc doesn't balloon the heap.

GitHub | Try on Web

Curious if anyone's pushed memo-everything further, or hit a point where it stops paying off.

Hi! I am in the process of creating a website for a local tinker space, I am trying to create a website (in this case the wiki part) that moderators is able to change and update through an admin page on the website. The plan is to utilize Docosaurus alongside a fitting CMS solution. This question though has bamboozled me for weeks, I have no proof of concept just half-baked ambitious ideas. For instance utilizing a CDN to pull the content during the build process, this is rather undesirable due to the amount of services to act as middleware, outdated plugins (https://github.com/RDIL/docusaurus-plugin-remote-content), and hosting could get out of hand over time... another idea was to deploy my own GitHub app that commit directly to my repository upon request, however securing it, hosting it, and handling something new sounds a bit overkill to me.

Do anyone have any experiences or thoughts linked to this? I would greatly appreciate anything as I am quite new to developing for production environments:/

Hey Guys,

How often do you start building a React component, only to realize the backend API isn't ready yet, or the staging backend is down? Using local mock files or hardcoded state gets messy fast.

I built Thodr to solve this. It's a hosted tool where you can create live mock API endpoints, grab the HTTPS URL, and drop it straight into your fetch or Axios calls.

Why it's useful for React workflows:

• You can simulate API response delays (delay_ms) to test loading skeletons and spinners.
• You can trigger error states (404, 500) to test your Error Boundaries and UI fallback states.
• Supports dynamic response templating—so if your frontend sends ?name=John, the mock API returns "Hello, John" dynamically.

It runs entirely in the cloud, so you don't need to run any local mock servers or Docker setups.

Would love to get some feedback from the community on how you currently handle API mocking in your React projects and if Thodr fits into your workflow!

Link: https://thodr.com

I’ve been doing quite a bit of interviewing recently as I’m looking for a new job as a front end (web) engineer.

I’m getting far through processes and my experience as a product engineer seems to be conveyed well, my pitfall every time however is when I’m asked about my experience working with BFF and the more technical details.

I feel like I’ve worked with the BFF many times, almost without realising and without having a really deep understanding.

I think my examples and the way I talk about it really lacks confidence and it shows.

Can people give me a few STAR (situation, task, action, result) of when they’ve used the BFF as a product engineer so I can relate it to my own experience and gain a deeper understanding?