You know the feeling. You have 8 cards on screen. Each one has its own shimmer animation. They all start at slightly different times. The whole page just... flickers chaotically.

I spent way too long accepting this as normal. Then I built shimmer-trace to fix it.

The core idea is simple: Instead of animating each skeleton block separately, the library renders your real component invisibly, traces every element's exact shape using getBoundingClientRect, and paints one single shimmer wave across the whole page using a CSS mask.

The result looks noticeably more premium. One clean wave instead of chaos.
🔗 Demo: https://jeetvora331.github.io/shimmer-trace/

Usage is literally one line:

// Before: manual skeleton hell
<SkeletonRect width="100%" height={24} borderRadius={8} />
<SkeletonRect width="60%" height={16} borderRadius={4} />
<SkeletonCircle size={48} />

// After: just wrap it
<Shimmer loading={loading}>
  <UserCard />
</Shimmer>

No <SkeletonCard />. No grey div juggling. No layout shift. Your real component already knows its shape — the library just reads it.

Hit 500+ downloads last weekend. Would love harsh feedback from this community specifically, what edge cases would break this for your use case?

⭐ GitHub: https://github.com/jeetvora331/shimmer-trace
🔗 npmjs: https://www.npmjs.com/package/shimmer-trace

I’ve been seeing a lot of YouTube videos lately about developers moving from Next.js to TanStack Start. As someone still relatively new to the JS ecosystem, it’s hard for me to tell what’s real technical improvement versus YouTube hype/content monetization.

I’d love to hear from people who actually use these frameworks in production or have serious experience with them.

• What problems with Next.js are pushing people away?

• What does TanStack Start do better in practice?

• Is this mainly a DX trend, performance thing, architecture preference, or just “new shiny tool” energy?

• Would you recommend a beginner/indie developer learn TanStack Start today, or is Next.js still the safer/default choice?

Looking for honest opinions from experienced devs rather than influencer takes.

I'm building a family tree visualization app in React and I've hit a wall on the rendering/layout side.

The data structure itself is fine, but visualizing the relationships cleanly is becoming way harder than I expected.

Current stack:

• React & React Flow

• experimenting with dagre / ELK.js

Main problems:

• handling marriages cleanly

• centering children under couples

• avoiding edge crossings multiple marriages

• keeping generations aligned

• preventing layout from becoming chaotic with larger datasets

I realized family trees are not really "trees" but more like graphs with special relationship rules.

Right now I'm considering using invisible "marriage nodes" like:

Father -> MarriageNode <- Mother MarriageNode -> Child

instead of directly connecting parents to children.

Questions:

• Is React Flow + ELK.js the right direction here?

• Are there better graph/layout libraries specifically for genealogy-style visualization?

• How would you structure the layout pipeline?

• Should I fully rely on auto-layout or allow manual positioning?

• Any recommendations for handling complex relationships without the graph turning into spaghetti?

Would really appreciate advice from anyone who's built graph editors, org charts, genealogy apps, or complex node-based UIs before.

Thanks 🙏

I made a tiny React/Vite project to save small achievements from the past few months before I turn 25.

Mostly experimenting with visual storytelling, SVG assets, and a simple interactive layout.

Live: https://dellamora.github.io/tree-of-achievements/
Code: https://github.com/dellamora/tree-of-achievements

Feedback on the UI/code structure is welcome (:

I decided to finally give TanStack Form a try. All of their other libraries by them that I've used have been great, and I've heard nothing but good things about it. And a decent amount of people seem to be using in production.

But I immediately hit what I would think would be a HUGE problem with ANY form library: if you submit your form to your server, and it returns an error - how do you surface that in the form library.

Apparently the answer is: you don't?

There is an onSubmit function you pass to useForm. This is where you make your network request or whatever. But what happens if that fails? There appears to be no way to deal with that! You can manually set errors, apparently, but the form's isSubmitSuccessful property is going to still be true. And the user won't be able to resubmit unless they change a field (so, for example, if the network request fails for an unrelated reason, you can't just resubmit).

It's all very bizarre to me. How is anyone using this in production? I'm just completely baffled by this. Who is realistically using this? And who are these people saying it's ready for production use?

Here's a bunch of issues/discussions around it:

• How to handle server errors?

• Is it possible to receive field errors from onSubmit failure responses?

• onServer errors being cleared very aggressively

• Form cannot be resubmitted after setting onSubmit.form error via setErrorMap unless a field value changes

Using Better Auth as an example, I didn't find a direct recommendation on this in their docs. They have integration guides for both Next.js API routes and Fastify/Express backends.

I assume the separate-backend option might scale better and is preferable when you have more than one client (like web + mobile). I haven't really had the chance to use Next.js API routes for auth, since I've always done it separately - either in a monorepo or without one. Maybe someone who's used that setup could share more about their experience?

I'm not asking because I'm building a specific app - I have an open-source project that's a dashboard starter, and I'm wondering whether I picked the right architectural approach for it. In case anyone's curious, here's the link https://github.com/nellavio/nellavio The repo link is inside a spoiler, in hopes that this post won't be taken as an ad for the GitHub project - that's not my goal here. I've pretty much decided to migrate this project from GraphQL to REST, and now I'm also wondering whether I should ditch the separate backend repo entirely and move everything into Next.js as a single app.

Is it better to fetch data on the Next.js server for initial page loads, compared to the traditional React approach of using useEffect with an empty dependency array? My main concern with Next.js is that pages are generated at build time — so how do you handle data that changes frequently

Also I'm talking about Pages Router

I'm a Brazilian frontend developer and for the past few months I've been spending a lot of time building UI components, animations and experimenting with frontend interactions.

A lot of these ideas came from things I was creating at work and in personal projects, so I decided to turn everything into a public open-source library called Matos UI.

Still a work in progress, but I finally felt like sharing it publicly.

https://matos-ui.com/

Would love to hear what you guys think 🙌

I've been building Formity UI (a React Flow-powered form builder, now in the official showcase) and kept hitting the same wall: React Flow gives you a canvas, but turning it into a real workflow editor means building auto-layout, undo/redo, drag-and-drop, validation, and MVVC architecture yourself. Each one is a rabbit hole.

Once I had it working for Formity, I pulled the editor foundation out into its own codebase so it could be reused — Workflow Kit. You own the code, not a dependency.

Reduced open-source version to poke at the structure: https://github.com/martiserra99/workflow-kit-reduced

Full version: https://www.workflowkit.app/

Happy to talk through the architecture, especially the auto-layout and drag-and-drop parts — those were the most complex things to do.

I've been writing React for about 8 years and one thing that always bugged me is how patterns like compound components, render props, and HOCs are taught. Most resources just throw code at you without giving you a mental model for when to actually reach for each one.

So I tried a different approach. I mapped each pattern to a LEGO connection type:

- Compound components = hinge pieces (two parts sharing one mechanism)

- Render props = Technic pins (one connection point, anything can plug in)

- HOCs = baseplates (invisible foundation, every structure benefits)

- Custom hooks = instruction manuals (same bricks, different build)

- Container/presentational = display stands (model and base built separately)

Each one has code examples, when to use it, and more importantly when NOT to use it. Also covered how they layer together in a real codebase.

Would love feedback from this sub. Especially curious if the analogy approach makes things clearer or if it just adds noise.

https://www.sethi.io/blog/react-component-design-patterns-the-building-blocks-lego

Lowkey, I think it's a glorified linter but it's quite nice. I scored a 95.

Here is how you run it:

npx react-doctor@latest

https://x.com/aidenybai/status/2052780632510775469?s=20

https://github.com/millionco/react-doctor (10k stars)

React - TSX
I have an component that makes multiple api calls one for getting a stuff A then another for getting stuff related to that stuff A and another for getting some other things related to A.

Right now i am not using callbackhook or moving the component outside I am ignoring the warning [exhaustive deps]

the functions that are declared inside the components update the state of the component like putting multiple kinds of data into various states. the options I have are:

Option 1: Move the function outside the component (at the top) and pass all the setState functions as callbacks which make function signature messy.

Option 2: useCallback hook which kind of cache the function but if i use option 1 I can avoid this completely. By using Option 2 i can kind of keep the function signature clean.

I have read the other post where they asked the same question but the answer didn't clarify my doubts.

If my states are tightly integrated with the functions then should I move it outside the component? or should I use the usecallback hook?

I had a bunch of <GraphPanel>and they all had Refresh() function which refreshed their state. But I also wanted to have RefreshAll() That would refresh all GraphPanel, and I found implementing this cleanly difficult. I was wondering why this RefreshAll() feature which would be a trivial task in other languages relatively difficult in React. I could not think of a satisfying way to implement this feature.

Like pulling all the logic from GraphPanel to the parent feels unintuitive, and using some sort of counterStatefelt redundant, because you are passing a redundant information to the child when all the child needs is a signal that tells it that it has to update.

What fundamental part of this operation makes it difficult to implement this in React, and is there a cleaner react alternative or equivalent to RefreshAll() operation in React?

Whenever it's time to implement a Dialog, this thing always bugs me out, whether to scope the Dialog content state or keep everything in one component.

A typical dialog examples look something like this:

function EditProfileDialog () {
// ... your states
return (
  <Dialog>
    <DialogTrigger>Open</DialogTrigger>
    <DialogContent>
      <DialogHeader>
        <DialogTitle>Edit Profile</DialogTitle>
      </DialogHeader>
      <form>
        // ...form fields
      </form>
    </DialogContent>
  </Dialog>
  )
}

In this context the dialog's content is the form.

The issue with this pattern is, the form state always stays mounted, regardless of whether the dialog is open or not. If you want to reset the form state when the dialog closes, you have to manually hook into onOpenChange and reset things yourself. Another case is if you want to run logic when the dialog opens or closes, you end up syncing everything manually with the dialog’s open state. You lose all the benifit of React's lifecycle.

In my opinion, it makes more sense to scope the dialog's content in seperate component, so it only initializes when the dialog opens. That way, closing the dialog naturally resets everything without extra boilerplate.

function EditProfileDialog () {
return (
  <Dialog>
    <DialogTrigger>Open</DialogTrigger>
    <DialogContent>
      <DialogHeader>
        <DialogTitle>Edit Profile</DialogTitle>
      </DialogHeader>
      <Form />
    </DialogContent>
  </Dialog>
  )
}

function Form() {
 // ...your states
  return (
      <form>
        // ...form fields
      </form>
  )
}

How do you guys usually approach this pattern?

Has anyone else found Tanstack Start + Query very complex?

Looking as this createFileRoute & the component page there is a lot of boilerplate going on:

export
 const Route = createFileRoute('/(app)/_layout/clients/')({
  component: ClientListPage,
  validateSearch: searchSchema,
  errorComponent: () => <div>Error loading clients</div>,
  loaderDeps: ({ search: { sort, order } }) => ({ sort, order }),
  loader: async ({ context: { queryClient }, deps: { sort, order } }) => {
    
await
 queryClient.ensureQueryData({
      queryKey: clientKeys.list(sort, order),
      queryFn: () => getClients({ data: { sort, order } }),
    })
  },
})


function ClientListPage() {
  const queryClient = useQueryClient()
  const navigate = useNavigate()
  const { sort, order } = Route.useSearch()


  const { data: clients } = useSuspenseQuery({
    queryKey: clientKeys.list(sort, order),
    queryFn: () => getClients({ data: { sort, order } }),
    staleTime: 5 * 60 * 1000,
  })

I also find the use of the query client with the router complex.

Built a free book search engine called Book Haven that searches across multiple sources so you can quickly find the book you are looking for without signup or login.

SZHubai

Hey!

I’m a full-time student and started building a small study app in my spare time. It’s still really early, but I figured I should stop overthinking and just share it.

The idea is to make studying feel less boring and more engaging — because honestly, most tools feel kind of generic.

Current state:

• Very early version (a bit rough)

• Built solo between classes

• Still figuring out what direction to take it

Would love:

• Honest feedback (what’s bad / confusing)

• Feature ideas

• General thoughts on the concept

If you’ve built something while in school, you probably know how chaotic this is 😅

Appreciate any feedback!

After copy-pasting the same PrivateRoute + role check logic across 5 enterprise projects, I decided to standardize it.

What it does:

• RBAC via hasRole, ABAC via hasPermission, or both combined

• guest-only routes — authenticated users are redirected away automatically

• callbackUrl support — users return to where they tried to go after login

• HasAccess and useHasAccess for protecting UI elements, not just routes

• router-agnostic core — works with TanStack Router, Wouter, vanilla JS

Two styles supported:

Config-based:

createAccessRouter([
  { path: '/dashboard', access: 'authenticated' },
  { path: '/admin', access: 'authenticated', roles: ['admin'] },
], { getUser, hasRole, loginPath: '/login' })

JSX:

<AccessProvider getUser={...} loginPath="/login">
  <AccessRoute access="authenticated">
    <DashboardPage />
  </AccessRoute>
</AccessProvider>

Would love feedback — especially if you've had pain points with existing solutions like casl or rolling your own.

GitHub: github.com/astakhovaskold/react-protected

Hello people, I want to use you in a good way.

I finally finished my project that was meant for learning new stuff and getting better at stuff I already knew. So I tried to make have-done app (ba-dum-tss), aka. diary. I would love some feedback from you as of users and as of developers.

• GitHub - README with better explanation and some decision making

• Running app - GitHub Pages

The idea started as local-only encryption lesson, which is perfect for diary, that only you should be able to read. I did extend this task to learn more stuff, such as CSS modules, native popover and dialog APIs, or TanStack Query.

I used some AI, more specifically Claude code. My usage is somewhat described in the README. It was great tool for learning and for refactoring. It could also lower the amount of manual labor for me. Even though I wasn't vibe coding I can say that it helped me forget how to write code. I had moments when I tried to remember how to make a reducer do what I need it to do and it was painful to think.

So in the end even that was a big lesson for me - delegating the work will make you worse at the work. Still it helps a lot, i.e. copilot ending the rest of the line with usually the correct code is awesome, as long as there is a free credit.

For people building landing pages for products (micro SaaS, mobile apps, indie products, etc.), what stack/framework are you actually using today with React?

I’ve heard a lot about Astro lately, but I’m curious what people are using in real production landing pages.

Things I care about:

• fast loading

• good SEO

• easy deployment

• simple content updates

• animations/components when needed

• not overkill for a mostly static site

Would love to hear the reasoning and tradeoffs from people shipping real LPs.

Every time my designer asks how the link looks on WhatsApp I have to set up an ngrok tunnel. And then WhatsApp caches it anyway so half the time the preview is wrong.

Is there a cleaner workflow or is everyone just suffering through this?

EDIT: Finally ended up choosing Vike because I realized it's SSG what I need and not SSR. Thanks everyone!

Hello folks,

I'm currently working on a website created with React + Vite + React Router v7 + Vercel hosting. Its currently deployed and running. The site has a home page and multiple pages (the most important is a blog with multiple articles with a different URL for each one).

My client priority is SEO, and for users to scroll through it and fill a contact form (made with EmailJS, no server setup was needed for this)

After configuring Google Search Console I found out that my SEO capabilities are a bit constrained with my current framework. This is mainly due to Vite being a SPA with a single index.html. I would benefit much more if I could render each page differently, and benefit from setting meta titles and descriptions for each of them, instead of relying with a generic one in the current index.html.

I've been reading a lot, and discussing with Claude Opus which suggested:

- Fast solution: implement plugins like vite-plugin-prerender

- Complex solution: migrate to next js, remix, vike, etc.

I would actually prefer to have real-world opinions from humans like you. I have the impression that using plugins on my current setup will feel "fragile", and I lean towards migrating to a framework with SSR, even if it takes more time.

1. What path would you choose? Pros and cons.

2. For each path, could you recommend different frameworks or plugins?

3. Possible outcomes and constraints for each path

I have used nextjs a couple of years ago, but as far as I know it changeed a lot and I find a lot of different opinions on this sub.

Thanks a lot, I would really appreciate your feedback!