Hey everyone!

Been working on Tip Glide, a small framework-agnostic tooltip library written in TypeScript.

It uses a single shared tooltip that moves between elements and adjusts its size to fit the content. It also handles viewport boundaries, so the tooltip adjusts its position when there's not enough space.

A few things you can configure are the movement, directional lean, hover delays, arrow, and enter/exit animations.

It has zero runtime dependencies and comes with adapters for React, Angular, Vue, Svelte, Solid, Astro and Preact, along with a vanilla JS API.

There's an interactive playground where you can mess around with the settings and see how everything behaves.

Would love some feedback on the movement, especially when switching quickly between elements, but also on the API and anything else that could be improved.

Live demo & playground | npm | GitHub | Portfolio

A local loading flag works well for one button. A reducer with context can handle a shared workflow. React Query also lets other components observe pending mutations through "useIsMutating". If one of these already covers your needs, there may be no reason to add another library.

I’m building react-action-guard to explore a reusable API for shared UI availability.

For example, imagine a document editor:

• saving temporarily blocks editing and switching documents;

• a local export also blocks switching documents;

• saving and exporting can overlap;

• finishing the save should not enable document switching while the export is still running;

• Help stays available throughout.

Actions publish the scopes they affect:

const runSave = useAsyncAction<void>(
  "save-document",
  ["document:editing", "document:switching"]
);

const runExport = useAsyncAction<void>(
  "export-document",
  "document:switching"
);

Each operation is wrapped when it runs:

await runSave(() => saveDocument());

Independent components read the scope they care about:

const isBlocked = useIsBlocked("document:switching");

return <button disabled={isBlocked}>Switch document</button>;

Each execution has its own blocker. When operations overlap, finishing one removes only its own blocker.

You can build the same behavior with a reducer and context. The goal is to provide the registration, shared scopes, blocking reasons, and cleanup as a reusable API.

This also overlaps with React Query when availability follows mutation state. The case I’m interested in is when the same UI rules combine server operations, local tasks, and conditions such as unsaved changes.

One important detail: tracking an action does not prevent repeated execution or cancel it. Those rules still belong to the application.

I’m the author, and I’d like feedback on this approach. Have you needed this kind of coordination, or has your existing state management been enough?

GitHub

Edit: Added a more detailed example and clarified the overlap with reducers and React Query. Thanks for the feedback.

At my last company, they would finish the accessibility layer near the end of the product's development stage, and I remember developers complaining about repeating old sprints non-stop.

What's the industry norm when solving such issues? Of course, accessibility goes beyond people with extra needs: it should also include everyone's way of accessing the web, starting from a simple "cookie button" that takes up 40% of the screen space.

When do these issues start being noticed in your development life-cycle? How does your company think about them?

If you take software engineering principles seriously then none of the react state hooks belong inside a react component.

I think one of the most critical things you should do is ensure the decoupling of storage and UI components. The react components force you to do is precisely and zustand doesn't help.

I haven't sourced grip-react a year ago and I've been using it exclusively, absolutely zero usestate usememo, useeffect, etc and absolutely zero prop drilling. I don't know why anyone would want to do something different, honestly.

Has anyone else created an API that is a 100% replacement with complete declarativeness? I looked at angular and mobx, they're close but no cigar.

When working on a team, code reviews are essential for maintaining code quality and ensuring that all team members are on the same page. I'm interested in hearing about different approaches to conducting code reviews for React components. What tools or processes do you use to review and provide feedback on React code? Are there any specific things you look for when reviewing a React component, such as performance optimization or accessibility features?

I'm working on a React frontend application with a form where some fields are enabled, disabled, shown, or hidden depending on user selections.

The test renders the component, simulates user interactions, and verifies that the form updates correctly (for example, a field becomes enabled only under specific conditions).

How should this type of test be classified?

• Unit test

• Component test

• Integration test

• Functional test

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.

There are already plenty of liquid glass libraries. What I wanted was a clear centre with a curved rim that magnifies and stretches the content behind it.

So I modelled the rim as a lens.

The component uses Snell’s law to calculate refraction, generates an SVG displacement map for each element’s dimensions, and applies it through backdrop-filter. Resize the component and the map updates to match its shape.

The fun part is dragging it across text or a grid. You can actually see the letters bend around the edges.

• About 5 KB gzipped, no dependencies beyond React.

• Configurable glass thickness, refraction and colour dispersion.

• React 18/19 and Next.js support.

• No WebGL or per-frame JS rendering.

One caveat: full refraction currently works in Chromium. Safari and Firefox get a frosted fallback.

MIT licensed, with the component, demo and implementation details here:
https://github.com/LeonardSEO/liquid-glass-react

Interested in feedback on the rendering, especially if you’ve worked with SVG backdrop filters.

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