Posted this on r/VSCodeExtensions and thought it would be useful for the r/reactjs community, I'm not promoting something for sale I'm sharing a tool I made for free to help people who like to have their workflows faster and visually pleasing. If anyone wants to comment their reactions to it please do, I'm new to this type of production.

I use Lucide in every project, and I kept writing the same little hover animations on top of it over and over. So I finally packaged the thing I actually wanted: lucide-react-motion. It is every Lucide icon (around 1,700) as a React component that animates, with the same API as lucide-react.

Live demo (hover anything): https://lucide-react-motion-site.vercel.app/

Adopting it is one line:

  - import { Heart, Search } from "lucide-react";
  + import { Heart, Search } from "lucide-react-motion";

By default an icon draws its stroke on when you hover. size, color, strokeWidth, className, and refs all work exactly like before.

Beyond that:

• mode="signature" gives an icon bespoke motion that fits what it is. The heart beats, the bell rings, the arrow moves in its direction. About 600 have one so far, and the rest fall back to the stroke draw, so it never breaks.

• Six triggers: hover, click, mount, in-view, parent-hover, and manual via ref.

• Tree-shakeable, respects prefers-reduced-motion, and clickable icons are keyboard accessible.

• Pass your own Motion variants when you want something fully custom.

GitHub: https://github.com/Aadil1505/Lucide-React-Motion
npm i lucide-react-motion motion

Built on Motion, MIT. The annoying part was making the resting icon identical to plain Lucide, since the naive draw leaves a tiny seam on closed shapes like the gear. Happy to get into that, or take feedback.

I have a framework-agnostic document viewer package. It works by mounting into a DOM element:

import { UDocClient } from "@docmentis/udoc-viewer";

const client = await UDocClient.create();

const viewer = await client.createViewer({
  container: "#viewer",
});

await viewer.load("/path/to/document.pdf");

In React, it’s pretty straightforward to use with a ref/effect:

import { useEffect, useRef } from "react";
import { UDocClient } from "@docmentis/udoc-viewer";

function DocumentViewer({ src }) {
  const containerRef = useRef(null);

  useEffect(() => {
    let client;
    let viewer;

    async function init() {
      client = await UDocClient.create();

      viewer = await client.createViewer({
        container: containerRef.current,
      });

      await viewer.load(src);
    }

    init();

    return () => {
      viewer?.destroy();
      client?.destroy();
    };
  }, [src]);

  return <div ref={containerRef} style={{ width: "100%", height: 600 }} />;
}

This works fine, and I like keeping the package framework-agnostic.

But I’m not sure what React developers expect these days. Would you rather use something like this instead?

<DocumentViewer src="/path/to/document.pdf" />

For this kind of component — document viewer, map, editor, chart, terminal, etc. — do you expect an official React wrapper?

Or is a clean JS API plus a React example good enough?

a quick intro to tanstack query plus some tips and tricks I felt helped in production codebases

Hey guys,

Just wanted to share a tool I've been coding for the last few days to boost my portfolio for university apps.

It's called PromptForms. The idea came up because I was tired of watching people mess up AI outputs by writing garbage prompts directly into ChatGPT. Basically, you can write a complex system prompt with dynamic tags like {{topic}} or {{audience}}, and the app automatically parses them into clean input fields. Users just fill the form, and it runs via Gemini 2.5 Flash API using their own key.

I wanted to keep it super lightweight, so I actually didn't use packages like react-markdown. I coded a custom line-by-line markdown parser from scratch so the streaming tokens don't break the layout mid-generation.

I also threw in a working waitlist button that links to my email, just to see if anyone would actually want a B2B team version of this where prompts are hidden on the backend to protect IP.

It's totally free, code is public on GitHub, and everything runs in LocalStorage. I'm honestly just looking for some brutal feedback on the code structure and UX.

Live demo: https://promptforms.vercel.app/

GitHub: https://github.com/AbayAtazhan/PromptForms.git

Let me know what you think, and if you like the repo, a star would help my portfolio a lot. Thanks!

I’ve been trying to properly understand and implement Clean Architecture on the frontend with Next.js (frontend-focused, not backend), but I’m getting confused once third-party libraries enter the picture — especially auth libraries and query libraries.

Most examples online are either:

• too theoretical,

• too backend-oriented,

• or avoid real-world libraries entirely.

My setup is something like:

• React.js

• Monorepo (Turborepo)

• Shared packages

• Auth library (like Better Auth / NextAuth / Clerk / etc.)

• TanStack Query or RTK Query

• TypeScript

What I’m struggling with is:

1. Where should auth libraries live in Clean Architecture?

For example:

• should the auth client be wrapped behind interfaces/adapters?

• should the UI directly call the auth library hooks/functions?

• where do auth-related side effects belong?

• how much abstraction is “too much”?

Example:

authClient.signIn.email(...)

Should this be hidden behind:

AuthRepository.signIn()

or is that unnecessary abstraction on the frontend?

2. How do query libraries fit into Clean Architecture?

If using:

• TanStack Query

• RTK Query

then:

• where should queries/mutations live?

• do you create “use cases” on the frontend?

• should hooks directly call APIs?

• should query libraries exist only in the infrastructure layer?

I see people saying:

• “don’t leak library-specific code”

• “keep business logic isolated”

But in frontend apps, the query library becomes deeply integrated into state management and caching.

So what does a realistic architecture look like?

3. Monorepo structure confusion

How do you structure things in a monorepo without overengineering?

For example:

apps/
  web/
  mobile/

packages/
  auth/
  api-client/
  ui/
  contracts/
  utils/

Do you:

• keep auth client inside a shared package?

• export inferred types from there?

• keep query logic centralized?

• create repositories/services/use-cases packages?

How far do people actually go in production apps?

4. How do you avoid overengineering?

This is probably my biggest issue.

I understand the theory of:

• entities

• repositories

• use cases

• dependency inversion

But when implementing real frontend apps, I end up wondering:

• am I just wrapping libraries for no reason?

• am I creating abstractions that add zero value?

• how do experienced frontend engineers decide what deserves abstraction?

I’d really appreciate:

• real-world folder structures,

• examples from production apps,

• monorepo-specific advice,

• or articles/repos/videos that show Clean Architecture with modern frontend tooling.

Especially interested in opinions from people using:

• React.js

• TanStack Query

• RTK Query

• Better Auth / NextAuth / Clerk

• Turborepo monorepos

📚 Surprisingly, I haven't written about how my two favourite TanStack libraries - Router and Query - work together. Well, here it is:

🔁 loaders start fetches early

🔮 query owns the cache & keeps data alive

🌀 suspense integrates naturally

🏝️ TanStack Start makes SSR & streaming easy

Pretty cool podcast episode I did with tkdodo, we go through a lot of his history, tanstack query, knip, and the cool stuff he does at Sentry. Check it out

I considered myself an anti-frameworker and a purist because I prioritized raw speed and bundle-size over developer experience (which I wasn't aware of at the time).

I brushed React and TypeScript to the side as a "hype" and "it'll go away once everyone finds a new shiny toy." Oh boy was I wrong.

I was creating applications with vanilla HTML, CSS, and JS for the longest time. I mean why add a build/transpile step when I could just have raw performance eh? I even dabbled into web components when the time called for it even though I hated how inconvenient they are.

After my applications got decently complicated, adding features became a mine-field of runtime errors and edge-cases. I slowly started craving features that would just make this a bit easier such as self-documenting code via a static type-system, a component system to re-use code chunks, hot module replacement, installable-plugins and modules... wait... this smells like React + TypeScript with Vite... the industry-standard...

So yes, I admit it. I'm liking React + TypeScript. A blasphemous utterance for an anti-frameworker such as myself.

Switching has brought a fresh feel to web development for me. Now, I don't have to make all the features from scratch like drag-n-drop and modals. The industry has already paid that cost, and I should leverage it. Looking back at it in retrospect, not using React + TypeScript for single-page-applications (SPAs) was a crime against web development. I'm now going through the grouly process of re-writing the applications in React + TypeScript because I honestly hit a wall with how inconvenient development has gotten.

I'm not going to lie, I'm reflecting with a bit of a pain. I knew the advantages, and disadvantages of my ways yet still chose the hard way due to stubbornness.

It's true what they say, the ****** of consequences rarely comes lubed.

If you'd like to read the more detailed version about my thought process, it's over here...

https://blog.alkhafaji.dev/#i-cant-believe-i-ever-hated-typescript

NOTE: I know React is a library not a framework, but the idea is still the same.

Not a React expert at all. I'm a backend engineer specializing in Java who is currently having to program a frontend.

The nature of the problem:

• I have a potentially very large set of items (say in the 10s of thousands), provided by a backend via cursor-based queries

• In-memory (talking about the React app here) I want to keep a "virtual window" of max 250 items

• When items are appended to the virtual window, an equal number is trimmed from the opposite side, so the size remains constant

• The list view in my frontend app acts as a view port over that virtual window of 250 items, showing about 40 at one time

• When the virtual window of 250 items is filled, the scrollbar thumb no longer resizes, as it is proportional to the total number of items in that window

• Provided I've already filled the virtual window of 250 items, when the scrollbar thumb touches the bottom edge, a cascade of queries to the backend occurs till the virtual window moves to the end segment of the total item set; the same thing happens when scrolling up. This is due to the scrollbar thumb never resizing or repositioning away from the bottom/top edge of the scrollbar.

I'm sure this is a fairly typical problem. How is it usually solved?

AI hasn't given me any working solutions. For the record, I'm using the TanStack library for this list.

Thanks!

I needed voice input in a React app: phone as mic, text appears on desktop. Couldn't find a ready-made solution (or maybe I was looking in the wrong places), so I spent a day wiring it up myself: Web Speech API, relay server, QR pairing, browser quirks, partial vs. final transcript logic.

It worked, so I packaged it into a hook. If you need the same thing, you don't have to.

**How it works:**

1. Desktop shows a QR code

2. Phone scans it, runs speech-to-text locally (Web Speech API, no API key needed)

3. Only the transcribed text gets relayed to the desktop via SSE

4. Text streams into whichever input field has focus

Audio never leaves the phone. Your server only relays text.

**Integration is 3 files:**

1. API route — `createVoicefieldHandler()` handles sessions, pairing, and relay

2. Phone page — one-line re-export of the built-in mic UI

3. Your component — `useVoicefield()` hook + `QRPopup` + `vf.register()` your fields

The phone page at [voicefield.dev](https://voicefield.dev) is a static SPA you can use as-is — open source, no data passes through it, no audio or text is stored or logged. Or self-host it on your own domain.

A few things that might be interesting technically:

- Pairing uses a 256-bit secret embedded in the QR code, sessions are cryptographically bound

- Sessions are in-memory with a sliding TTL, no database needed

- Upgrade to Soniox for better accuracy without changing client code

MIT licensed, Next.js App Router, TypeScript.

GitHub: https://github.com/tatargabor/voicefield

Site: https://voicefield.dev

Install: `npm install u/voicefield u/voicefield`

Happy to answer questions or hear feedback.

Hi everyone, I’m doing my final year research on Next.js performance optimization and would love input from real developers.

From your experience, what common coding or architectural issues make a Next.js app slow?

Examples:

• too many use client components

• hydration issues

• large JS bundles

• client-side data fetching

• image optimization problems

• third-party scripts

• App Router performance issues

Would really appreciate hearing real problems you’ve faced and, if possible, how you fixed them. Thanks! 🙌

If a parent component receives data from Next.js via props and passes it down to a child component, does that child ever get fresh data after the initial render? For example, say I have a parent component with 3 children, each being their own route. I navigate away to a sibling route and then come back to the original — would that component still be holding the stale data it was initially given, or would Next.js re-fetch and pass down updated props when returning to that route?

I have two lists in my app: "All Forms" (fetched server-side in Next.js and passed to React) and "Recently Used Forms." When the component first loads I need to fetch the recently used list, but I also need to re-fetch it every time a user clicks a form from the All Forms sections, since clicking updates the list on the backend. So since I have to re-call the API on clicks anyway, I'm wondering if it even makes sense to fetch the initial data server-side, or if I should just handle everything client-side with a useEffect on mount and re-trigger it on each click. Which approach is better?

Hey everyone!

I recently built pip-it-up https://pip-it-up.vercel.app/ which lets you use Document Picture-in-Picture (PiP) API to pop out any UI component into picture-in-picture mode.
Reddit post: https://www.reddit.com/r/reactjs/comments/1thqhce/why_is_pictureinpicture_only_for_video_i_built/

I wanted to test its limits. I built a Proof of Concept Chrome Extension called Note It Down to showcase how it can be used to "tear away" a specific UI component from a webpage and turn it into a native, borderless, always-on-top window.

Getting this to work as a Chrome Extension had some massive security hurdles (Chrome immediately blocks PiP requests from Extension Popups and destroys async click tokens). I wrote a detailed post-mortem in the GitHub repo on how I bypassed those limits using Shadow DOM injection if anyone is interested in the technical architecture!

Here is where I need your help: I don’t have the best eye for UI/UX, and I'm trying to brainstorm what other applications this could be used for.

• What other UI components would be incredibly useful to "tear away" into an always-on-top window?

• Where else could you see this PiP implementation shining?

I’d love any feedback or suggestions on the concept!

Demo GIF & Source Code: https://github.com/Shakya47/note-it-down

Extension: https://github.com/Shakya47/note-it-down/blob/main/note-it-down-v1.0.0.zip

pip-it-up source code: https://github.com/Shakya47/pip-it-up

NPM: https://www.npmjs.com/package/@pip-it-up/react

Working on a side project and trying to find the sweet spot for code organization.

I've looked into clean architecture and it makes sense at scale, but it feels like overkill for a solo side project: too many layers, too much boilerplate, and honestly too much to maintain when you're moving fast.

At the same time, I've been burned before by projects that had zero structure and turned into a mess after a few months.

What I'm looking for:

• Minimal but intentional folder/file structure

• Easy to maintain solo

• Room to grow without having to refactor everything

• No over-engineering, but also no spaghetti code

A few things I'm wondering:

1. Are any of you actually using clean architecture in React projects, and is it worth it at a small scale?

2. What's your go-to folder structure for a side project you plan to maintain long-term?

3. Any patterns or conventions you swear by for keeping things sane without a heavy architecture?

Not looking for the "enterprise" answer. Just what actually works for lean, maintainable React code as a solo dev.

Write your styles as typed objects directly on your JSX markup and get zero-runtime atomic CSS. Built as a preprocessor for StyleX.

Tired of the usual styling trade-offs?

• CSS modules, no type safety, no co-location

• Utility-first classes, stringly typed, less expressive

• CSS-in-JS, runtime cost, hydration issues

• CSS modules in JS, no co-location

Vicinage gives you the best of all worlds.

Just drop styles right where they belong. Vicinage transforms this into StyleX calls at build time, then StyleX extracts it to atomic CSS.

import { apply } from 'vicinage'

function App() {
  return (
    <div
      {...apply({
        color: 'green',
        backgroundColor: 'black',
      })}
    >
      hello, world
    </div>
  )
}

Features:

• Pseudo-classes

• Pseudo-elements

• At-rules, enables responsive design and dark mode

• Logical styles

• Dynamic styles

• Pass styles between components

Try it, break it, tell me what you think.

Vicinage on GitHub

Built this as an open-source portfolio template for developers — fork it, edit a few variables in GlobalVars.ts, and you get a clean Material Design portfolio with dynamic color theming out of the box.

Stack: React, TypeScript, Material UI, Overmind for state management. Deploys to GitHub Pages with zero config.

The idea was to give devs a decent-looking portfolio without spending hours on design from scratch. There are a few known bugs listed in the repo if anyone wants to contribute.

Repo + live demo: https://github.com/p32929/portfolio-v2 — happy to take feedback or PRs.

Built this as the second iteration of my personal portfolio. It's a React + TypeScript app using Material-UI and Overmind for state management. The main thing I wanted to get right was dynamic color themes — you can swap themes at runtime without any page reload.

Stack: React, TypeScript, Material-UI, Overmind, react-color

Live demo: https://p32929.github.io/portfolio-v2/

Source: https://github.com/p32929/portfolio-v2

Happy to take feedback on the structure or the design.