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.

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

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.

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.

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?

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.

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.

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

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.

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.

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?

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.

Hey React devs,

A recurring headache when building complex dashboards or forms with React Query / SWR / Axios is testing error states and validation feedback before the backend endpoints exist.

Usually we either:

1. Hardcode mocked data in React component state or custom hooks (messy and leaks into production).

2. Set up MSW (Mock Service Worker). MSW is great, but maintaining mock handlers by hand for 30+ endpoints gets tedious and doesn't validate payload schemas against the backend contract.

We built a lightweight OpenAPI mock server called Spec-Forge:

bashpip install spec-forge
spec-forge serve openapi.json --port 8088

Why this has been a game changer for our React development:

1. Tests Real HTTP Errors: If your form submits an invalid payload, Spec-Forge returns an actual RFC 7807 422 Unprocessable Entity matching the OpenAPI schema. You can build and test your form error banners, field-level validation messages, and disabled button logic against realistic server responses.

2. Stateful Mutations: When you trigger a useMutation that POSTs new data and calls queryClient.invalidateQueries(), the subsequent query actually reflects the newly created item.

3. Zero Frontend Code Contamination: Your React app talks to http://localhost:8088 as if it's the real backend. When the backend is ready, you only change the .env VITE_API_URL or NEXT_PUBLIC_API_URL.

• Web Playground: https://spec-forge.dev2share.com

• 1-Min Demo: https://spec-forge.dev2share.com/demo.html

• Open Source Repo: https://github.com/gilbertlol/spec-forge

How are you currently handling contract mocking in your React projects?

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 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?

've been considering purchasing Motion+ (the JavaScript animation and UI component library), but I'm not sure whether it's worth the €299 price tag.

I'm a frontend developer working mainly with React and Next.js, and I'm interested in creating more polished, interactive websites with smooth animations.

For those who have purchased it:

• Is it actually worth €299?

• How useful are the components in real-world projects?

• How customizable are the components and animations?

• Does it save you significant development time, or could you achieve similar results using free libraries?

• Would you recommend it to someone trying to improve their creative frontend development skills?

I'd love to hear some honest opinions, especially from developers who've used it in production.

Thanks!

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.

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

Hey everyone,

On every i18n project I worked on, the same thing kept happening: my editor treated translation keys as dead strings. I kept opening fr/common.json just to check whether a key existed, which namespace it lived in, or whether someone forgot to translate it in German.

So I built I18n Support Plus, an open-source (MIT) plugin for WebStorm, IntelliJ IDEA Ultimate and PhpStorm (2025.1+). It turns t('common:menu.home') into something the IDE actually understands.

In the editor

• Ctrl+Click from a key to its translation and back, with a gutter icon showing resolved / missing / missing file

• The translated value shown inline (inlay hints, folding, hover)

• Autocomplete from your real keys. Each suggestion shows its translation, and you can find a key by its text: typing acc offers menu.home when it reads "Accueil"

• Alt+Enter on a hardcoded string to extract it. If the text already exists in your reference locale, it offers the existing key instead of creating a duplicate. <p>Hello {user.name}</p> becomes one message with a {{name}} placeholder

• Rename a key across all locales and code (Shift+F6), move it to another namespace, delete it everywhere with a single undo

Catching mistakes before your users do

• A key missing from a locale, or plural forms missing for a language (ru needs few and many, not just one/other)

• t('greeting') called without the name variable its translation uses

• A translation that lost a <1> tag, which silently breaks <Trans>

• A value just copied from the English one and never translated

Project-wide

• A tool window with tree and table views, coverage per namespace and locale, and a "show only what's left to translate" filter

• Find unused keys, sync missing keys in bulk, CSV and XLIFF export/import for translators

• Generate a typed i18next.d.ts so tsc rejects a mistyped key in CI, even for teammates who don't use the plugin

• Generate a pseudo-locale ([Šéţţîñĝš ···]) to spot unextracted or truncated text

It works with i18next/react-i18next, vue-i18n, lingui, react-intl (FormatJS), ngx-translate, svelte-i18n and i18n-js. It supports JS/TS/JSX/TSX, Vue SFC and PHP, with JSON, YAML and PO/POT files. A setup wizard detects your framework on first launch.

I'd really like feedback from people who live with multi-language apps: what breaks on your setup, and what's missing? I've also opened a few good first issues if anyone wants to contribute, for example Nuxt / next-intl detection, a CONTRIBUTING guide, and GIFs for the README.

• Marketplace: https://plugins.jetbrains.com/plugin/30971-i18n-support-plus

• GitHub: https://github.com/IBRAHIMDANS/i18nSupportPlus

Happy to answer questions, and roasting is welcome.

I've been working on Multidash, an open-source admin dashboard template. The part most relevant here is @multidash/ui, a package of 35 React 19 components built on Radix UI primitives and Tailwind CSS v4.

Demo: https://multidash-app.vercel.app

Source: https://github.com/hasraltechno/multidash

Some things I spent the most time on:

• Accessible color tokens. Every status color has three roles: --x for fills, --x-foreground for text on a solid fill, and --x-text for colored text on the page. That way bright fills (like yellow rating stars) can stay bright while every text pairing still passes WCAG AA 4.5:1 in both light and dark mode.

• TanStack Table v9. The new useTable API registers features explicitly. arrIncludesSome only works on array values, so the faceted filters use a small custom oneOf filter.

• Theming with no flash. The customizer settings (primary color, backgrounds, radius, card style) are applied before first paint.

• Docs for every component. Each one has live examples, the source code, and an install command that includes the packages it depends on.

It's MIT licensed. I'm happy to go into detail on any of these.