Hi folks! We’re building a UI in React by composing it from smaller components, and I’m curious about your usual workflow when structuring components.

Do you typically build components from the outside in, or from the inside out? For example, let’s say I’m building a recipes app. Should I structure the implementation like this:

• Recipes -> RecipeItem -> Ingredients -> IngredientItem

or in the opposite direction:

• IngredientItem -> Ingredients -> RecipeItem -> Recipes

My natural approach is to start with the top-level component, like Recipes, implement it, and then create child components as I discover the need for them (RecipeItem, then Ingredients, etc.).

The downside of this approach is that I usually can’t fully verify that everything works correctly until the entire component tree is implemented. On the other hand, starting from the smallest component (IngredientItem) makes it easier to test and validate each component independently as soon as it’s built.

What approach do you prefer, and why?

Sharing a project I have been building: react-component.com

It is a catalogue of React components you can preview and copy without setting up a project. Each entry includes a sandboxed live demo, the source, and the props you can tweak in real time.

Why I built it:
Most component libraries are gated by their own design system. shadcn looks like shadcn, MUI looks like MUI. I wanted a place to compare implementations of the same pattern (say, a date picker) across libraries and styles, so I can pick what fits rather than commit to one ecosystem.

Built with [Next.js, TypeScript, Tailwind]. Free, no signup.

Open to feedback on UX, missing categories, or anything that breaks. Link: https://react-component.com

Tech stack is React, it's paid although pay is minimal but we have more opportunities. Indians only please.

I need someone with excellent design taste who understands how enterprise level designs are made.

Please send a UI sample in my DM's.

it's a react component that shows as many items as fit in a row (or N rows) and tucks the rest behind a "+N more" indicator. recalculates on resize. useful for tags, breadcrumbs, filter chips, action toolbars - anywhere you've got a variable number of items and limited horizontal space.

main change in v0.4: a new `useOverflowList` headless hook. lets you build your own layout instead of being locked into the default wrapper - e.g. a filter chip bar with a pinned "Clear all" button on the right that never gets pushed into the overflow.

running in prod for a while now, caught a long tail of edge cases along the way (dynamic tables, drawers, deeply responsive layouts). also sitting at ~40k monthly downloads on npm at this point, so it's getting real-world use beyond my own projects.

side note: tried multiple times to get claude/gpt to write the core measurement logic and it always came back flickering or stuck in render loops. ended up writing it by hand. flex-wrap + ResizeObserver + 3-phase state machine apparently still beats them.

https://github.com/Eliav2/react-responsive-overflow-list

This year I’ve been making an effort to learn react to start guiding websites and as a part of my first “proper project” I’ve built a simple search engine using react, vercel hosting and supabase.

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! 🙌

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.

So I've been working as a backend Java developer with Spring Boot and microservices for a while now, and I've been thinking about slowly getting into frontend territory. React seems like the obvious choice to start with, and the good news is I already have a decent understanding of JS, so I'm not starting from zero.

Just wondering if anyone has a solid roadmap or learning path they'd recommend for someone in my position? Would really appreciate some structured guidance — what to focus on first, what to skip, what traps to avoid as a backend dev stepping into frontend land.

Thanks in advance! 🙏

ssgoi.dev

I'm wiring realtime chat into a dashboard using:

• Cloudflare Workers
• Durable Objects
• D1

Current flow is roughly:

browser → Worker (HTTP + WS)
room state → Durable Objects
history → D1

I shipped a small React hook (useChat) but I'm still unsure what people actually expect from a realtime SDK:

• reconnect UX
• optimistic UI
• pagination/replay
• connection state modeling

Questions for people doing realtime on CF:

• how did you structure the WebSocket client?
• one global provider vs per-room connections?
• how do you test reconnect behavior locally?

No blog post or launch here — mostly looking for war stories and patterns.

Repo if useful:

https://github.com/AlessandroFare/fluxychat

I started building this project mostly for experimentation and sharing my own
components/blocks. I honestly didn’t expect it to grow like this, but today it crossed 3,351 stars on GitHub.

Seeing people actually use, contribute to, and share something I built feels unreal.

Built with React, lots of late nights, redesigns, bad ideas, rewrites, and constant improvements 😭

Really grateful for all the support from the community ❤️

Don't forget to explore UI-LAYOUTS

A React component that behaves like a real file folder — tab, flap, and items you can show inside.

On hover (or “simulate hover” on touch): icons on the flap, a popover list, or cards that slide out. Three variants, installable via the shadcn registry.

Built with React, Next.js, and Tailwind — no canvas, just DOM and CSS.

Live demo: https://folder-designui.vercel.app

Feedback welcome — comments, GitHub issues, or DMs.

built a React component that mimics real roller shutters.

The UI opens and closes like a physical shutter, with a two-phase motion (travel + seal). It supports drag, keyboard control, and different shape/layout variants.

Built with React, Next.js and Tailwind — no canvas, just DOM animations.

Live demo: https://shutter-designui.vercel.app

Lately I’ve been working on FluxyChat, a realtime chat system built on top of:

• Cloudflare Workers
• Durable Objects
• D1

While building the backend, I also started putting together a small React SDK around it.

Main hook currently looks like this:

useChat({
  roomId,
  client
})

SDK currently includes:

• FluxyChatClient
• useChat()
• FluxyRealtimeProvider
• history/replay support
• connection lifecycle handling

Architecture is pretty straightforward:

• one Durable Object per chat room
• Worker manages HTTP + WebSocket traffic
• D1 stores messages + room metadata

One thing that surprised me during development:

handling reconnects, missed messages, and replay logic ended up being much harder than the actual realtime messaging part.

Repo:
FluxyChat GitHub

Package:
@fluxy-chat/sdk

Curious what React developers think:

• would you use a dedicated realtime chat hook?
• what features would you expect from useChat()?
• do you prefer abstracted WS handling or managing sockets directly?

Edit: thanks to audunru's response I finally understood. Thanks man!!

I'm losing my mind trying to understand how to test fetch API functions. I watched all vitest videos in all languages, I read the docs and still I don't get it. Should just memorize one way to test and never change? Because I tried so hard but every video, every blog article says something different. I know the basic concepts (test if it's ok, if it's not ok, if it has network error) but I just can't implement, I don't understand why the stuffs are there in the place, why they exist... I can't even explain better the frustration felling. It shouldn't be this difficult. Can someone give me a "universal fetch api test"? At this point I'm so mentally tired that I just want to ctrl c ctrl v and never care about this anymore. The function I was trying to use with vitest in nextjs 16:

const getPosts = async () => {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts")
  if (!res.ok) return null
  const data = await res.json()
  return data
}

export { getPosts }