r/reactjs

Hey everyone! I’m building Nagare, an open-source runtime that unifies styling (Tailwind/CSS), animation, state, and JS logic into a single block called a "Soul".

Instead of managing ternary states in your JSX and bouncing between event handlers and CSS, you define the behavior in one place. Your JSX stays 100% clean.

"use client" import { useSoul } from "@nagarejs/react"

export default function Component() { useSoul((soul) => { soul("button-soul") .default({ tw: "px-4 py-2 bg-blue-600 text-white rounded", state: { active: false } }) .click({ onStart: { css: `@if active { transform: scale(0.95); }`, js: function(this: any) { this.state.active = !this.state.active; } }, onEnd: { css: `transform: scale(1);` } }) })

return <button data-soul="button-soul">Click Me</button> }

🛠️ Tech stack: TypeScript, React, Vite. 🚀 Current status: Core engine works, but I'm looking for people who want to help build:

Vue / Svelte adapters

Better event listener cleanups

More built-in detectors (like swipe, drag, or idle)

I don't have a massive network, so I'm looking for curious frontend devs who want to collaborate, roast my architecture, or help shape the API.

https://nagare-nu.vercel.app

I am a full stack developer with 6 YOE. At work, I don't even read the front end code anymore when claude writes it. I still read the backend code to make sure data access, security etc are done right, but for the front end if it works, passes linting and tests and looks good, I don't really read it. I know there isn't gonna be any obvious security risks like api keys etc because I don't have them in my local anyway, and the foundation is correctly set up for auth, rbac and I am not touching those most of the time (almost never).

But it's also more than this. I can't even bring myself to read the generated code. Like it feels like a huge chore to read what claude wrote. I know the architecture is right and sound. So I just make sure the correct files are edited or new files are created in the right places and that's it. Most of the time the PR reviewer just rubber stamps it too. Anyone else feel this way?

I have around 3 years of full-stack development experience (MERN/PERN), and over the past 4 months I've attended nearly 30 interviews.

The good part is that I've improved a lot. My communication is much better than it used to be, and I can confidently answer most technical questions. I've reached the later rounds in several interview processes (almost 8), but I keep getting rejected in the final stages with either generic feedback or no feedback at all.

Recently, I interviewed with a startup that's building LLM-based products and training its own in-house models. I made it to the final round, where we discussed the architecture of my previous company's product, the features I designed, deployment, CI/CD, scalability, business impact, and technical decisions. The final round was mostly behavioral, and I felt it went well. I left the interview feeling confident, but I never heard back.

What confuses me is that this wasn't my experience in 2024 or early 2025. Back then, I got multiple offers without putting in anywhere near this much effort.

Most of the roles I'm interviewing for ask for 3+ or 4+ years of experience, so maybe I'm simply losing out to candidates with a bit more experience. But I'm not sure.

I'd love to hear from people who've been involved in hiring or have seen the current market from the other side.

- Is it common to keep interviewing candidates even after there's already a preferred candidate?

- Why do candidates who perform well throughout the interview process still get rejected in the final round?

- Has the market really become this much more competitive over the last year, or is there something I'm overlooking?

I'd really appreciate any honest advice. I'm genuinely trying to improve, but after months of interviewing, it's becoming difficult to understand what I'm missing.

The Radix stagnation saga last year showed that shadcn's "you own the code" promise has a catch: your components are only as stable as the primitives they import.

So I've been toying with an idea: same distribution model as shadcn (CLI copies source into your repo, registry, nice defaults), but every component is built on native platform APIs. Zero runtime deps. Each component is a single readable file you can actually audit and understand end to end.

I'm not pretending this is free. The tradeoffs as I see them:

• Bigger files. No primitives layer means each component carries its own focus/keyboard/ARIA logic
• Fixes don't auto-propagate. With Base UI, a bug fix ships to everyone via npm.
• Modern browser floor. Native dialog/popover/anchor positioning means recent browsers only

Would you actually use this, or is Tailwind + Base UI too entrenched?

Not looking for advanced architecture advice.

Just one small thing that improved your projects.

Examples:

• lifting state less often
• better component composition
• custom hooks
• React Query
• lazy loading
• memoization (when appropriate)

Curious what little habit had the biggest impact.

I'm relatively new with react. Recently I started working with websockets. I've built a websocket and it got rather large, in order to help keep things organized I decided to create a single object in a separate file with the websocket functionality. So the new object has a function for opening the socket and handling all the interactions with the back end and I passed to it a number of functions for updating my variables.

One of my variables is another objection with functions and variables. Not all the variables get updated with each call to the backend so my code looks like this:

const [tableInfo, setTableInfo]=useState(tableInfoDefaultObject);

...

const UpdateTableInfo = (dictionaryForUpdate)=>{

setTableInfo({...tableInfo, ...dictionaryForUpdate})

and I pass the UpdateTableInfo function to the websocket object. What I'm finding is that it only uses the original default tableInfo. I think it passes the whole function instead of just a reference to it but I'm still a bit foggy on how react does this. Is there a way around this? I'm OK with moving the functionality back into the main web page, just wanted to organize things better and figured that there's probably a way to make this happen.

Looking back at old projects, I noticed I was solving problems in much more complicated ways than necessary.

For me it was overusing Context when local state was enough.

What's something you used to swear by but rarely use now?

Everyone knows React Query, React Hook Form, and React Router.

I'm more interested in the hidden gems that made your life easier.

I am making a devlog, in which will have hundreds of logs. It will be self hosted on my personal server using Vite+React

Markdown files seem most obvious for devlogs of course, but I would also like the devlogs to have pictures and youtube links.

My question is: is it reasonable to have each devlog as a react component? Or should I use markdown with yaml frontmatter? Or maybe there is a better standard?

Essentially: I want to know the fastest/best way to load mass amounts of content.

Examples:

• State management
• Hydration
• Build tooling
• Bundle size
• Server Components
• Something else?

What belongs in Redux, URL state, server cache, and local state in modern React apps

As a senior developer I’ve seen many developers over-engineering the front-end system and putting too many things in Redux (or Zustand) but after years using Next.js, React Query, context providers and URL parameters, I have a clear vision on what goes and what does not go into global state, there is also a bit of server side rendering.

This is still a problem in the front-end because we don’t see clearly the difference between app state and server state, to give you an example in a social media style page app state can be the posts that you’re actually interacting with and pressing likes and server state are the new posts that are added in the meantime, we need to have a clear picture of what the user is interacting with if we don’t want them to make an update on the wrong post, or see an outdated number of likes because of the wrong cache or offline mode. When new posts come in the feed we need to implement techniques to sync with the app state taking into account a sync strategy: optimistic updates, handling race conditions, and sometimes offline queues so interactions are not lost or applied to the wrong entity.

By adding too much to the global state we’re increasing the cost in several ways: rerendering too much, having stale data that is not synced with the server source of truth, and increasing the difficulty to test components. The smaller the state, the less we need to worry about these things, I’ve seen way too many times a parent React component that rerenders on every interaction every single child component because it is subscribed to too many store updates. There are mechanisms to prevent this, like React memoisation, split slices…

First we need to break down 4 different types of state:

• Server state: TanStack Query, React Query, Server side components and anything fetched from a REST API.
• URL state: query, path, filters, pagination, selected tab, shareable views
• UI state: modals/drawers open, themes, sidebars
• App state: Shopping carts, Draft composition, optimistic updates, offline queues.

What should never go in a global state:

• Controlled input value on every keystroke
• Page content that barely changes over time (blog posts)
• This object that I need in the next page so I’m going to save it in the state so everything seems like a single page application.

For example in a shopping website, the cart needs to be global as is shared across multiple components and pages, needs to be updated from the server regularly (server is the source of truth to keep prices and discounts real) Product details doesn’t need to be stored in the global state, server side rendering takes care of caching, and pagination, filtering and search are URL properties, there is no need to over complicate things here.
In a blog the articles need to be server side cached for SEO and speed, with optimistic updates on comments etc.

It is very useful to take this into consideration when reviewing a pull request, sometimes we don’t stop to think if the use of Redux is necessary to store the list pagination state or some terms and conditions text that we need in several places. A document in the repo for developers to come back to when making a decision is also a good idea.

In conclusion: default to local state and server cache (React Query, RSC, SSR where it fits). Use global state only when several components or pages share the same piece of data

If you liked posts like this you can visit my website to read more articles: raypoly.netlify.app/blog

I've been building a fair amount of websites with TanStack Start / Vite / Cloudflare Workers lately. I love the stack, but the one thing that's been causing me a lot of headache is optimizing images.

So far, I've tried a couple of approaches:

• vite-imagetools style, where you use import params to specify all widths and formats, which are generated at build time like this:

&#8203;

import srcSet from 'example.jpg?w=400&h=300&format=webp&as=srcset'

• CDN optimization (in my case, Cloudflare Image Transformations with the url-based API). I have a custom <CloudflareImage> component that handles this.

The problem with vite-imagetools and similar build-time solutions is that they rely completely on Vite import params. So imports are ugly, and there's no type safety or convenient means of ensuring that your imports don't have typos.

I somewhat worked around this by creating custom presets so that I could instead import from example.jpg?preset=hero or similar. But there are inevitably a lot of edge cases that don't fall cleanly into a preset, so you still end up with a lot of long, ugly import strings.

Cloudflare Image Transformations has the upside of being a runtime solution, which allows for baking logic like desired transformation widths into the actual image component. However, it too has some major drawbacks.

For one, it costs money. It's a pretty trivial amount, but it can add up, especially in development. Secondly, there isn't a convenient way to use Cloudflare transformations in development. You can either host images in S3 and point to the S3 bucket for transformations in development, or else you're stuck rolling a custom solution for local development with a Workers images binding.

It feels like there's almost certainly a better approach here to image optimization. I know Next has this functionality built-in, but my understanding is that I'd then have to host on Vercel or another more expensive provider, since Next's image optimization server isn't compatible with serverless platforms like Workers, without integrating something like CF image transformations.

How do you non-Next, non-Astro users handle image optimization? Is there another solution I'm missing, or is this just a hole in the ecosystem?

I’m working on a Next.js app with authentication handled through Clerk. The authentication is done server-side.

The current flow is:

1. The user signs up or logs in with Clerk.

2. After the first login, they go through an onboarding flow where they need to provide some additional information.

3. This information is not just basic user data that I can get from Clerk. It’s app-specific data that the application needs later.

4. After onboarding, the user gets access to the actual dashboard/application.

Most of my app logic is server-side. For every request at this state (I'm at the very start of the project), not only mutations but also GET requests, I have a server-side function in Next.js that calls my external backend, and that backend returns the data I need.

My main confusion is around caching.

A lot of this information does not change very often. For example, the user’s profile data or the information collected during onboarding is updated rarely. The mental model I was trying to use is something like this:

* I create a server-side function that fetches the user data from my external backend.

* I cache that function or that request in Next.js.

* Whenever a page needs the user data, it just calls that function.

* If the data is already cached, I avoid another call to my backend.

* When the user updates their data through a form, I invalidate the cache.

* The next time the data is needed, it gets fetched again from the backend and cached again.

In theory, this felt like a way to avoid client-side state management for data that is already available server-side and does not change frequently. But I’m not sure if this approach is correct, if it’s an anti-pattern, or if I’m missing something important.

I also have a few related doubts.

Clerk seems to verify the user every time I visit a page. But if the user has already authenticated once, shouldn’t it be enough to have a token with an expiration time and only verify the user again when that token expires? Or is it normal for this verification to happen frequently on the server side?

Also, does it make sense to use Server Actions for GET requests? Since I have an external backend, I’m wondering whether it makes sense to cache things in Next.js, or whether caching should be handled directly in the backend instead, for example with Redis.

Overall, I’m pretty confused about how I should think about caching in this setup. I want to avoid unnecessary backend calls when I know certain data rarely changes, but I also don’t want to build something fragile or conceptually wrong.

What is the correct way to handle this kind of data in a Next.js app with Clerk, an external backend, and mostly server-side logic?

Over the years, in our goal to achieve faster and faster web applications, we created different hydration and rendering strategies. Each with benefits and drawbacks that we explore in this article.

Hi everyone,
I’ve been debugging one of the strangest frontend issues I’ve ever encountered and I’m completely stuck.
Stack
React
Vite
TypeScript
Tailwind CSS
Lucide React
Chrome & Edge (Chromium)

The Problem
Some Lucide icons randomly don’t render.
The weird part is that they’re still there:
The button is clickable.
Hover effects still work.
The SVG exists in the DOM.
Width and height are correct.
Computed styles look normal.
display, visibility, opacity, stroke, color, etc. are all correct.
Only the icon itself isn’t painted.

The Strange Part
Changing browser zoom immediately changes which icons appear.
Example:
At 90%, some icons disappear.
At 100%, different icons disappear.
At 110%, those icons suddenly appear again.
The behavior changes depending on the zoom level.
This happens in both Chrome and Microsoft Edge.

Things I’ve Already Tried
Removed all page blur animations.
Added global Lucide CSS rules (flex-shrink: 0).
Removed unnecessary transforms.
Verified SVG width/height.
Verified computed styles.
Verified stroke="currentColor" and computed color.
Tested browser hardware acceleration.
Refactored layout containers.
Investigated overflow and flexbox.
None of these changed the behavior.
Example SVG

<svg
class="lucide lucide-users size-3 text-brand"
xmlns="http://www.w3.org/2000/svg"
width="24"
height="24"
viewBox="0 0 24 24"
fill="none"
stroke="currentColor"
stroke-width="2"
&gt;
...
</svg>
Computed styles look completely normal:
width: 12px
height: 12px
display: block
flex-shrink: 0
stroke: correct color
color: correct color
Yet the icon is invisible.

Important Detail
The invisible icons are still clickable.
The layout space exists exactly where the icon should be.
Only the SVG isn’t rendered.
Browser zoom immediately makes them appear again.

Question
Has anyone seen something like this before?
Is this likely:
a Chromium paint invalidation issue?
a CSS rendering bug?
a Tailwind interaction?
a Lucide issue?
something else entirely?
I’d really appreciate any ideas because I’ve spent hours debugging this and haven’t been able to isolate the root cause.
Thanks!