Hey r/reactjs,

Like many of you, I've used React Hook Form and Formik across several production projects. While they're powerful, I always felt friction with how modern form libraries force you to treat standard HTML forms as legacy: - Having to manually register every input with refs: {...register("email")} - Wrapping UI components in custom controllers - Giant bundle sizes once you add schema resolvers and adapters

I wanted to see if we could go back to standard HTML5 forms as the single source of truth without sacrificing React ergonomics or type safety.

So I built Native Form: * GitHub: https://github.com/sunilsv26/native-form * npm: npm i @native-form/react

What makes it different?

• Zero Input Registration: You write plain HTML inputs with standard name attributes (<input name="email" />). Native Form discovers them automatically from the DOM via MutationObserver.
• Uncontrolled DOM-First Performance: Keystrokes don't trigger component re-renders. Your view only re-renders when form state (validation errors, submission status) actually changes.
• Microscopic Schema Adapters: Adapters for Zod, Yup, and Valibot are under 500 bytes. The core runtime has zero third-party dependencies.
• Built-in Multi-Step Memory: useWizard and preserveUnmountedValues: true keep your unmounted step values hydrated without complex state contexts.
• Framework Agnostic Under the Hood: The core runtime (@native-form/core) runs in pure Vanilla JS, Vue, or Svelte, while @native-form/react provides React 18 & 19 hooks (useForm, useField, useWatch, useWizard).

Quick Example:

```tsx import { useForm } from "@native-form/react"; import { zodResolver } from "@native-form/zod"; import { z } from "zod";

const schema = z.object({ email: z.string().email(), age: z.number().min(18), });

export function Form() { const { formRef, formState } = useForm({ schema: zodResolver(schema), serializationMode: "typed", // automatically coerces type="number" and range to numbers onSubmit: (values) => console.log("Submitted:", values), });

return ( <form ref={formRef} noValidate> <input name="email" type="email" placeholder="Email" /> {formState.errors.email && <span>{formState.errors.email}</span>}

  <input name="age" type="number" placeholder="Age" />
  {formState.errors.age && <span>{formState.errors.age}</span>}

  <button type="submit" disabled={formState.submitting}>
    {formState.submitting ? "Submitting..." : "Submit"}
  </button>
</form>

); } ```

I recently released v0.1.2 with fixes for discrete controls, range sliders, and custom design system integration (like Material UI).

I'd love to hear your feedback on the architecture, API design, or any edge cases you'd like to see covered!

I have been thinking about this a lot lately. Most React content is about how to do things, but the decisions that really shape a project are the big early ones: architecture, state management, framework choice, rendering strategy.

And with React 19.x, the React Compiler, and Server Components all in the picture, a lot of us are now living with choices we made years ago.

So I’m curious about the experienced people here:

• What was the biggest React/architecture decision you made that you would reverse if you could?
• What did it cost you (time, performance, team confusion, rewrites)?
• What did you learn, and what would you pick today instead?

WhoRuled is an interactive world-history map. Stack: Astro (static), one React island for the Canvas 2D map, TypeScript strict, deployed as static assets on Cloudflare, no backend. Facts live in CC0 JSON keyed by Wikidata QID, and a pipeline imports rulers from Wikipedia with source URL and quote. Every claim needs a source or the page isn't indexable.

Things I learned: preloading the two pixel fonts took CLS from 0.425 to 0.000, and the build generates 1,600+ SEO pages from the data. Repo: WhoRuled. Feedback welcome, especially on the data model.

This is my own project. rudra-js is an open-source TypeScript library (MIT) for React stores. A language model designs one product-recommendation block, the library checks it against your catalog, and React renders it.

The model never writes HTML or JSX. It returns a few fields: layout, headline, copy, which cards to highlight. Products are SKUs from the list you pass in. Titles, prices, images and links come from your catalog at render, and the model's text is rendered as escaped text. Each field also goes through wording checks, and a field that fails is dropped. They aren't airtight: rewordings and spelled-out numbers can get through.

It works as a Server Component, with renderToString, or client-rendered. Rendered on the server, the block is in the first HTML response with no client JS. React 18 or 19, Node 22.12+.

It also runs with no model, so the quick start needs no API key.

It's v0.8.3 and APIs may change before 1.0. I'd like feedback on the API shape and on what breaks in a real Next.js app.

https://github.com/clivedsouza1010/rudra-js

​

Hey everyone!

I've been working on a learning garden where I write technical deep dives into frontend development, with a focus on understanding how things actually work under the hood rather than just learning APIs.

Currently, it has three main learning paths:

- How React Works — Understanding React's behavior from the ground up.

- React Internals — A source-level tour of React 19, from "createRoot", lanes, and fibers to hooks, the commit phase, and the React Compiler.

- Next.js in Practice — Exploring Next.js concepts and how they work in real applications.

My goal is to make these topics easier to understand by connecting the underlying implementation to what we experience as developers.

I'm particularly interested in the details that are easy to overlook when building applications every day: how updates are scheduled, what happens between a state change and a DOM update, and why the framework behaves the way it does.

You can check it out here: https://garden.drhexe.ir

I'd genuinely appreciate feedback, especially on the technical accuracy, depth of the explanations, and what you'd like to see covered next.

If you're interested in React internals, framework architecture, or understanding frontend beyond the API level, I'd love to hear your thoughts!

Hi all, I want to share a WebSocket library I built, chanx-js. It makes the messages on both ends of a socket typed, keeps the frontend in sync with what the server really sends, and comes with React hooks.

Every realtime feature I built in React ended up the same way. lastMessage was any, so I wrote the message types by hand and found out the backend had changed them only when something broke in production. On top of that I kept rewriting the same reconnect logic and the same switch over message types in every project.

How it works, in three steps: `

1. The server declares its messages and handlers. Here with chanx-js on Node:

​

const Chat = defineMessage('chat', z.object({ text: z.string() }));
const Notice = defineMessage('notice', z.object({ text: z.string() }));

const chat = consumer('/ws/chat/{room}', {
  name: 'chat',
  groups: (conn) => [`room.${conn.params.room}`],
}).on(Chat, { output: Notice }, (m, ctx) =>
  ctx.broadcast(Notice.create({ text: m.payload.text })),
);

1. The server publishes those as AsyncAPI, and the CLI turns them into a typed channel:

   npx @chanx-js/codegen http://localhost:8000/asyncapi.json # writes src/generated

   // src/generated/channels.ts export type ChatToServer = ChatMessage; // { action: 'chat'; payload: { text: string } } export type ChatToClient = NoticeMessage; // { action: 'notice'; payload: { text: string } } export type ChatReplies = { chat: NoticeMessage };

   export const chat = defineChannel<ChatToServer, ChatToClient, ChatReplies>()({ name: 'chat', address: '/ws/chat/{room}', });

2. Your component uses that channel with useChannel:

   import { createClient } from '@chanx-js/client'; import { ChanxClientProvider, useChannel } from '@chanx-js/client/react'; import { chat } from './generated';

   const client = createClient({ baseUrl: 'ws://localhost:8000' });

   function ChatRoom({ room }: { room: string }) { const { status, messages, send } = useChannel(chat, { params: { room }, buffer: 'all', });

   return ( <> <p>{status}</p> {messages.map((m, i) => ( <p key={i}>{m.payload.text}</p> ))} <button onClick={() => send({ action: 'chat', payload: { text: 'hi' } })}> Send </button> </> ); }

   root.render( <ChanxClientProvider value={client}> <ChatRoom room="lobby" /> </ChanxClientProvider>, );

params must have room because the path does, m.payload.text is a string, and send({ action: 'chat', payload: { txt: 'hi' } }) fails to compile. When the backend changes a message, you regenerate and TypeScript shows every place to fix.

What else it gives you:

• const reply = await request({ action: 'chat', payload: { text: 'hi' } }), with the reply typed from ChatReplies
• Reconnects, and topic subscriptions (room:lobby, ...) restored after a reconnect
• lastMessage for the latest message, or an on map with callbacks that don't re-render, and batch: 'raf' for busy streams
• The server side too: one validated handler per message type, AsyncAPI docs generated from the code, broadcasts across instances through Redis

The backend needs to be a chanx server, since the client relies on its message format and the AsyncAPI it publishes. That can be chanx-js on Node (ws, Express, Fastify, Hono, NestJS), Bun or Deno, or chanx on Django and FastAPI, the Python version I started with.

• Repo: https://github.com/chanx-dev/chanx-js
• React guide: https://js.chanx.dev/client/integrations/react
• npm: https://www.npmjs.com/package/@chanx-js/client

It's still new on the JS side, so if you run into any problem or have ideas to improve it, please open an issue or a discussion. Stars and PRs are welcome too.

I use AI when coding, but I don’t want to lose the ability to work through a problem without it. It’s easy to get working code now. Understanding what it does, why it breaks, and whether a suggested fix is actually right still takes practice.

That’s why I built Debug React: https://debugreact.com

You get a small broken React app and a bug report. Investigate it, fix it in the live editor, run behavioural checks, and explain your reasoning. Then review someone else’s proposed fix for the same bug. Some look right but miss something important.

The idea is to do the exercises without AI. Documentation, debugging tools, and built-in hints are welcome. I wanted a place to keep practising the understanding that comes from figuring things out yourself.

Four scenarios so far, covering async requests, list state, failed saves, and effects and event listeners. Each takes about 20 minutes. Free, no account, no scores. Progress stays in your browser. Best on a computer.

If you try one, I’d love to hear what was confusing, whether the checks felt fair, and which React bug you’d want next. Honest feedback welcome, including the critical kind. Thanks for taking a look!

While developing a tool for designing products directly in code, I kept running into the same issue: AI agents recreating basic UI components for every project, often with inconsistent styles and token structures.

So I created Varelyo UI, a React/TypeScript component library with typed APIs, predefined states, variants and a three-layer token architecture:

Core - base design values

Semantic - tokens that define how those values are used

Component - component-specific styling

You get the actual component source code to use and modify in your own projects. You can change the brand through tokens, customize components and extend the system as your product grows.

I originally made this for my own workflow, but decided to open-source it under MIT. It works independently of my desktop tool or any AI agent.

GitHub: https://github.com/varelyo/ui

Would appreciate feedback on the component APIs and token architecture.

Hey everyone,

I built an interactive 3D tactical command center using React and CesiumJS to track real-time global telemetry feeds.

Key React implementation details:

• Canvas & WebGL Integration: Synced Cesium's render loop with React state without triggering unnecessary re-renders during high-frequency telemetry updates.

• Custom Hooks: Encapsulated live ADS-B flight feeds, orbital satellite calculations (SGP4), and threat feeds into dedicated streaming hooks.

• Performance: Avoided standard React DOM nodes for map markers; batched updates directly into Cesium primitive collections to maintain a smooth 60 FPS.

• Dynamic Telemetry: Global fiber optic lines, data centers, and live GNSS interference zones rendered dynamically.

Looking for feedback on React state management patterns when handling high-frequency WebGL data streams!

(Live demo link added in the comments below)

I was building a web app and wanted Excel files to live within it and be fully modifiable / saveable, but couldn't find anything open source that fully fit the bill. I ended up building the repo below.

Basically full Excel functionality in our React app including:

• Import .xlsx and csv file, export to .xlsx
• Fully preserves existing Excel formatting
• Real-time calc that's a heavily modified fork of ironcacl
• Formulas and calculations
• Multiple worksheets
• All the formatting options you'd use on day-to-day basis
• Fully open source

https://github.com/pixelsmasher13/gridpath. Please let me know if you end up trying it out.

Skeleton screens always felt like a guess to me: grey bars in roughly the right shape, then the real content pops in somewhere slightly different.

So I built Arrivo. While loading is true, an effect plays exactly where your content will land. When it turns false, the real elements are revealed in place.

Demo : https://tuancuongpham.github.io/arrivo/ 

Code: https://github.com/tuancuongpham/arrivo

npm i u/brottin/arrivo

import { Reveal } from '@brottin/arrivo';

import { halftone } from '@brottin/arrivo/effects';

<Reveal effect={halftone} loading={isLoading}>

  <ArticleCard post={post} />

</Reveal>

How it works:

• Your content stays in the DOM, hidden with visibility, so nothing shifts when it lands.
• Each wrapper gets one canvas overlay. Text lines are measured with Range rects and images are read from the page, so the effect draws the real shape of your content instead of a guess.
• An effect is two draw functions, idle() and reveal(p). One shared requestAnimationFrame loop drives every instance, off-screen ones pause, and reduced motion turns every reveal into a 150 ms fade.
• Zero runtime dependencies, about 8.5 KB gzipped for the core and 0.7 to 3.4 KB per effect, tree-shaken.

The 13 effects: split-flap, redacted, quadtree mosaic, CMYK halftone, CRT tune-in, ink (with 8 threshold maps), particle swarm, darkroom, Tetris, fuse (with a Lunar New Year mode), equalizer, thermal and snowfall.

It's 0.1.0, so feedback is very welcome, especially on where you'd actually use something like this and where it would be too much.

Hey everyone! 👋

I've been working on Pimolu UI, an open-source React component library focused on clean design, customization, and smooth interactions.

I wanted to share my first motion showcase, featuring some of the components, their interactions, and examples of interfaces you can build with them.

My goal is to make building modern, consistent UIs easier while keeping components flexible and developer-friendly.

This is still a work in progress, and I'd genuinely love to hear your thoughts!

• What do you think of the design and animations?
• Is there anything you'd improve?
• What would make you consider using a new UI library?

🌐 Website: https://pimolu.com

Any feedback is appreciated! 🚀

Just added 3 new components to Ovio, bringing the collection to 20 animated React components. Each available in 4 styles: Minimal, Craft, Retro, and Toy.

Built on the shadcn registry model, Ovio is for developers who want their websites to feel a little less ordinary, with motion and interactions that go beyond the usual UI.

The motion layer for developer websites.

Explore Ovio → https://ovioui.vercel.app

I recently created a complete tutorial where I build a Redux Toolkit-inspired state management library from scratch using React and JavaScript.

The goal is to understand how Redux-style state management works internally instead of only using the package.

In the tutorial, I implement:

• A custom createStore function
• Store Provider
• Reducers and actions
• Subscribers and listeners
• useSyncExternalStore
• useSelector and custom store hooks
• Redux DevTools integration
• createSlice
• combineReducers
• shallowEqual
• Thunk functionality
• Final testing and debugging

YouTube tutorial:
https://www.youtube.com/watch?v=LucUJ-5COjg

I would appreciate feedback from the community, especially on the library design, API structure, and any improvements that could make this project more reliable or easier to use.

Please note: this is an educational project designed to understand Redux and state management concepts internally. It is not intended to replace the official Redux Toolkit.

I read a few books on JavaScript and coding in general

This was in late 2025 and a few months later I started writing react js,
Ai has gotten so good at writing code, it is way better than I am.

I have pretty okay fundamentals of coding that I have been able to spin up some interesting projects with Ai.

But if you ask me what some parts of the code does, I have very little idea about it.

How can I catch up with so many years old coding experience and survive in this field if Ai learns 20x faster.

Hey everyone,

I kept writing the same code for every form in my projects: react-hook-form setup, a try/catch around the server action, mapping server errors back onto the fields, a loading state, stopping double submits, a toast, refreshing the data, resetting the form... and doing it again for every add/edit/delete dialog.

So I pulled all of that into a small package called **submitly**.

It’s headless, so it doesn’t render anything. You keep your own components (shadcn, Radix, Base UI, plain inputs, whatever you use).

What it does:

* `useCrudForm`: react-hook-form + schema validation + your action in one hook

* Works with any Standard Schema library: Zod 3/4, Valibot, ArkType

* Server errors get mapped to the right fields automatically (nested ones like [`items.0.name`](http://items.0.name) too)

* Ignores double submits while a request is in flight

* Locks the dialog while saving, so the user can’t close it halfway through a request

* `useCrudAction` for delete/toggle buttons, with the same behavior

* One provider where you plug in your own toast, router and refresh logic

* Next.js helpers: `runAction` for server actions (validates again on the server, revalidates on success, turns thrown errors into a clean result), and it handles `redirect()` from server actions properly

* Also works in plain React + Vite (there’s an example with React Router + TanStack Query)

* Around 3 kB gzipped, typed end to end, tested on React 18 and 19

Quick example:

const { form, onSubmit, isSubmitting } = useCrudForm({

schema,

defaultValues: { name: "" },

action: createProduct,

onSuccess: () => closeDialog(),

});

It’s still early (0.x), so I’d really like feedback: what’s missing, what’s confusing, or what you’d do differently.

Docs: https://submitly-docs.vercel.app

GitHub: https://github.com/toony10/submitly

If you find it useful, a star on GitHub would mean a lot. Thanks for reading 🙏

Hello. Does anyone know how to host a web application built with React—both the frontend and the backend?

Hey everyone,

I kept writing the same code for every form in my projects: react-hook-form setup, a try/catch around the server action, mapping server errors back onto the fields, a loading state, stopping double submits, a toast, refreshing the data, resetting the form... and doing it again for every add/edit/delete dialog.

So I pulled all of that into a small package called submitly.

It’s headless, so it doesn’t render anything. You keep your own components (shadcn, Radix, Base UI, plain inputs, whatever you use).

What it does:

• useCrudForm: react-hook-form + schema validation + your action in one hook
• Works with any Standard Schema library: Zod 3/4, Valibot, ArkType
• Server errors get mapped to the right fields automatically (nested ones like items.0.name too)
• Ignores double submits while a request is in flight
• Locks the dialog while saving, so the user can’t close it halfway through a request
• useCrudAction for delete/toggle buttons, with the same behavior
• One provider where you plug in your own toast, router and refresh logic
• Next.js helpers: runAction for server actions (validates again on the server, revalidates on success, turns thrown errors into a clean result), and it handles redirect() from server actions properly
• Also works in plain React + Vite (there’s an example with React Router + TanStack Query)
• Around 3 kB gzipped, typed end to end, tested on React 18 and 19

Quick example:

const { form, onSubmit, isSubmitting } = useCrudForm({
  schema,
  defaultValues: { name: "" },
  action: createProduct,
  onSuccess: () => closeDialog(),
});

It’s still early (0.x), so I’d really like feedback: what’s missing, what’s confusing, or what you’d do differently.

Docs: https://submitly-docs.vercel.app/
GitHub: https://github.com/toony10/submitly

If you find it useful, a star on GitHub would mean a lot. Thanks for reading 🙏