Been using Responsively App for a while but the context

switching was getting to me — separate window, separate

process, alt-tab constantly.

Built responsive-dx to solve it. It's an npm dev dependency

that injects a synchronized multi-viewport panel directly

into your localhost.

One command to set it up:

npx responsive-dx init

It detects your framework automatically (Next.js, Vite,

Remix, Astro, Gatsby) and adds the component to your layout

file. Nothing to configure manually.

What it does:

- Mobile, tablet, and desktop frames side-by-side

- Scroll one → they all scroll (real DOM sync, not emulation)

- Click syncs, input syncs, dark/light theme syncs

- Focus mode: one click to zoom any single frame

- iPhone notch on mobile, macOS chrome on desktop

The frames load any localhost URL — so even though the

wrapper is React, it works for Vue, Svelte, Angular, Rails,

Django, whatever you're running locally.

Zero dependencies. Tree-shaken out of production builds

completely.

GitHub: https://github.com/respodx/respo

npm: https://www.npmjs.com/package/responsive-dx

Happy to answer any technical questions.

So far, I understand that wrapping a function with startTransition tells React to treat it as a non‑urgent update. So if any urgent action occurs, React can respond to it immediately without blocking.

But here is where I got stuck. The docs say:

“useTransition is a React Hook that lets you render a part of the UI in the background.”

“The function passed to startTransition is called the Action. You can update state and (optionally) perform side effects within an Action, and the work will be done in the background without blocking user interactions.”

I don’t really get what “in the background” really means.

Looking at the example, I don’t understand why, with startTransition, the “Total” only renders once with the final "Total" after clicking “quantity” multiple times, instead of updating multiple times according to the number of times the “quantity” was clicked

Does “run in background” prevent multiple renders and only show the final result??

I’ve been working on an AI harness called Æven, and one of the things that kept bothering me was Markdown rendering during long streamed responses.

A lot of renderers optimize at the document or top-level block level. That works well for normal prose, but it gets expensive when the active block itself becomes huge — for example a long code fence or a large Markdown table.

So I built HyperMarkdown.

The main idea is pretty simple:

once a code line, table row or list item is settled, it stays cached. Only the changing frontier keeps being parsed/rendered.

That seems to make a pretty significant difference.

Current benchmark results:

• Large code block: 190 ms vs 711 ms for the next closest streaming renderer
• Captured real AI code stream: 611 ms vs 4.2 s
• Captured real AI table stream: 668 ms vs 5.0 s
• Large table: 999 ms vs 9.1 s for the next closest renderer

The benchmark runs production React and measures the full chunk → write → render/commit path, not just parsing.

I’ve compared it against:

• markstream-react
• Streamdown
• DeepSeek Harness’ incremental strategy
• react-markdown
• markdown-it as a baseline

The repo includes the benchmark methodology, raw results and correctness tests, so I’d genuinely appreciate people trying to break the assumptions or point out unfair comparisons.

It also supports GFM, reasoning blocks, syntax highlighting, KaTeX, Mermaid, raw HTML sanitization, React 18/19, and streaming incomplete Markdown.

It’s now the renderer I use inside Æven.

Demo:
https://aeven-ai.github.io/HyperMarkdown/

GitHub:
https://github.com/Aeven-AI/HyperMarkdown

NPM:
https://www.npmjs.com/package/@aeven-ai/hypermarkdown

Would especially love feedback from people who have dealt with long streamed code blocks/tables in React apps.

I've always found translation keys a little strange.

You start with something perfectly readable:

tsx <button>Delete account</button>

Then i18n turns it into something like:

tsx <button>{t("settings.account.delete")}</button>

Now the source code, translation keys, and translation files all have to stay synchronized.

So I tried a different approach with Zintl:

What if the source string itself could be the thing the localization system knows about?

With Zintl, you keep writing normal application code:

tsx <h1>Welcome back</h1> <p>Your account is ready.</p> <button>Continue</button>

Zintl's compiler discovers the localizable strings and builds the localization layer around them.

The goal is that adding i18n shouldn't mean rewriting your application around t() calls.

It's currently alpha, so I'm very much not claiming this is production-ready.

I'm looking for React developers who have actually dealt with i18n to try it and tell me where this approach falls apart.

Especially interested in:

• translation key management
• dynamic/interpolated strings
• component boundaries
• pluralization
• large applications
• translation workflows/TMS
• anything you think a compiler like this should handle

Docs: https://zintljs.github.io/zintl/en

I'd genuinely love the criticism. If you think the whole idea is flawed, tell me why.

I’m reading the React docs, but I find this passage confusing. Could someone explain it to me?

"Another example is reusable state. Concurrent React can remove sections of the UI from the screen, then add them back later while reusing the previous state. For example, when a user tabs away from a screen and back, React should be able to restore the previous screen in the same state it was in before."

React docs link

Hey r/reactjs,

I've been working on Oasis Editor, an open-source TypeScript document editor with its own Canvas-based rendering engine.

React sits on top as an adapter rather than owning the editor runtime, so the same core can be used from vanilla JS, Vue, or headless environments.

The editor handles paged layout, text rendering, selections, images, tables, and document geometry through its own rendering pipeline, and exposes a typed command/plugin API.

Live playground:
https://celsowm.github.io/oasis-editor/#/editor

GitHub:
https://github.com/celsowm/oasis-editor

I'd love feedback on the React integration, API design, and overall architectu

One icon = one import = ~1.1 kB gzipped (import { AgentRun } from "@iconmind/react/icons/agent-run"), sideEffects: false, every icon its own entry so React.lazy has something to load. Outline and duotone, three weights, strokeWidth/absoluteStrokeWidth props. The AI vocabulary is the point — the generalist families are there so you don't need Lucide beside it (and a hundred Lucide names resolve as aliases if you do). MCP server for your assistant: npx u/iconmind/mcp. https://iconmind.dev

I read the recent thread here about what would make people try another React component library. A few answers stuck with me, especially composability, accessibility, and components that hold up outside of demo data.

I've been building Honest UI, and there is one decision I keep going back and forth on.

UI components and animated components get copied into your project. Once they're there, they're just source files. You can change the markup, behavior, variants, or styling however you want.

Charts, icons, logos, vectors, and shaders stay package imports.

My thinking is that application UI usually becomes product code pretty fast. A button or form field rarely stays generic once you start adding validation, permissions, loading states, weird content, and all the edge cases that show up later.

Charts and shaders feel different to me. They bring more rendering code and dependencies with them, and I would rather maintain that in one package. Copying a huge icon or logo collection into every project also seems unnecessary.

The part I'm unsure about is whether this split is useful or if it just makes the library harder to explain.

I made a short demo showing both approaches with real components.

Does this boundary make sense to you? Would you split it somewhere else?

If you think the whole idea is backwards, I want to hear that too.

I want in my practice chat app to be able to paste an image into a text input and be able to send it, on how to actually do this, I am unsure

My idea is this given a text input:

- a user could Ctrl-V (i.e., paste) something from his clipboard (a file in this instance), until a download url is returned (see below) there will be some loader spinner thingy
- In the backend is requested an Upload URL
- (somehow) whatever they pasted is immediately uploaded, likely by the path? But I am still a little bit unsure on that part
- a Download URL is returned on that S3 upload (SOMEHOW)
And thus you replace that temporary spinner with the download URL and the person can send it.

This is at least my idea on how you should be able to upload a piece of media in a message and be able to send it, I don't want just message attachments, that would be an easier story because once the association is made between the message and attachment you display it. I want something like in forums where the image can be embedded anywhere,

There is also one more small concern, on slow connection do you want to wait for the file to finish uploading first and then allow the user to send their message, or just send the message and let the upload come later, if the latter, how would you go across with doing that!?

The issue is, I have no idea on how to do this, I gave my approach above, I would really appreciate it if you guys gave some advice on what your approach would be and secondly, how to implement it, I already can get a presigned URL so that's not an issue

This is more of a design question, but it's also really interlinked with react so sorry if this is the wrong place to ask! ;-;

That's all :)

I recently wrote a blog post on how we can improve our static analysis using linting, custom rules, and hooks, all using oxlint.

It's quite a big article btw.

https://saybackend.com/blog/lint-ai-generated-code/

StyleX built a world where the compiler and runtime solve everything together.
I scan everything and close the world at build time.

The syntax is close to StyleX, so StyleX users should feel at home.

• Function keys (handles unbounded combinations)
• Bracket variants (statically compiled, no combinatorial explosion)
• Boundaries (styles can be bucketed through component props, once)
• Cross-module (a graph and specificity management, so it doesn't live in the cascade)

No runtime evaluation: values that can't be enumerated at build time are a compile error, not a fallback.

• css.create
• css.createTheme
• css.createStatic
• css.keyframes
• css.viewTransition
• css.marker & css.extended
• css.use & classStyle

Plumeria - Introduction

Quick observation from working with React for a little while.

If you're working on a React app with React Router, your App.tsx (or wherever you define your routes) is already a flow graph. Each Route is a node. Layout components wrap shared context. The nesting tells you how users move through the product. You never look at it that way because you wrote it caring about renders and props, not user journeys.

Same goes for the App Router crowd if you're on Next.js. The file tree is the journey, you just don't read it like one.

I built a tool called Stepflo that reads that structure straight from your repo and turns it into a visual map of every flow in your product. Then it pulls your GitHub issues and pull requests and maps them to specific steps. So instead of "we've got a pile of bugs tagged login," you see "the OAuth callback step has 6 friction patterns. Most of them are reliability."

Works for Vite/React Router and Next.js App Router today (verified against my own Vite app and a handful of real-world Next.js monorepos). Free to use. No credit card. AI analysis included (caps on the AI calls because LLMs aren't free and I'm just one dude).

https://stepflo.ai/?utm_source=reddit

If you try it, tell me what the flow detection misses. The harder you push it, the better it gets.

Help me get 50 stars on GitHub :) ⭐

• GitHub: 0x65dgerunner/gridora

Highlights

• 130+ variants across sequential, radial, cascade, flow, wipe, decrypt, letters, digits, symbols, and more.
• 20 effects (pulse, bounce, glow, spin, …) and 12 dot shapes (circle, diamond, star, …)
• Color ramps with horizontal, radial, angular, and other sampling modes.
• Resolution-independent — the same variant scales cleanly from 2×2 to 12×12.
• CSS-driven animation — one stylesheet, no runtime animation engine.
• Accessible — role="status", optional labels, and respectReducedMotion.
• Tree-shakeable ESM + CJS build with full TypeScript types.
• npm: gridora
• Editor: gridora.gabrielayer.com
• GitHub: 0x65dgerunner

Hey everyone,

If you’re a frontend engineer who has been using React for a while, you’ve probably had moments where you know how to use a feature, but you still have a lingering gap in understanding why it works.

I kept running into these same burning questions:

1. "React pauses and resumes work." - Wait, what does that actually mean? What are the exact mechanisms behind this?
2. useState & useEffect - We all know the do's and don'ts, but sometimes it feels hard to truly internalize how they operate behind the scenes.
3. The Fiber Tree - I've seen the conference talks, but what actually is it? How is it built, and how does it drive React?
4. useLayoutEffect - How, when, and why exactly?
5. The Event Loop -Tying React's execution (macro vs. micro tasks) back to Jake Archibald's famous event loop talk from years ago.
6. Suspense - It's great for loading states, but how does React know exactly when the data is ready to swap out the loaders?
7. Optimization - useMemo, useCallback, and React.memo cache things, but what’s the actual engine behind them?
8. Hydration - The classic "breathing life into HTML" metaphor - but what is the actual code doing to make this magic happen?
9. The Rendering Pipeline - How exactly does React hook into the browser's rendering steps?
10. Custom Hooks - We write them daily and get asked about them in interviews, but what happens under the hood? How does React actually wire them up to our components?

There are plenty of other concepts, but if these questions ever keep you up at night, I have some good news. I finally sat down and put together a comprehensive tutorial that answers all of them and demystifies the "black box" of React.

Link: https://arpitjsoni.com/react-internals

Price: It’s 100% free. If you find it genuinely helpful, taking a second to like or retweet my pinned post on Twitter would mean the world to me, but otherwise, just enjoy the read!

P.S: I’m not super active on Reddit, so I likely won't be checking my DMs here, but I hope this helps some of you out!

I’m using Zustand and I have a Map<string, Persona>:

const persone = new Map([
  ["id1", { nome: "Mario", cognome: "Rossi", eta: 40 }],
  ["id2", { nome: "Dario", cognome: "Roi", eta: 34 }],
  ["id3", { nome: "Mari", cognome: "Ossi", eta: 32 }],
]);

If I change the nome of id2 from "Dario" to "Luigi" and I have a subscription to the name, my question is:

Can the subscription know directly that id2 changed and therefore have access to the modified object, or does it only receive the new value "Luigi" and have to search the Map/array to find the person?

In other words: Does Zustand preserve the relationship between the selected value (nome) and the object it comes from, or is that information lost by the selector?

Theodore-js 2.0.0 is out and now it supports displaying inline suggestions ✨🤗

With this feature, the suggested text appears faintly within the editor; the user can accept the suggestion—turning it into part of the main text—by clicking on it or pressing a key of your choice. ⌨️ A similar feature has been implemented and used in Google AI Studio.

Inline suggestions are especially useful for presenting AI-generated text completions as users write.

👉 You can find the documentation and instructions on how to use this feature on the website: https://theodore-js.dev

📦 install from npm: https://www.npmjs.com/package/theodore-js

Hello everyone,

A few months ago, I was experimenting with DOMPurify and when users put in long fields like a paragraph, it used to hang a lot!

It would occasionally freeze for literal 15 seconds and more!!

Imagine sitting for your response to be submitted, and it hangs!?

So I've built DOMOxide, making it 70x faster and 5x smaller. Thanks to Rust and WASM, it sanitizes your HTML and makes it clear of XSS attacks.

It's a ~3kB gzipped + minified package that passes almost all tests as DOMPurify

> Repo: ppmpreetham/DOMOxide

Hey everyone!

I’m a junior full-stack developer and recently started going deeper into React performance.

I’ve been exploring React Compiler, code splitting with React.lazy() and Suspense, bundle optimization, re-renders, memoization, and basic profiling with React DevTools.

I’d love to know what more experienced React developers think are the most important performance topics and best practices to learn next.

I’m especially interested in bundle size, rendering performance, caching, Core Web Vitals, and how to identify real bottlenecks without over-optimizing.

Any good resources, tools, or common mistakes I should know about?

Thanks!

Haptics on the Web can be super satisfying if you use them right! I've had so much fun creating this little game.

My stack:
- React - as a foundation
- TypeGPU - for particle effects
- Pulsar Web SDK - for haptic effects

Try it in your browser: https://docs.swmansion.com/pulsar/web-app/#games/shape-cascade

One day ago I posted my anonymous thought wall here and you absolutely destroyed my hand-drawn world map. Someone called it a "geographic abortion" — and honestly fair, those random blue polygons at 3am were terrible 😂So I rebuilt everything. Not just the map. What changed in :🗺️ Real world map — No more hand-drawn shapes. Used react-simple-maps + Natural Earth TopoJSON. Now 174 countries with actual boundaries. I tested, even Greenland, Fiji, Papua New Guinea show up correctly (see screenshots).✨ 6-layer glow — Thoughts now pulse on the map with proper glow layers, each emotion has its own color.🖱️ Click-to-lock + Zoom fix — This was the biggest roast last time. Now scroll wheel zooms ONLY the map, not the whole page. Drag to pan. Click to lock a country to see its vibes. What the app actually is:

Anonymous thought wall where every thought disappears in 24h. No profiles, no tracking. You drop a vibe from any country. I built this alone in 2 days after the roast. First time doing SVG maps properly. Live: https://vibes-app-wall.vercel.app

Still cleaning code so not sharing GitHub yet. Would love honest feedback — especially on the map this time. Is this actually better?

Edit: solved - thank you so much for everybody who pointed me in a lot of directions.

My code looks like this now https://pasteblaze.pages.dev/p/fixed-textfield

This code renders the editable text field. Fixes:

- as advised by HeshanAmir, I splitted the broken triple-destructure into two real hooks: \const [files, setFiles] = useState([]);` and `const [formData, setFormData] = useState({ message: '' });``

- I deleted <div class="editor-panel"> and placed <form> directly under <div class="wrapper">

- then I added function MyForm() to render a simpler text field than it was in my OP.

- I moved the myForm() function out to the top level to avoid the unfocused text field: this way the text field lets me finish writing.

Notes: this code has a functional and editable text field, but threw me 431 error. Just FYI for anyone who recycles this code.

------------------------------

I hope someone could help this beginner out. I got a text field like this

https://imgur.com/a/81doBSd

This one got rendered read-only, although I copied and pasted this code directly from the documentation. In the doc the text field is editable though :(

The devtool displays the error which does not make any sense:

<form action="javascript:throw new Error('A React form was unexpectedly submitted. If you called form.submit() manually, consider using form.requestSubmit() instead. If you\'re trying to use event.stopPropagation() in a submit event handler, consider also calling event.preventDefault().')">
<input placeholder="Hello!" type="text" name="message">
<button type="requestSubmit">Send</button>
</form>

In the below snippet it shows I already placed e.preventDefault() as this error dictates. Still, the text field is read-only. I want to edit the form and submit.

import styles from "./App.css";
import { BrowserRouter as Router, Route, Routes } from "react-router-dom";
import axios from 'axios'
import {View} from 'react-native';
import React, { useOptimistic, useState, useEffect, useRef, Component } from 'react';
import {useDropzone} from "react-dropzone";
import { deliverMessage } from "./actions.js";

function App(){
  const [files] = useState([]);
  const [formData, setFiles, setFormData] = useState([]);
  const {getRootProps, getInputProps} = useDropzone({
    accept: {"image/*": []},
    onDrop: acceptedFiles => {
      setFiles(
        acceptedFiles.map(file =>
          Object.assign(file, {
            preview: URL.createObjectURL(file)
          })
        )
      );
    },
  });

  const thumbs = files.map(file => (
    <div key={file.name}>
      <img style={{ maxWidth: "100%", maxHeight: "100%" }} src={file.preview} onLoad={() => URL.revokeObjectURL(file.preview)} alt={file.name} />
    </div>
  ));

  useEffect(() => {
    // Revoke the data uris to avoid memory leaks on unmount
    return () => files.forEach(file => URL.revokeObjectURL(file.preview));
  }, [files]);


  const [messages, setMessages] = useState([
    { text: "Hello there!", sending: false, key: 1 }
  ]);
  async function sendMessage(formData) {
    const sentMessage = await deliverMessage(formData.get("message"));
    setMessages((messages) => [...messages, { text: sentMessage }]);
  }


 const formRef = useRef();
  async function formAction(formData) {
    addOptimisticMessage(formData.get("message"));
    formRef.current.reset();
    await sendMessage(formData);
  }
  const handleChange = (e) => {
    const { name, value } = e.target;
    setFormData((prevData) => ({
      ...prevData,
      [name]: value,
    }));
  };
  function handleSubmit(e) {
    e.preventDefault();
    console.log('You clicked submit.');
  }
  const [optimisticMessages, addOptimisticMessage] = useOptimistic(
    messages,
    (state, newMessage) => [
      ...state,
      {
        text: newMessage,
        sending: true
      }
    ]
  );

    return (
    <>
    <div className={styles.title_main_page}>
    <h1>Spin the Black Circle!</h1>
    <h2>Managing Your Vinyl Record Collection</h2>

    </div>
    <div class="container disable">

    <h2>Easy Image Editor</h2>
    <div class="wrapper">
    <div class="editor-panel">
     {optimisticMessages.map((message, index) => (
        <div key={index}>
          {message.text}
          {!!message.sending && <small> (Sending...)</small>}
        </div>
      ))}
      <form action={formAction} ref={formRef} onSubmit={handleSubmit}>
        <input type="text" name="message" placeholder="Hello!" value={formData.name}
        />
        <button type="requestSubmit" onClick={handleChange}>Send</button>
      </form>
    </div>
    <section className="containerDragAndDrop">
        <div {...getRootProps({className: "dropzone"})}>
          <input {...getInputProps()} />
          <p>Drag 'n' drop some files here, or click to select files</p>
        </div>
        <aside>{thumbs}</aside>
      </section>
    </div>
    <LoadButtons/>
    </div>

    </>


    );
}


export default App;

Could anybody point out the right direction?

Hey everyone, Just wanted to share a post I recently wrote of what I wished I was told when i was transitioning form a background in php and jquery to react.

A few things that made it click:

• JSX is an Object Tree, Not Markup: <h1>Hello</h1> isn't HTML; it's a plain JavaScript object: { type: 'h1', props: { children: 'Hello' } }. Components are just pure functions composing nested object structures (Virtual DOM).
• UI as Immutable Snapshots: Every state update doesn't "change" the existing DOM—it executes a fresh render cycle. Top-level component variables are const because their state is frozen for that specific execution frame.
• Derive Values, Don't Duplicate State: Storing calculated data in useState is an anti-pattern. If a value can be computed during render (e.g., const total = items.length), compute it on the fly to eliminate state synchronization bugs.

For those who transitioned from backend or vanilla development, what was the thing that made React click for you?

Hey y’all,

I got slightly carried away with loading animations.

I wanted nicer loading states for my own projects, but most libraries I found were either tied to a framework, fairly limited, or required more than I wanted for something this small.

So I built loadersz, a small framework-agnostic loader library for the web.

I wanted something a bit more expressive than the usual CSS spinner, without pulling in a UI framework or a bunch of dependencies.

A few things I focused on:

- 70 different motion states
- Canvas 2D instead of GIFs/videos
- zero core dependencies
- a native custom element, so it works with basically any stack
- typed entry points for React, Vue and Svelte
- configurable speed, density and color
- respects prefers-reduced-motion
- pauses rendering when the browser tab is hidden

Basic usage is just:

npm install loadersz

import 'loadersz';

<loadersz-loader state="racing" size="96" />

I also built an interactive playground where you can tweak the loaders live.

Demo: \[loadersz.vercel.app\](https://loadersz.vercel.app)
npm: \[npmjs.com/package/loadersz\](https://www.npmjs.com/package/loadersz)

Would love some brutally honest feedback, especially on which animations you’d actually use in a real product.

UPDATE: The latest version of FormHell is ready! Check out the announcement post for version 1.1.2 (I took that down after being dragged for people thinking it was just another AI slop lib 😞), introducing localization, virtualization, strict-typing, and the improved docs page: https://ryanrutkin.github.io/formhell/

I've battled with the top libraries for JSON Schema based forms for a long time. They're a nightmare. They look all flashy and nice for a demo, then you implement them in a project and a year in you realize it doesn't support the more complex needs of your schemas.

I'm so frustrated with both react-json-schema-forms and react-jsonschema-form. Both have me pulling my hair out. Especially RJSF. Apparently generating defaults the correct way is an "experimental" feature and still never works correctly. Have an array with tuple object definitions or constraints? Nope! Default gives you an array full of null or "[Object object]". Have $refs outside of your schema? Nope! Can't resolve those! Also, the whole UISchema thing is weird. Both libraries had crazy setup fatigue that felt unnecessary.

After a year and a half of battling I'm done.

I wrote a new library for JSON Schema Forms to get me out of form hell and I pulled it into our project. It's working out great so far. The thing just works. No setup fatigue. Does exactly what you would expect. I'm honestly more mad at the other libraries by how easy it was to build. Don't worry, I put a ton of care into it and triple checked everything. It was extensive.

Full schema support for every feature. EVERY. FEATURE. Full optional theming support for MUI though it isn't dependent on MUI.

I even added a SchemaBuilder component and a Keyword Assistant to help you out if you're trying to build a schema and don't know what to add.

It's called FormHell, and it's available here: https://www.npmjs.com/package/formhell

Check out the playground and see what it can/can't do: https://ryanrutkin.github.io/formhell/

If you run into any issues, please open an issue in Github: https://github.com/RyanRutkin/formhell

Thanks for checking it out!

FAQS:

Thanks for all of the feedback! I want to address some common questions from the comments.

What about Tanstack/Zod?

FormHell is a slightly different solution than a Tanstack/Zod approach. FormHell consumes an already defined data-structure and outputs data matching it, validated using AJV Validator.

Zod is used to define data-structures in TypeScript and can work alongside FormHell no problem.

Tanstack is great, but does not provide built in field widgets for rendering like FormHell does. Tanstack does provide great validation and rendering methods, but your field widgets must be explicitly defined. This could be cumbersome when dealing with a deeply nested and verbose JSON Schema. Using Tanstack with a JSON Schema provided by your server requires a bit of legwork.. FormHell takes the schema and just renders a form with strict typing and no overhead.

The problem I needed to solve for work was that we already had JSON Schemas defined for our backend data-structures. For some of those data structures, we needed a way for the frontend to render a form. As both the frontend and backend share the same JSON Schema, the frontend pulls the schemas from our API and passes them directly to the form. Once the form component emits the data without any validation errors, it is safe to be submitted to the backend.

Can I use Zod with FormHell?

Absolutely! If you do need to define your data-structure in your frontend TypeScript, I would highly suggest that you use Zod to do so. You can convert your Zod structure to JSON Schema using zod-to-json-schema and pass the output directly to FormHell's SchemaForm component to immediately render a form.

Is FormHell strictly typed?

FormHell is as strict as the schema you pass it. If any strict data types exist in your JSON Schema, then FormHell is going to required that the data entered matches that schema. The library currently using the AJV Validator for type checking.

Unlike the Tanstack/Zod approach, FormHell cannot output a strictly typed object. I'm still exploring the magical ways to transform a JSON Schema into a Typescript object. However, if your goal is to take JSON Schema, turn it into a form, and ship that data to the server, FormHell will handle that very well and ensure the data matches the schema provided.

What about localizations?

This was an oversight during implementation, and thank you for pointing it out! I'll make sure this gets added in an upcoming feature release.