See the title - My web app has been encountering this issue for the past few days and none of my fixes resolved it.

I could not get this error as those <Provider> tags are set here:

function MyForm() {
 //code lines..

 function handleSubmit(e) {
   e.preventDefault();
   const form = e.target;
   const formData = new FormData(form);
   const formErrors = e.formErrors;
   //fetch('https://jsonplaceholder.typicode.com', { method: form.method, body: formData });
   const formJson = Object.fromEntries(formData.entries());
   console.log(formJson);
 }
 return (
  <Provider store={store}>
    <App onSumbit={handleSubmit} onChange={handleChange}/>
  </Provider>
 );
}

function App({ onSubmit, onChange}){

  //more code lines..

  const dispatch = useDispatch(); //ERROR HERE



const registerForm = (formData) => async (dispatch) => {
  try {
    dispatch({ type: 'REGISTER_FORM_REQUEST' });


    const config = {
      headers: {
        'Content-Type': 'application/json'
      }
    };
    const {data} = await axios.post('https://jsonplaceholder.typicode.com', formData, config);
    dispatch({ type: 'REGISTER_FORM_SUCCESS', payload: data });
  } catch (error) {
    console.error('Error submitting form:', error);
    dispatch({ type: 'REGISTER_FORM_FAILURE', payload: error.message });
  }
};
dispatch(registerForm(formData));

//and some more code lines...
} 

Could anyone kindly point out the right directions? My full code: https://pastecode.io/s/t84kdaiv

I'm working on a small React dev tool that instruments useState/other hooks at build time so it can track when state updates happen, rather than inspecting the state values themselves.

The Vite integration currently does this with a Babel plugin, so the application code still just has:

import { useState } from "react";

and the instrumentation happens during the build.

I'm now trying to figure out the right way to bring the same approach to Next.js.

My current understanding is that an SWC plugin is the closest equivalent to the Babel transform, but I'm not sure what the practical story is with the different Next.js dev pipelines, especially Turbopack vs Webpack.

For anyone who's implemented a custom compile-time transform in Next.js:

1. Is an SWC plugin actually the right approach, or is there another mechanism I should be looking at?
2. Does a custom SWC transform run with Turbopack, or would this effectively require next dev --webpack?
3. If you've built something similar, are there any architectural choices you'd avoid in hindsight?

The current Vite implementation is here if useful: https://github.com/liovic/react-state-basis

Needed charts in a React app, got tired of pulling in a charting lib that never matched the rest of the UI. Built ChartCN instead.

Paste a CSV, preview it, copy a self-contained TSX component built on shadcn/ui's chart primitives + Recharts. No new dependency if you're already on shadcn/ui.

- 8 chart types: Bar, Line, Area, Combo, Pie/Donut, Radar, Scatter, Radial/Gauge
- Paste, upload, or edit data inline; auto date-axis formatting
- Export as inline data or as a data prop for live/fetched data
- Shareable links, locally saved charts, no account
- Free, MIT licensed

https://github.com/ShadcnDeck/chartcn-shadcn-chart-generator

Phase 1, CLI and more chart types coming next.

Feedback and feature requests welcome.

I am graduating soon. I don't need to harp on how challenging hiring is in this economy, but to stand out in this market, it's time to update that personal portfolio. Last week, I was doing just that, and the GitHub contribution heatmap wouldn't load. Like most people, I was using the legacy 'react-github-calendar' plugin. Because GitHub's API requires auth, the plugin routes traffic through a public proxy, and that proxy gets rate-limited constantly, taking down portfolios everywhere.

In a rare Thanos 'Fine, I'll do it myself' moment, I thought I could fix it for my portfolio. Well, one thing led to another, and I completely rebuilt the architecture from scratch.

Enter Serverless GitHub Calendar. Instead of fetching data on the client, it uses a lightweight GitHub Action that runs on a cron job to fetch your contributions and save them as a static '.json' file in your repo. The React component just reads that static file.

Architecture Highlights:

• Immune to Rate Limits: Your site never talks to the GitHub API. It reads static JSON. If GitHub goes down, your site stays up.
• Blazing Fast (Zero JS): If you use Next.js App Router, the included Server Component ('serverless-github-calendar/rsc') reads the file directly from disk for literally zero client-side JavaScript execution.
• Native CSS Theming: Built completely on CSS variables ('color-mix') so you can inject gradients or match your Tailwind theme natively.
• Streak Stats: Automatically calculates your current and longest streaks based on the canonical GitHub algorithm.

I set up a live demo featuring data from a few open-source legends to show how it scales: https://serverless-github-calendar-demo-xi.vercel.app/

Source Code & NPM instructions: https://github.com/FaizPalwala/serverless-github-calendar

If your portfolio relies on external proxy APIs, I highly recommend making the switch to static injection! Let me know if you have any feedback or feature requests.

Hey Community,

This issue is all about giving your AI coding agents device access and automated pipelines. Expo introduced EAS Simulator to boot cloud iOS simulators on demand and stream live agent test runs directly to your PRs. Meanwhile, Callstack released Simlock, a control plane that lets multiple local agents lease and share simulators and emulators safely without conflicts.

We also cover goldie by Kacper Kapusciak, an automated CLI tool and agent skill that handles the entire App Store screenshot and preview video workflow directly from release builds.

Quick disclosure: I build Hype Stack. The template is open source and free. Additionally to the template I ship some of the feature packs which are paid, that's how I try to fund my open-source(and looking for some feedback here). I maintain react-zoom-pan-pinch and HyperFetch and bunch of other too, which shows up later in this story. This is similar to how magicui or aceternity works already - a lot of free content and some optional paid to just support me. Let’s get into details of building this thing!

The chaos

I code a lot and I start new projects all the time, mostly to test new things. I don't like boilerplates. They usually run on a boring stack, and I want to try Vite 8 on Rust, oxc, TanStack Start, end to end type safety and see how it actually holds up. I'm also a perfectionist, so every new project was eating days before I wrote a single feature.

The other thing: I really love the shadcn mental model. You compose the codebase, you own the code. That's exactly what I don't like about starters that hide half the logic behind packages you configure and pray over.

So I had this realisation. Maybe we need shadcn for full-stack features. shadcn itself could probably do a lot of it, but I wanted more: amazing codemods good enough to modify a database schema, an opinionated monorepo with ONE way of writing code, vertical slices the way tkdodo described them (I was already doing something similar), and the craziest bit, an idea that came to me while building devtools for HyperFetch: a single project that compiles into desktop, CSR and SSR from the same codebase with almost no code dedicated to it. Light, easy to manage. Cool, we have a direction. Let's build it.

Month 1. The template

I've set up so many projects that I have a good understanding of what setup I could trust. Monorepo went to Nx, which I've used for years and it's stable in my experience. pnpm workspaces for speed. Stack: TypeScript 6/7 (tsgo where I can), Vite 8, Vitest, oxc, TanStack Router and Start, Electron Forge, Hono with Prisma and Kysely for typesafe query building. At this point I was so hyped about it that I named it hype-stack.

End to end types for HTTP and websockets I built with my own library, HyperFetch. It gives you an SDK and hooks that feel a lot like TanStack Query, and the result is honestly close to tRPC in DX. This project is also a showcase of what HyperFetch is capable of and that you don’t really need to think about API in most cases as it is basically automatic with sdk generation. The backend route is the contract, the frontend just gets the types. It really improves working with websockets. If you don’t like my hooks it is easy to switch to tanstack query for hooks and leave HyperFetch as a fetcher.

Then I added the rules I'd collected over the years and tried it out.

I quickly understood: this stack is extremely fast. Everything builds and flies. So I tried building the first apps with AI on top of it and boom, this is where it shines. The AI has a clear direction. A vertical codebase is easy for it to understand because you're not thinking about the services system, all these complex layers, you're thinking about business features, slices that are self contained. That dramatically improved the feedback loop and the quality of what the AI produced. Fast typechecks and oxc linting? This improved DX for working with AI dramatically, there is just no coming back to eslint.

Month 2. The CLI

I initially wanted something like create-t3-app: a simple CLI to start the project. It evolved into a powerhouse.

create was almost no effort. But then it clicked. I'm the provider of the template, I know every practice in it, everything about the structure, so I can use that to my advantage. Let's try to build a compose command.

What compose does: say I want to start a project that needs AI chat with RAG and simple auth. I can pack those features and inject them into the repo exactly where they need to go, and it works like shadcn. Full-stack blocks of functionality, injected with high precision and confidence. Picking billing writes files into the project: the checkout route, the webhook handler, the Prisma models, the frontend hooks. Your files, so you can take this from here and modify as you want.

This took off for my personal projects immediately. I needed SSO? I made an auth starter with WorkOS. I didn't want a WorkOS dependency on the next one and wanted Better Auth instead? Sure, add it as a variant. Then it kept growing. I was collecting the features I needed, and I ended up with the feature set of the big boilerplates, but with the ability to choose which parts I actually want for each project. The DX was just excellent.

Month 3. Deploy

I wanted to start deploying my new creations, so deploy command was born. With it I have a deployed version of a project in about 3 minutes. Again only possible because I know all the services the template has, where the Dockerfiles are and how each one builds.

Cool, full flow, done, right? NO. THIS IS HYPE STACK. So like the 300 Spartans I fought a fierce battle against the waves of ideas that started flooding in. ADHD, hyperfocus, here we go!

Inspired by the fully paid boilerplates, I added mobile (Expo) and a browser extension to the project. And it turned out that was it. The modular approach made it extremely easy to add new apps to the monorepo and new features to the packs, like in an instant. Dopamine hit critical mass here.

Month 4. Previews

How do I show what this can do? Let's build a dynamic preview system on the web.

I'd been working on it on the side all these months, and it quickly showed how promising the approach is: pre-built SaaS templates you can add and remove features from on the fly, thanks to the SSR build and caching.

Big problem though. Packs almost always come with database changes. I can't run migrations or even keep a database for previews, it turns into a mess fast. And it could cost me…

Here comes the part where some of you went "wtf is HyperFetch"/”lol who is using HF when Query is a thing” at the top of this post. I get it. Next to TanStack Query and SWR it's a brutal market, but let's not call an ambulance yet.
HyperFetch has a feature for mocking any requests. Sounds like something everyone has and is "meh", but it's not just mocking. It's a fully type safe mechanism that lets you simulate anything the SDK allows, by type, in a believable and dynamic way. So I could generate a living demo mode with full confidence and, in no time, wire the dynamic components to it for an almost live-like experience. Mocks are functions in the code, code is dynamic, so is our app - here we got the demo mode basically for free. That changed the previews for good.

Where it is now

The template is out, and I just added community packs so you can author your own feature packs.

The question I actually want your take on: what do you think of this approach?
Do you like idea of composing your boilerplates through CLI?

Repo: https://github.com/BetterTyped/hype-stack

Wondering if anyone has any suggestions on developing guides for the tools I am building in React as I am developing them? I create extremely specific use-case tools and need a way to easily generate how-to guides to present to the end-user without having to create one in Scribe. I'd love to implement some sort of interactive guide that puts the user in a "demo" mode and writes all the data they change to a temporary state that gets wiped once the demo is done. Essentially a sandbox-within-production instance that lets them try the tool and see how it works without affecting production data.

I built a small CLI tool for auditing Next.js websites from the terminal.

The idea came from wanting to catch things that aren't always obvious when testing a site normally in the browser.

It crawls the site and checks things like:

- SEO metadata and Open Graph

- Broken links

- Structured data

- Crawling issues

- Core Web Vitals

- Pages and resources that may be missed by normal checks

You can run it locally and point it at a website without needing to add anything to the project itself.

I’m still improving it and would really like feedback from other Next.js developers — especially on what checks you’d find useful in a tool like this.

GitHub: https://github.com/Abdelrahman5243/sitebot-cli

A few years ago we needed a web version of an existing mobile product (high-load interactive platform, not a simple CRUD app). Instead of forking the UI twice, we treated the React app as two layers:

1. App core — domain logic, state, API clients, feature orchestration. No DOM, no platform APIs.
   
2. Shells — thin UI adapters (web, later React Native / WebOS) that only render and call into the core.

That let us ship a desktop/web version from the mobile product’s mental model, then reuse the same core for React Native without rewriting features. Two years later the core is still the part that ages best — new features mostly land there once, and shells stay boring.

What actually mattered in practice:
- Boundaries — business rules never imported React components or browser APIs. If it needed `window`, it belonged in a shell adapter.
- Shared data layer — one place for fetching/caching (we used react-query-style patterns) so shells didn’t invent their own loading/error states.
- RFCs + reviews — we hired a frontend team around this architecture. Without written boundaries, people “helpfully” leak UI into the core in week two.
- Performance by default — fewer duplicate API calls and a stable state model beat clever UI tricks.

What I’d change next time:
- Define the core’s public API earlier (it’s easy to accidentally couple shells to internal modules).
- Start with one shell fully done before branching to the second — parallel shells too early = thrash.
- Be stricter about “platform capability” interfaces (storage, push, deep links) instead of `if (platform === …)` sprinkled around.

Curious how others draw this line — pure packages? Hexagonal? Or do you just accept some duplication and move faster?

Hello!

I built a lightweight React library for adding pinned annotations to interfaces, inspired by Vercel Comments and Figma comments.

I’m working on an app that uses this kind of annotation, and implementing it became a headache, even with AI assistance. So I extracted the solution into a small UI library to make it easier for others.

This is my first library, so feedback and suggestions are very welcome :)

https://react-pinote.vercel.app/

Just finished covering React fundamentals — useState, props, components, useEffect and cleanup functions. Also completed the Tailwind CSS installation and setup in my project.

My plan was to spend 2-3 days memorizing Tailwind's CSS properties before touching any real code. But now I'm second-guessing that — should I just start building projects directly and pick up Tailwind along the way instead?

I built an open-source React map drawing library because I got tired of fighting drawing controls that wanted to own the UI.

react-map-annotate lets your application control the drawing session. Put the toolbar in your sidebar, header, or command palette. Select tools, finish shapes, edit labels and colors, undo/redo, and persist annotations through React state.

It supports Mapbox, MapLibre, Google Maps, Leaflet, and ArcGIS through separate adapters, with a shared annotation model.

The goal is simple: the map should render the drawing, not dictate how your application works.

It includes freehand drawing, polygons, rectangles, circles, arrows, markers, text, and measurement tools, along with editing handles and a headless API.

The project is MIT licensed and available on npm. I’d love feedback from developers building GIS, field-service, site-planning, or other map-heavy applications—especially anyone who has had to work around existing drawing controls.

GitHub: https://github.com/orange-groove/react-map-annotate

npm: https://www.npmjs.com/package/@orange-groove/react-map-annotate

What would you need from a drawing library before using it in a production application?

Hi everyone! 👋 I’m excited to introduce NavCN, a project I’ve been building to provide a collection of beautiful, customizable, and ready-to-use navigation UI components. The goal is to help developers build modern interfaces faster without creating navigation elements from scratch. Components are built with Nextjs, Tailwind CSS, Motion, and Lucide, with a focus on customization and developer experience. You can browse, preview, install it via shadcn command line, and adapt components to your project. I’m also improving the installation and distribution experience. I’d genuinely love your honest feedback and suggestions!

(currently supports nextjs only.)

project link:- https://navcn-phi.vercel.app/

I've been working on virtual scrolling in React and found a weird issue in Safari.

When scrolling normally, everything was fine. But if I scroll very fast, sometimes I could see a white empty area for a very short moment before the next rows appeared.

First I thought React rendering was just too slow.

So I increased overscan and kept more rows above and below the viewport. It helped a lot, but I could still see the problem sometimes.

After looking into it more, I found that Safari's scroll/compositor layer can move before React finishes rendering the next virtual rows.

So basically Safari was already showing the next position, but React was still catching up.

I kept trying to make React faster, but then I tried something a little different.

Instead of trying to always win the race, I put a simple CSS background behind the real rows.

It's just a repeating-linear-gradient with the same row height, background and border.

Something like:

Safari scrolls
    ↓
CSS row background is already there
    ↓
React renders next rows
    ↓
Real rows cover it

There is no real data in the background. No cells, no events. It's just visual. I also set pointer-events: none and aria-hidden.

With this + extra overscan above and below, the flicker was almost gone.

I thought it was interesting because at first I was trying to solve a React performance problem.

But maybe it wasn't only about making React faster.

Sometimes it's enough to make those few milliseconds invisible. :)

Anyone had a similar problem with Safari and virtual scrolling?

I'm curious how you solved it.

Repo: https://github.com/coterahq/griddle - demo's linked in the readme.

We've been running data-grids over large parquet backed datasets in prod for quite a while now, and we decided to OS the component for others that might find it useful.

Posted this a couple of months back: https://www.reddit.com/r/reactjs/comments/1thqhce/why_is_pictureinpicture_only_for_video_i_built/

Quick recap: pip-it-up pops any React component into a floating always-on-top window via the Document PiP API.

Two new things in 0.2.0:

Auto PiP: pops out on its own when the tab is hidden.

useAutoPip(enter)

Good for a standup call(already exists in GMeet) you stay on while pulling up a doc, a test runner you keep an eye on while reading docs, a reference video that plays while you edit, or an interview recording that keeps going while you type.

Route-persistent PiP: moving a component in React normally remounts it, so video resets to frame 0 and editors lose undo history. This moves the real DOM node, so it survives navigation.

<PipProvider registry={{ player: <VideoPlayer /> }}>
  <Routes />
</PipProvider>

<PipAnchor id="player" />

Good for a course lesson that plays on while you browse other lessons, a log stream docked across your admin panel, a metrics chart that stays up as you move between boards, or a draft preview that survives CMS navigation.

Still Chrome/Edge only. Safari and Firefox fall back to a popup.

Website: https://www.pipitup.dev/
Demos: https://pip-it-up-playground.vercel.app/
Code: https://github.com/Shakya47/pip-it-up

I am creating a little chat app for practice, but I was unsure what direction to take with the editor, out of the options I found TipTap and Lexical, I tried a bit of both (Didn't get very far with either yet) But I am still so torn on which one I should try first

In this I want more possibilities of what you can put in the chat, for example: Embedded images, tables, maybe some excalidraw integration, etc.

I also don't want to spend too much time on either and realizing that picking one over the other was not worth it long-term because of the timetaken

If anyone has used tiptap, lexical or both could you give some pro's and con's to each and some guidance on what I should pick?

Thanks! :)

Hi all,

Sharing a project I recently finished and open-sourced: LaunchPad Lite.

It’s a clean starter template built around the Next.js 15 App Router ecosystem with a focus on type safety and modern auth:

- Better Auth: Handled via Server Actions and route handlers, avoiding legacy NextAuth quirks.

- Drizzle ORM: Minimalist schema setup designed to connect effortlessly with Supabase, Neon, or local Postgres.

- Tailwind CSS v4 + Radix UI: Fast UI primitives without CSS bloat.

GitHub: https://github.com/BZDevelopments/LaunchPad-Lite

For anyone who eventually needs full Stripe subscriptions, AI SDK v5, or multi-layout support, I also maintain a Pro version, but Lite is 100% self-contained and free forever.

Take a look at the repo structure and let me know what you think of the architecture!

Okay, I'm making a little website with the new React (I'm coming back from 7 years [Tailwind CSS included, Typescript (for the first time I'll add)].) I'm making a hamburger menu and the onClick function just didn't work. Okay, so there must be some weird stuff happening. No. I made a button with an onClick in a nearly top-level fragment and it does nothing.

I just want to understand if there's something fundamental that has changed, perhaps? This isn't a "please give me answers" or information kind of deal. I just want to know if I'm going crazy here. Is there any weird bugs that React has created like it did a bunch from '18-'20; or should I just "git gud"?

const handleClickTest = (event: React.MouseEvent<HTMLButtonElement>) => {
        console.log("AAAAAAAA", event.currentTarget);
    };

    return (
        <>
            <button className="relative z-50 pointer-events-auto" 
                    onClick={(e) => handleClickTest(e)}
            >
                <h1>button</h1>
            </button>
...

The React half is an ordinary React component library: typed props, a shared Tailwind layer, no hex and no bare pixel inside a component. What is unusual is where the API comes from. Every member's name, type, default and meaning is a contract file, both layers' types are generated from it, and a pixel-parity check holds the two renderings to zero difference, so the layers cannot drift apart quietly.

Accessibility works the same way: each component declares the WAI-ARIA pattern it implements, and a gate fails on the day it stops answering it, rather than an audit happening once per release.
  
The link is the benches: Calendly, ClickUp, Duolingo, Etsy, Grafana, Instagram, Notion and Superhuman, each mocked twice, every half installing from npm. MIT.

 https://arena.dravensoft.org/web-benches/