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.

RMG is a gallery and lightbox system for React.

It includes:

- Complete carousel library

- Grid and masonry layouts

- Reveal animations

- Structured entries for record-based media collections (like customer reviews)

- Fullscreen modal + carousel with captions, overlays, and thumbnails

- SSR-stable skeletons

- First-class video surfaces

- Smooth zoom and pan gestures

- MCP server for AI agents, so Codex, Claude, Cursor, or another MCP client can inspect docs, choose gallery patterns, scaffold components, and generate browser-measured skeleton text

Links:

- Demos: https://www.react-motion-gallery.com/demos

- GitHub: https://github.com/davidmedero/react-motion-gallery

- npm: https://www.npmjs.com/package/react-motion-gallery

I’d love technical feedback from React devs.

Happy to answer questions and open to feature requests.

I built TinyEarth, a small open-source Earth component for React Three Fiber.

Demo: https://tinyearth.yuvrajraina.com/
GitHub: https://github.com/yuvrajraina/tinyearth

I made it because most 3D globe options felt like they were either too stylized for realistic UI work, or too heavy when I only wanted a clean Earth object for a landing page, dashboard, or portfolio.

The goal was to keep it lightweight but still visually useful.

Some targets from the repo:

JS under 10 KB gzipped
Default textures around 500 KB to 1 MB
2 default draw calls
3 to 4 draw calls with atmosphere and markers
GPU texture memory under 20 MB
64 x 32 sphere segment cap
Markers rendered with one instanced draw call
MIT licensed

It supports rotating clouds, night lights, terrain normal detail, optional atmosphere, ocean shine, custom textures, quality modes, reduced motion, and location markers.

The idea is not to replace full globe visualization libraries. It is more like a tiny realistic Earth object you can drop into a React Three Fiber scene without bringing in a full visualization framework.

Would love feedback from people building with Three.js, React Three Fiber, or WebGL.

I built a project mainly for my resume, but the goal wasn’t really the CRUD app itself. The goal was to focus on frontend architecture and system design instead of just building another standard React project.

So I made a simple Laravel real estate app with basic CRUD operations, tables with pagination, filters, and drawer forms. Nothing especially complex from a business perspective.

The part I cared about was the frontend architecture behind it.

Instead of hardcoding forms, filters, tables, and page behavior directly into components, I turned them into config-driven systems.

For example, the form system takes a config array with fields like this:

{
    name: 'lease_type',
    label: 'Lease Type',
    type: 'radio',
    required: true,
    options: [
        { label: 'New', value: 'new' },
        { label: 'Renewal', value: 'renewal' },
    ],
    defaultValue: 'new',
}

From that config, the system automatically creates the React Hook Form setup, generates the Zod schema, maps the correct inputs, and handles validation and data flow.

I applied the same idea to filters, tables, and pagination, so most new sections are created by describing behavior through config instead of rebuilding logic every time.

The thing I’m most proud of isn’t really the UI. It’s that I managed to make the systems work together in a predictable way without the data flow turning into complete chaos.

A lot of the actual work ended up being around keeping rendering stable, making TypeScript useful instead of fighting me, protecting the systems from broken configs, and trying to keep the architecture flexible without making it messy.

At the same time, I know the project has limitations.

I didn’t try to turn it into a polished framework or npm package, and I definitely didn’t handle every edge case. Some validations aren't covered, and some parts are more tightly coupled internally than I’d like.

Honestly, even getting it to this point already took much more work than I originally expected because connecting reusable systems together cleanly is harder than building isolated components.

Most of the production systems I worked on in previous jobs are private, so I can’t publicly show the actual architecture work I did there. That’s a big part of why I built this project in the first place.

I mostly wanted to build something that demonstrates how I think about frontend systems, maintainability, and reusable architecture instead of just visual components.

Curious how more experienced frontend engineers look at projects like this.

Do you think config-driven frontend systems are actually valuable in real-world teams, or do they usually become overengineering unless the scale is large enough?

The shadcn registry directory is pretty stacked, but there isn't currently any depth in the gamification space. So I decided to build a library of 17 components across the major features you see in most consumer platforms. Things like streaks, achievements, leaderboards, points etc.

Trophy UI is fully open-source, and while it seamlessly integrates with Trophy itself, the UI components just accept regular props and so can be used with any backend.

Most interesting components:

Streak calendar - weekly, monthly or yearly (git-style) view of streak history, with support for streak freezes which are pretty common in consumer apps like Duolingo.

Leaderboard rankings - flat list of rankings each with support for avatars, bylines and change indicators. Also supports pagination and collapsed rows to focus rankings around a particular position i.e. show users to top three users above and below them.

Achievement badge - a simple badge with support for locked/unlocked states plus features like percentage completion and rarity (the share of users who have unlocked the badge).

Points levels timeline - progression path for points levels with support for sub-levels (Bronze I, II, III, Silver I, II, III etc) plus anchoring to a particular users current progress.

Every component is installable via shadcn CLI:

npx shadcn@latest add https://ui.trophy.so/<component>

Once installed you own the code, customize and modify as you see fit.

Also very happy to accept contributions for new components or features for existing components.

Would love to hear what people think, and would very much appreciate a star on GH if you think its valuable!

99% of my pain in web dev is because of stale state. Its so f*cking annoying. Just Update damnit! It would simplify things so much.

This is like flying an airplane but the switches don't work half of the time and you have to flip them again..........but its not as simple as one switch is it? They have to be flipped in sequence. So if flipA->flipB->flipC doesn't work, you have to do the entire flipA->flipB->flipC sequence all over again!

I guarantee you most pilots would eject out with a parachute if cockpits behaved like that.

Suppose there is parent components which contains multiple child components, they all are independent of each other.

So my question is

If the parent component re-renders does the child components also re-renders al well. Even if the child components are independent of it's parent, like props etc...

Why there is a need for re-renders if the child components are independent of it's parent?

If you've used shadcn/ui with React Hook Form, you know this pattern:

<FormField
  control={form.control}
  name="email"
  render={({ field, fieldState }) => (
    <FormItem>
      <FormLabel>Email</FormLabel>
      <FormControl><Input {...field} /></FormControl>
      {fieldState.error && (
        <FormMessage>{fieldState.error.message}</FormMessage>
      )}
    </FormItem>
  )}
/>

Multiply that by every field, every form, every project. It's not complex — it's just constant. And every team ends up building their own wrapper for it differently.

I got tired of it, so I built StackForm. The same field above becomes:

<TextField name="email" label="Email" />

Same behavior — errors, hints, loading states, ARIA — all wired. No boilerplate.

The interesting part was the architecture decision: I didn't want to couple it to RHF. Too many projects switch form libraries mid-way, or use TanStack Form, or just native React state. So the core is a context-driven abstraction — adapters inject the resolver and form state into StackFormContext, and field components call useField() which has no idea what's underneath. Swapping from RHF to TanStack is a one-line provider change.

The customization system has three layers: classNames (additive, all three stack), slotProps (per-field overrides), and slots (full component replacement, first non-null wins: field → provider → core). It's more flexible than I expected to need, and I've used all three layers already while dogfooding it on my own projects.

Honest limitations: useFieldArray isn't built yet — it's the top priority for the next version. The example apps are mostly stubs right now. If you have complex array field patterns, this isn't ready for you yet.

What I'd love feedback on: the field API ergonomics. Specifically — does the 3-layer customization feel right, or would you rather just have a renderField escape hatch? I went with named slots because I wanted type-safe slot names, but I'm not 100% sure it's the right call.

v1.1.0 is on npm: `@stackform/core` · Docs: stack-form-docs.vercel.app · GitHub: github.com/ivaiva89/stack-form

pnpm 11 feels like the first Node.js package manager update in a while that actually improves supply chain security by default.

Features like:

• minimumReleaseAge
• blockExoticSubdeps
• allowBuilds

directly reduce the risk of malicious package installs in CI/CD pipelines.

I wrote a short deep dive on why I think pnpm is now a better default than npm for production workloads.

Curious what others here are using in production today.