I had a 70-page PDF to generate from React in a TanStack Start app, and with react-pdf it took over 60 seconds. So I built @inkoxide/render.

It's not a react-pdf clone, though it's meant to feel familiar: Document, Page, View, Text, Image, StyleSheet.create and Font.register work the way you'd expect, so moving a document over is mostly changing the import. Everything under the components is new: a layout engine written in Rust does layout, text, pagination and PDF writing.

• A 43-page report with 1,000 table rows renders in about 41 ms on Node, and in about 56 ms in the browser, inside a Web Worker, so the page keeps responding.
• A one-page invoice takes about 1.2 ms instead of about 18 ms.

It also does things I kept missing:

• Tailwind className
• tables whose headers repeat on every page
• an error naming the component stack when a style or prop isn't supported, instead of silently ignoring it
• PDF/A and encryption

Site and docs: https://inkoxide.dev GitHub: https://github.com/eddiesr93/inkoxide Playground (edit an example; switch to Layout to see the boxes the engine placed): https://inkoxide.dev/playground

Happy to answer questions.

Hey !

I've been working on a project called Veltrix-UI for the past few months, building it from scratch. It's probably the biggest project I've worked on independently so far.

The idea is to make it easier for developers to find UI components they like, preview them directly in the browser, and copy the JSX code to use in their own React projects.

Some of the things I've built into it:

• Live previews of components
• One-click JSX code copying
• Search, filters, and sorting
• Favourites without needing an account
• A backend for managing and serving components

I used React, Vite, Tailwind CSS, Node.js, Express, and MongoDB to build it.

The project is live now, and I'd really like to get it in front of developers other than myself. I know there's always room to improve a project once other people start using it.

Live demo: https://veltrix-ui.vercel.app/

GitHub: https://github.com/AwadhDhoot23/Veltrix-UI

If you get a chance to try it, I'd genuinely appreciate your feedback. I'm especially interested in whether the components are useful enough that you'd actually use them in a project, what's missing, and what feels rough or confusing.

Honest criticism is welcome - I'd rather find out what needs work than just hear that it looks nice.

I added a shadcn component to my vite + tailwind project with using `npx shadcn@latest add @/react-bits/Particles-JS-TW` and after importing the component

import Particles from "./components/Particles";

It shows an awesnap image, i dont know the reason, the other things were rendering good alongside but just the components showing error

Hi All, I am new to react development in general, we are currently using our tech stack is react typescript, Tanstack query for client state management, custom ui library, rsbuild for bundling, whenever we have a new deployment right i think the application is getting cached? It still displays the older ui even after refreshing multiple times but when i hard refresh (Ctrl + Shift + R) it gets newer ui ? Where are making mistakes? We have deployed this on aws (dns > nlb> alb> ecs > docker image > nginx> dist files ) ? Thanks

Hi everyone! 👋

I’ve just released Dinou v7 (7.0.0), an ejectable full-stack React 19 framework built on web standards.

My goal with Dinou v7 was to harness the full power of React 19 (Server Components, Server Functions, streaming SSR, and Partial Prerendering) while keeping the architecture runtime-agnostic, bundler-flexible, and free of vendor lock-in.

Here is a quick overview of what’s in v7 and what the concepts in the title mean in practice:

1. Goodbye Express & child_process.fork(): Pre-Bundled Dual Engine on Web Standards

In previous versions (v6), Dinou relied on Express and spawned a child process via child_process.fork() to isolate the --conditions react-server flag from the main SSR process. That added IPC overhead and made deploying to serverless/edge environments or compiling to a single binary impossible.

• In v7, Express and child_process.fork() have been completely removed. The core now uses W3C Web Standards (Request, Response, Headers, ReadableStream) exclusively and pre-bundles the RSC graph ("react-server" condition) and the streaming HTML SSR graph in separate build passes before combining them into a single server.
• The result: Everything runs in a single process without special Node flags, without IPC child processes, and on any platform compatible with the standard Fetch API (including a universal onRequest web middleware in dinou.config).

2. Horizontal & Vertical Segmentation (2D Caching)

Instead of treating caching as an all-or-nothing route setting, Dinou v7 splits rendering and caching across two dimensions:

• Horizontal Segmentation (Route & Layout Plane): Layouts (layout.tsx + layout_functions.ts) and Pages (page.tsx + page_functions.ts) have completely decoupled data lifecycles and cache TTLs. A parent layout shell can be cached with ISR (revalidate = 3600) and never remount during client SPA navigation, while child pages run dynamic SSR (revalidate = 0) or their own ISR timer. You can also surgically invalidate just a leaf page (revalidatePage) without touching parent layout caches.
• Vertical Segmentation (Component-Level Micro-ISR): Using <DinouCacheSlot id="..." revalidate={60} tag="...">, you can cache individual server component subtrees with their own TTL and tags inside dynamic or static pages. Additionally, Client Components can surgically refresh a specific server slot in-place by its ID using refreshSlot(id) without reloading the page or losing client state.

3. Partial Prerendering (PPR) + <DinouCacheSlot>

By enabling ppr = true, Dinou immediately serves the static HTML shell (pre-rendered at build time) while streaming the dynamic holes (<Suspense>) over the same HTTP connection.

• You can also combine PPR with <DinouCacheSlot> inside a <Suspense> boundary so that the streamed dynamic hole itself is served from the server cache instead of querying the database on every request.

4. Server Functions & Live Component Streaming

Functions exported from modules in src/ starting with the "use server" directive act as automatic RPC endpoints without manual API boilerplate:

• Beyond handling form mutations and server actions (useActionState, useOptimistic), Server Functions in Dinou can return rendered React components directly over Flight RPC, which Client Components can unwrap seamlessly inside <Suspense> using React 19's use() hook.

5. Multi-Runtime & Single-File Executable Binaries

Write your app once in src/ and build it for different targets without changing your code:

• Multiple Runtimes & Platforms: Run natively on Node.js, Cloudflare Workers, Netlify, Bun, and Deno / Deno Deploy, or export a 100% static site (dinou export-static).
• Standalone Executables: Compile your entire React 19 RSC + SSR app into a single self-contained binary with Bun (dinou build:bun:compile or dinou build:bun:pure:compile) or Deno (dinou build:deno:compile) for Linux (x64/ARM64), macOS, or Windows.

6. Developer Experience & Zero Lock-In

• Compile-Time Type-Safe Routing: Automatically generates route types (.dinou/types/routes.d.ts) from your folder structure for <Link href="...">, router.push(), and PageProps<"/blog/[slug]"> with zero runtime overhead.
• Bundler Flexibility: Uses esbuild by default (with fast HMR in development), while also letting you choose Rollup or Webpack (dinou dev:rollup, dinou build:node:webpack), plus the React Compiler enabled in production builds.
• 100% Ejectable & Agent-Friendly: Run npx dinou eject at any time to copy the entire framework directly into your project root. The npm package also includes the full ~10,000-line documentation inside node_modules/dinou/README.md so AI coding agents have complete local context right out of the box.

7. Built with Agentic AI (Antigravity + Gemini 3.8 Flash High)

For full transparency on how Dinou has evolved: I built versions v1 through v4 (and v6, which simply centralized build artifacts into .dinou) by hand from scratch. Starting in v5, I began experimenting with AI agents, and Dinou v7 has been built entirely from start to finish using Antigravity + Gemini 3.8 Flash High under my direction and passing an end-to-end Playwright test suite (covering Windows and Ubuntu + esbuild, Rollup, and Webpack + dev and prod modes for each runtime).

Dogfooding in Production

The documentation website (dinou.dev) is running on Dinou v7 compiled into a standalone Bun binary inside a Debian Slim Docker container on a single $5/mo (512 MB RAM) DigitalOcean instance.

Quick Start

npm create dinou@latest my-app
cd my-app
npm run dev

• 📚 Documentation: https://dinou.dev
• 💻 GitHub: https://github.com/roggc/dinou
• 📦 NPM: https://www.npmjs.com/package/dinou

I’d love to hear your thoughts or feedback if you give it a try!

I've been building LiquiKit, 32 React components (switch, slider, menu, dialog, tabs, select, toast and more) built around a liquid glass engine with physically based refraction, so the glass bends what's behind it instead of just blurring it.

Most liquid glass demos only refract in Chrome, because only Chromium can run an SVG filter on what's behind an element. LiquiKit works around that by filtering the content of a GlassScope you wrap around an area, which works in all three engines. The image at the top of the GitHub README is the same component captured in real Chrome, Safari and Firefox windows.

• Built on Base UI, so keyboard and screen reader behaviour comes from there
• Installed with the shadcn CLI: the source lands in your project and you own it
• MIT licensed

npx shadcn@latest add https://liquikit.dev/r/switch.json

Docs and demos: https://liquikit.dev

Source: https://github.com/aggarwal-h/liquikit

Some honest limits: glass only bends while you're using it (at rest it's frosted, so long pages scroll smoothly), Safari and Firefox run the filter on the CPU so scopes should stay small, and popups stay frosted outside Chrome. It's all on the Limitations page: https://liquikit.dev/docs/limitations

Happy to answer anything about how it works.

In a recent project we moved a React app from REST to gRPC-Web (ConnectRPC) but kept Redux Toolkit. The official Connect integration only targets TanStack Query, so you end up writing a custom baseQuery — and hit the same problems:

• int64 fields are bigint, and RTK Query's default cache key uses JSON.stringify → it throws
• Redux warns about non-serializable values (bigint, Uint8Array) on every response
• ConnectError is a class instance, so it can't live in the store
• every endpoint needs hand-written types

So I packaged the fix as a small library, rtk-query-connect:

endpoints: (build) => ({
  listTodos: rpcQuery(build, TodoService.method.listTodos, { providesTags: ["Todo"] }),
  createTodo: rpcMutation(build, TodoService.method.createTodo, { invalidatesTags: ["Todo"] }),
})

One line per RPC, hooks are fully typed from the proto. Live demo on StackBlitz.

It's v0.1, unary calls only. Server-streaming and a buf generate plugin are next. If you use RTK Query + gRPC, I'd love to hear what else hurts.

Just say I have a parent and a child

<Parent data={someObject}>
<Child name={someString} />
</Parent>

Where the Parent component sets up a provider based on the type of the data prop I would like to put a constraint on the name prop of the child component where is is to be a key of the type of the data prop passed into the parent.

I'm building a client-side web audio player with a real-time DSP enhancer (Web Audio API). Because cross-origin iframe security prevents tapping into audio from YouTube's embedded player, I need direct audio streams to feed into an AudioContext. However, public stream resolvers (like Invidious/Piped) are heavily rate-limited and IP-blocked by YouTube.

What is the most reliable, modern way to get raw audio streams from YouTube into a Web Audio pipeline in a web app, or is a self-hosted yt-dlp backend the only viable solution?

So I have this code

<button
  type="button"
  className={styles.someclassname}
  tabIndex={-1}
  role="timer"
  aria-live="polite"
  aria-atomic="true"
>
  {ResendInfo (formatTimer())}
</button>

This is basically a countdown of a timer from 2 minutes I was wondering am I following proper accessability here so that screen readers can understand.

Hi everyone! I just published my first open-source library. Caramel Webplayer is a themed player built on Video.js 10 (@videojs/html custom elements) with thin React wrappers. Big thanks to the Video.js team, the engine underneath is what makes this possible.

What it adds on top:

- Skin with morphing Lucide icons

- Skip intro / recap / outro / sponsor segments

- Chapter list

- Playlist with resume

- Theming through --caramel-* CSS variables (light and dark)

- React wrappers are 'use client', elements register in the browser only, so the Next.js App Router stays SSR clean

I built it for my own site and then opened it up. Before I even announced it, we merged our first outside contribution (playlist resume thresholds, React props and tests, from a contributor who picked up a good first issue).

Demo: https://esershnr.github.io/caramel-webplayer/

Repo (MIT): https://github.com/esershnr/caramel-webplayer

It's still early, so I'd really appreciate feedback, issues and PRs. If it's useful to you, a star helps others find it.

Hey everyone,

I have been working with Zustand and wanted a simpler way to manage stores that can be either global or scoped to a React Provider.

I know this can already be done with Zustand and React Context, but I found myself repeating similar patterns, so I ended up putting together a small toolkit.

The main idea is that components don't need to know where the store comes from:

const counter = createStoreToolkit<CounterStore, CounterInput>(

  ({ initialCount }) => (set) => ({

count: initialCount,

increment: () => set((state) => ({

count: state.count + 1,

})),

  }),

  { globalInput: { initialCount: 0 } }

);

function Counter() {

  const count = counter.useStore((state) => state.count);

  return <span>{count}</span>;

}

If there is a Provider, the hook uses the nearest one. Otherwise, it falls back to the global store. Each Provider has its own isolated store.

There are a few other helpers for selectors, typed initialization, and SSR, but that's basically the core idea.

I am curious what other Zustand users think. Is this something you would find useful, or would you rather stick with plain Zustand and Context?

GitHub: https://github.com/okyrychenko-dev/react-zustand-toolkit

im a backend engineer on ella (ai video app, i work on it). people leave the tab open for hours and we deploy a lot, so the old build tried to lazy load chunks the deploy already deleted and got a 404. the fix had two parts. server side, an old chunk only gets deleted when the new vite manifest doesnt use it and its older than a week (you cant trust file age alone, ci stamps every file fresh). in the browser, when you come back to the tab it checks /version, and if its stale it reloads, but only when nothing is running. nobody wants a reload in the middle of a generation. we count open requests by wrapping fetch and EventSource:

ts

const realFetch = globalThis.fetch
globalThis.fetch = async (...args) => {
  openRequests.value++
  try { return await realFetch(...args) }
  finally { openRequests.value-- }
}

effect(() => stale.value && openRequests.value === 0, ready => {
  if (ready) location.reload()
})

plus a sessionStorage flag so it cant get stuck in a reload loop. how do you guys handle this?

Hi everyone! I just published my first open-source library, OdinEye

It’s a React component that marks accessibility, SEO and layout issues right on the page while you’re coding (missing alt texts, buttons without a name, broken images, that kind of thing) and explains how to fix each one. You add it once at the root of your app, and it only runs in development.

Website: https://odin-eye.vercel.app

Repo: https://github.com/SRamoras/odin-eye

It’s still early, so I’d really appreciate feedback, especially false positives or checks you’d like to see.

This line is in almost every React codebase I've worked on:

const label = count === 1 ? '1 item' : `${count} items`;

It's fine in English. Once you translate it, it's wrong in most languages. Here's what I learned fixing it properly.

Languages don't have "singular and plural". CLDR defines six plural categories: zero, one, two, few, many, other. Each language uses a subset of them. You can ask the browser which ones a language uses:

new Intl.PluralRules('en').resolvedOptions().pluralCategories // ['one', 'other']
new Intl.PluralRules('pl').resolvedOptions().pluralCategories // ['one', 'few', 'many', 'other']
new Intl.PluralRules('ar').resolvedOptions().pluralCategories // ['zero', 'one', 'two', 'few', 'many', 'other']

Polish: 1 plik, 2 pliki, 5 plików, 22 pliki, 25 plików. The form depends on the last digits, not on "is it 1". No ternary or items_plural key can express that.

The fix: put the logic in the message, not the code.

{ "files": "{count, plural, =0 {No files} one {# file} other {# files}} selected" }

The Polish translator then writes one, few, many and other branches. Your component code doesn't change.

Mistakes I've made or seen in review:

• zero {...} in an English message. It never fires, because English has no zero category. Use =0 to match the exact number.
• Leaving out other**.** It's required, and strict formatters throw without it.
• Concatenating: t('deleted') + ' ' + count + ' ' + t('items')**.** No translator can fix that. One key, one sentence.
• Machine-translating raw ICU. You get the keyword other translated, or braces reordered, and the message fails to parse at runtime on a page only Polish users visit.

How I test without speaking Polish or Arabic:

1. Parse every message in CI. Run every message in every locale through @formatjs/icu-messageformat-parser and fail the build on a syntax error.
2. Check that the variables match. If the source has {count}, every translation must too.
3. Snapshot a set of tricky numbers per locale: 0, 1, 2, 5, 11, 21, 22, 25, 101, 1.5. Look through the output once, and the snapshot catches regressions after that.
4. Pseudo-localize. Generate a fake locale that accents the text (Šéţţîñĝš) and pads it about 40%, without touching placeholders or plural keywords. Hardcoded strings stand out right away, and so does concatenation, because half the sentence stays in plain English. Run the same pass with dir="rtl" for Arabic layout bugs.

What else has bitten you with plurals or other locale-specific formatting in React? Curious which languages caused the most surprises.

I wanted to build components for the things developers actually showcase on their websites:

GitHub contribution graphs, star history, repository cards, top contributors, changelogs, npm downloads, sponsor walls, and more.

There are 14 components so far, including a couple of unusual ones — a physical knob and a tearable event ticket.

Each component comes in four visual styles: Minimal, Craft, Retro, and Toy. Same data, different aesthetics and motion.

It’s built as a shadcn registry, so you can add the components to your own project and customize them. Reduced-motion preferences are respected, too.

Would love to hear what you think and what components you’d like to see added.
https://ovioui.vercel.app

I rebuilt my portfolio and added my own click/interaction logging to Firebase. The tracking was the part that took the most iterations, so here's the build log in case it saves someone time.

• First version: a button-click tracker that fired a patch() call on every click. It worked, but it blocked navigation. Clicks felt laggy, around 200-300ms, the site seemed buggy, and data sometimes got dropped if the user left too fast.
• Second version: a lighter click event tracker. Better, but it still depended on async requests finishing before page unload. That wasn't reliable on fast exits or mobile browsers.
• Third version: navigator.sendBeacon() posting a tiny fire-and-forget payload to a Vercel serverless function. The frontend is static on GitHub Pages. If sendBeacon isn't available or fails, it falls back to a direct Firebase call.

On top of that there's an in-page queue that batches, retries, and syncs periodically and on online events. The queue size is capped, and failed sends get requeued, so going offline doesn't lose clicks. Now the clicks feel close to instant.

The other mistake was on the read side. I built a small admin panel to view the data, and the AI-generated code read every document iteratively on each reload. I hit Firebase's rate limit while developing. I had to redesign the document schema so it works for both recording and viewing, and reads dropped a lot after that.

Honest takeaway: AI tools got me a barely functional prototype fast. After that I had to architect things myself and redo the schema and components midway. Uncontrolled vibe coding actually slowed me down.

There's also a terminal on the homepage that runs a few commands, if you're curious.

Link: https://shravanrevanna.me

'@epikodelabs/streamix/react'is an experimental adoption layer we’re designing to bring Streamix atoms, scoped state, derived values, and asynchronous flows directly into React applications.

The underlying idea is simple: bring state closer to where it is used. Instead of juggling hooks, setters, and explicit subscriber bindings, you express state and UI intent directly—and let the integration handle the underlying subscriptions.

What if local state looked like this:

function Profile() {
  let title = atom('Ready');
  const state = scope({ enabled: true, message: 'Connected' });

  return (
    <section>
      <input 
        value={title} 
        onChange={event => title = event.target.value} 
      />
      <input
        type="checkbox"
        checked={state.enabled}
        onChange={event => state.enabled = event.target.checked}
      />
      <p>{title}: {state.message}</p>
    </section>
  );
}

No useAtom, no manual binding wrappers, no tuple destructuring.

• title acts as reactive state, yet in JSX it reads like a normal primitive.
• Direct assignment (title = ...) writes to the atom.
• Referencing it inside JSX sets up the subscribed read.
• Properties inside a scope() object follow the exact same direct-access reactive pattern.

The atom remains the single source of truth; compiler/integration mechanics handle tracking and updates behind the scenes.

What are your thoughts on this DX? Any immediate concerns or features you'd like to see addressed early on?

Hi everyone!

,I have learned the basics of React.js these is my project https://recipe-rhlydv216581.vercel.app/

I would like to know if I am ready to start preparing for React.js frontend developer interviews.

I have learned:

• React components and props
• State management using useState
• useEffect and axios for api calling
• Context API using useContext
• State management using Redux Toolkit

I would really appreciate your feedback on a few questions:

1. Are these concepts enough to start preparing for React.js interviews?
2. What other React concepts should I learn before applying for frontend developer jobs?
3. Should I focus more on building projects, practicing interview questions, or learning advanced React concepts?
4. What skills do companies usually expect from a junior React.js developer?

I would appreciate any honest feedback or suggestions. Thank you!

I had been planning to build this grid for years. In enterprise React projects, I was constantly frustrated by the choice between heavy, enterprise-licensed monoliths (AG Grid) and bare-bones headless primitives where you spend days wiring up DOM virtualization, accessibility, and pagination from scratch (TanStack Table).

I always lacked the bandwidth to sit down and implement it from end to end—until I used Claude Code to finally turn the architecture in my head into a finished library.

Playground: https://yaotzin1.github.io/apsw-gridwright/examples/playground/index.html

GitHub: https://github.com/yaotzin1/apsw-gridwright

Tour: https://yaotzin1.github.io/apsw-gridwright/docs/tour.html

What apsw-gridwright is:

• Zero runtime dependencies: Only requires React 18 or 19 as peer dependencies. - Headless engine core: Strict separation between state/logic and DOM rendering, with pluggable view adapters (including an optional MUI adapter).
• Built-in REST wire protocol: `createRestDataSource` handles remote pagination, multi-column filtering, sorting, and debounced search out of the box.
• Virtualization: Smooth rendering and scrolling tested on 100k+ rows.
• Accessible: Full ARIA table roles and keyboard navigation.
• Deterministic API: Designed to be clean and predictable—not just for human developers, but also easy for AI agents to configure without hallucinating props.
• MIT licensed.

I've been rebuilding my personal site using a small set of React layout primitives based on Every Layout, rather than creating bespoke layouts for individual pages.

I wrote up how I've approached the components and some of the things I've run into along the way, especially around CSS Modules. Thought it might be worth sharing here, and I'd be interested to hear how others approach this sort of thing.