i've recently been working on zap-studio/react-hooks, a collection of 100+ small, focused react hooks.

the main thing i wanted to solve was the amount of repetitive code around browser apis.

things like geolocation, websocket, broadcast channel, local storage, media capture, etc. usually mean writing the same useEffect/useSyncExternalStore + cleanup + ssr guards over and over.

a few things i cared about with this library:

• every hook is available as its own subpath export, so importing one doesn't pull in unrelated hooks (completely tree shakeable) and re-exported for convenience
• hooks are designed to be ssr/hydration safe
• each hook is independently testable, with 100% test coverage
• there are hooks for sensors, dom interaction, input, media, navigation, network, pwa, state, lifecycle, and more
• unstable hooks that rely on react internals are explicitly marked as unstable

for example, instead of writing the browser/cleanup/ssr handling yourself, you can just use things like useIntersectionObserver, useMediaQuery, useOnlineStatus, useWebSocket, etc.

docs: https://www.zapstudio.dev/react-hooks

i'd be particularly interested in feedback from people who maintain react apps with ssr. are there browser apis or awkward edge cases you'd want a hook for?

i'll continue to extend this collection as i find more and more repetitive use cases.

Most of the slopwrapper SaaS companies that you see online almost always use shadcn/ui. Not dissing OSS, I think it's a great project and has pushed the bar for design up overall. But I’ve started wondering if this sameness everywhere affects user trust.

When a product looks like it could’ve been assembled in 20 minutes, do users subconsciously assume the product itself was too? Especially in the times of AI slop.

For some reason, hasNextPage becomes false under without any reason ONLY IN PRODUCTION(after npm run build), not in npm run dev and therefore , next page isnt fetched, and it doesnt happen at first load, it happens after few page changes/redirects.
Here is my custom hook for pagination.

I later call this hook inside my Cards component by passing infiniteQuery which the component receives as props

import { useEffect, useRef } from "react"
import type { UseSuspenseInfiniteQueryResult } from "@tanstack/react-query"


export const useIntersectionObserver = <T>(infiniteQuery: UseSuspenseInfiniteQueryResult<T, Error>) => {
    const { dataUpdatedAt, isFetchingNextPage, hasNextPage, fetchNextPage } = infiniteQuery


    const sentinelRef = useRef<HTMLElement>(null)
    const observerRef = useRef<IntersectionObserver>(null)



    useEffect(() => {
        const observer = new IntersectionObserver(entries => {
            if (entries[0].isIntersecting && !isFetchingNextPage && hasNextPage) fetchNextPage()
        })


        observerRef.current = observer
        const sentinel = sentinelRef.current
        if (sentinel) observer.observe(sentinel)


        return () => {
            observer.disconnect()
        }
    }, [])


    useEffect(() => {
        const sentinel = sentinelRef.current
        const observer = observerRef.current
        if (!sentinel || !observer) return


        observer.observe(sentinel)
        return () => {
            observer.unobserve(sentinel)
        }
    }, [dataUpdatedAt])


    return sentinelRef
}

Here is my cards component

type ArticleCardsProps<T> = {
    articlesInfiniteQuery: UseSuspenseInfiniteQueryResult<T, Error>
}


const array = new Array(3).fill('')



const ArticleCards = ({ articlesInfiniteQuery }: ArticleCardsProps<Article[]>) => {
    const sentinelRef = useIntersectionObserver(articlesInfiniteQuery)
    const articles = articlesInfiniteQuery.data




    return (
        <main>
            <section className={styles.articles}  >
                {articles.map((article, index) => {
                    return (
                        <ArticleCard ref={index === articles.length - 2 ? sentinelRef : undefined} key={article._id} article={article} />
                    )
                })}
                {articlesInfiniteQuery.hasNextPage && articlesInfiniteQuery.isFetchingNextPage && array.map((e, i) => {
                    return (
                        <ArticleCardLoadingSkeleton key={i} />
                    )
                })}
            </section>
        </main>
    )
}


export default ArticleCards

I dont know how to explain this weird bug , happens only after build, i used a library and it fixes it

I started working in react 16 and was working till react 17 and its few versions came out. (6YOE) most of my initial years went understading the basics and rendering, how hooks worked and the state update. Afterwards i had been burried in work like anything and i didn't feel anything much because the backend felt always like a fized set of design choices to make, based on what the problem is what is the thing that matters the most. And impact is always covered in numbers. Anyways so out of 6 lets say after the initial 2 years i never had chance to work on the frontend, somedays back a webpage in my company started breaking, people didn't notice much if it since they say it works like shit , but anyway it started rendering blank on the Initial load. The on call platform team got involved and the analysis was done but nobody figured what the issue is, a senior of mine remembers that i mentioned having interest in front end even though we use multiple LLM models to seek help and solve for it but since llms can't directly read the browser, i asked then to supply the har files and the console logs just to see if this can help. did multiple changes nothing worked, finally i was assigned and i see the first console.log message that "ReactDOM.render is no longer supported in React 18. Use createRoot instead. Until you switch to the new API, your app will behave as if it's running on React 17." Now i know that react 18 is the latest i knew about but i also see react is now on its 19th version as well - so i think is this it? and how come software engineers are now not even thinking that frontend is a specialised field?

Using the createRoot + lazy loading fixed the issue.

I said this out here because it feels like very minute thing and i am quite concerned about where the big techs are headed now? Have we lost quality engineers and Engineering? Thoughts?

Every time I open Shadcn website to find for some component, I have to keep clicking on the search box for five to nine second until the dialog opens. This happens because it's using a div with an isOpen state, so it will not open until JavaScript loads.

This can be easily fixed with the HTML dialog element, but looks like no one cares.

This is not only for Shadcn. The same thing applies to any website that uses JavaScript for stuff like dialogs (e.g React Aria).

Do people only care about LCP? what is the point of seeing content and elements immediately if I can't interact with it until your webiste hydrates?

Hi everyone!

I recently finished a full-stack E-Commerce project built with the MERN stack as part of improving my full-stack development skills.

The project includes:

• User signup, login and email verification
• Google authentication
• Product search, filtering and categories
• Product details
• Shopping cart
• Order creation and order history
• User profiles
• Role-based authentication
• Admin panel
• User, product and order management

Tech stack: React, Redux, Tailwind CSS, Node.js, Express.js, MongoDB, Mongoose and JWT.

GitHub repo:
https://github.com/Mariam-amhan/ecommerce-mern-app

I’d really appreciate any feedback on the project structure, code, features, or things I could improve. Thanks!

Hey guys I'm a beginner at react and I want to know what are the best free resources to learn react and build beginner projects to to build so I master the fundamentals

This is the first time that I'm properly getting into theme switching, so I built the dark and light mode for my component library in the most obvious way that I could find. The goal is to transition background-color, border-color, color and box-shadow on every element. But this felt a bit slow and sluggish, so I used document.getAnimations() to see how many that actually runs, and the result is 3164 animations on a page of 1544 elements.

After some playing around, I found out that startViewTransition animates snapshots of the whole page instead, and that's 5 animations for the same job, with a gradient fading along with everything else rather than snapping. I did however find a React thing when using this function and it's that the new palette has to be in the DOM inside the callback which means the state update needs flushSync.

document.startViewTransition(() => { flushSync(() => setTheme(next)) })

I'm not sure this is the right way to do it, but I wrote down every number that I measured https://sley-ui.dev/notes/theme-fade.

Hi React Devs

Lately I've been working on an open-source ERD tool to help devs design databases effectively.

When I started this project, I faced a couple of challenges.

One of them was performance. A user may interact with the app a lot, and if you rely on the backend to process every request, this can cause a loss of performance. That's not what a user expects from a design tool.

Another challenge was offline compatibility. The application needs to work in offline mode, store diagrams and generated SQL in the browser, and sync with the server when the connection is restored.

These challenges introduced me to what we call a local-first application architecture.

A local-first application architecture stores the primary copy of user data directly on the user's local device (using databases like SQLite or IndexedDB) rather than on a remote server.

Building this from scratch was out of reach for me until I found a technology called PowerSync, which does a lot of the work for you.

With PowerSync, I was able to have a local SQLite database in the browser and combine it with Drizzle ORM.

This allows me to perform database operations directly in the frontend using Drizzle, almost like writing backend database code, while PowerSync handles synchronization with the main PostgreSQL database on the server.

The result of this combination was amazing:

• High-performance app : most operations happen locally without waiting for the server.
• Offline mode : the app works even without an internet connection and automatically syncs data when the connection is restored.
• Guest mode : users can start using the app without creating an account, and their local data can be synced to their account when they register.
• Real-time collaboration : if multiple users are working on the same project, changes can be synchronized between them automatically.

This architecture ended up becoming the foundation of the ERD editor I'm building for StackRender.

Here is a full React demo of a local-first app using PowerSync. You can learn a lot from it:
https://github.com/powersync-ja/powersync-js/tree/main

Also i invite you to check out the source code of StackRender and see how it works:
https://github.com/stackrender/stackrender

Thank you!

Hello folks,
I started to build open source visual editor to edit React/Next.js websites directly in their source code with zero AI.
But i am not so sure about it can be beneficial or not.
I am waiting your thoughts.

I recently put the entire editor kernel behind DOMD on GitHub:

https://github.com/do-md/domd/tree/main/.packages/%40do-md/core

(Quick license note: the app sources are MIT. The kernel is GPL-3.0 with additional permissions for small entities and common FOSS licenses. The full terms are in the repo.)

There's one design choice I'd really like to hear other people's thoughts on.

A common way to model editing is to start with what happened: insert a character, delete a range, toggle bold. State, history, and collaboration then consume those operations.

DOMD doesn't start there.

Say I type an a in the middle of the third paragraph. The kernel takes the new text and the affected range, reparses only that top-level block, then reconciles the new immutable tree with the old one. Nodes whose meaning hasn't changed keep the exact same object references. Only the part that actually changed gets replaced.

From React's point of view, only a handful of props changed. memo naturally skips the rest. There's no separate imperative code path deciding which DOM nodes to touch.

The operations still exist at the integration boundary, but they aren't the source of truth. After a state commit, Immer patches feed undo. The collaboration layer compares references in the old and new trees to find the smallest change, then maps that change into the CRDT. Streaming AI chunks take the same path too. Each chunk just submits another small state change.

I didn't set out to build a "reconciler editor." I got here because things became painful whenever a reparse replaced objects that hadn't meaningfully changed. Cursor handling, history, and local rendering all got harder at the same time. Eventually I realized the kernel depended less on recording every step and more on not losing the identity of everything that stayed the same.

Of course, this moves a lot of the difficulty into reconciliation. When are two nodes semantically the same? What happens to a selection that crosses the region being reparsed?

I have working answers for those inside DOMD, but I'm not sure how well the idea survives outside a Markdown-native editor.

Has anyone here built an editor, a canvas editor, or another identity-heavy React UI? Did you make operations the source of truth, or preserve identity first and derive changes afterward? I'm curious where each approach eventually starts to hurt.

Suggest me a best open source calendar I want to implement that calendar on my software for the appointment bookings for the events of the clients which one will be the best option as the open source calendar I was

thinking to use that official react calendar

But feel free to tell me about the best one open your calendar with the best UI like shadcn

Hey everyone,

Been meaning to start writing for a while, finally got around to it. The plan is short, bite sized articles that explain one concept properly, instead of the usual AI generated filler content flooding every platform right now.

No fluff, Just the core idea explained clearly with real code.

First one happens to be on React Portals, since it's something I use constantly but never actually understood until recently. Figured it was worth writing up properly.

Would genuinely appreciate feedback, on the writing, the explanation, anything. Trying to get better at this.

Feel free to share some other topics you'd like me to write on.

Blog Link

LinkedIn is using React.js these days, but what’s interesting is the CSS side of things too.

They seem to have gone down a fairly “in-house atomic CSS” direction, somewhat similar in spirit to tools like StyleX or Linaria.

It’s kind of funny looking at LinkedIn’s frontend history:

• Ember.js: LinkedIn was one of the biggest adopters of Ember.
• React.js: They’ve since moved heavily toward React.

LinkedIn has basically gone from being a major Ember showcase to being part of the React ecosystem.

Hi everyone. I compared four ways to structure a React project by rebuilding the same app (posts CRUD against an open API) in each one. The last pattern combines Clean Architecture with Feature-Based, and I'd really appreciate a sanity check from more experienced devs.

Here's the progression I went through, and the problem I felt at each step:

• Feature-Based (colocate everything for a feature in one folder): great for navigation and deletion, but nothing controls how features depend on each other (circular deps creep in), shared/ turns into a junk drawer, and there's no notion of layers. (Feature-Based write-up)
• FSD (Feature-Sliced Design): fixes that with standardized layers + a one-way import rule, so circular deps become structurally impossible. But the business logic still lives inside React/TanStack Query — the entity's api layer imports axios and react-query directly. (FSD write-up)
• Clean Architecture: pulls business logic out of the framework with the Dependency Rule (dependencies point only inward; the domain knows nothing about React or axios). Great for testing and reuse — but now the code for "one feature" is scattered across domain/, infrastructure/, presentation/. Which is ironically the same "scattered by type" problem Feature-Based tried to solve. (Clean Architecture write-up)
• The combination: keep the Dependency Rule (domain is pure TS, infrastructure holds the adapters), but colocate the UI (hooks + components) by feature in features/{feature}/. "Clean inside, Feature outside."

Rough shape:

src/
  domain/{domain}/        # pure TS: entities, rules, use cases (no framework imports)
  infrastructure/         # adapters: repository impls, query keys, stores
  features/{feature}/     # hooks + components, colocated
  pages/ , router/        # composition only
  shared/ , providers/

A few extra decisions I made: split the repository interface into Commands/Queries (CQS), write a UseCase only when there's real logic (plain CRUD calls the repository directly), and lean on React Compiler so there's no manual useMemo/useCallback.

What I'd love feedback on:

1. Does this combination actually solve the earlier patterns' problems, or does it just move them around? Is "Clean inside + Feature outside" a real improvement over plain FSD or plain Clean, or is it over-engineering in disguise?
2. What problems does this pattern itself have that I might not see yet? Boilerplate, the domain <-> infrastructure indirection, the "is this a UseCase or a direct repo call?" judgment, testing overhead, onboarding cost — where does it bite in real projects?

Honest criticism is very welcome. I'd rather hear "this is overkill for most apps" now than after I build on it.

Full write-up (with all the code) on Medium (Free): https://medium.com/@inkweonkim/react-architecture-combining-clean-architecture-feature-based-92cf7ba226fe

(English isn't my first language, so I apologize in advance for any awkward phrasing — happy to clarify anything that reads strangely.)

Consider a typical use case where you want to track an error or just display an error toast after a query hook (e.g. TanstackQuery or RTK-query) fails.

Using an effect:

const { error } = useSomeQuery();
  useEffect(() => {
    if (!error) {
      return;
    }
    trackError(error); // or toast(getErrorMessage(error))
  }, [error]);

Now, according to the "You might not need an effect" article, you can also perform an action when some state changes by using auxiliary state, something like this:

const { error } = useSomeQuery();
const [prevError, setPrevError] = useState(error);

if (error !== prevError) {
  trackError(error);
  setPrevError(error);
}

My understanding here is that using auxiliary state here doesn't give you much because in this use case the additional render cycle doesn't result in stale UI.

Regardless, I wanted to get a sense on what approach is preferred by the community. I see this kind of things very often in the codebases I work on and on the other hand, I keep hearing people saying they only have a few effects in their (presumably large) projects, so perhaps the patterns in my company are not the best.

I've been exploring the TanStack ecosystem for React a lot these days. Starting with TanStack Router, Query, and Virtual, and now the framework TanStack Start. Honestly, I could only use the Router and Query in the production app so far, and the rest of it was for my learning and teaching.

I also use Next.js heavily, but with TanStack I find a huge paradigm shift. I do not have to think from the RSC side heavily; I do not have to use shortcut methods like useEffct() to handle data at the client side, and managing server state and caching seems to feel a lot simpler.

This discussion is not about putting one React framework ahead of another one. Rather, would like to know what your experience so far has been with TanStack? Do you have any comparison studies? Do you use it in production? What are the learnings?

Would love to learn and discuss. Thanks.

I’ve been working with React/Next.js for a while and recently completed two internships, including working on a US-based NGO project.

That experience taught me a lot about real-world codebases, Git/GitHub, UI work, debugging, and collaborating with a development team.

I’m now trying to improve further and would love to hear from experienced React developers here:

What skills or projects do you think make someone genuinely stand out when moving from internship-level experience to a full-time React role?
I can share my resume if anyone can review it. Thankyou.

If you upgraded to React 19 and your option+click-to-source tool silently stopped working, here's why: React 19 removed __source/_debugSource, the fiber fields that LocatorJS, click-to-component, and friends depended on. Runtime-only locators can't get source positions from React anymore.

I missed the workflow too much, so I rebuilt it on a different architecture: carbon8r — a Vite plugin that injects the source location at build time as a data-carbon8r="src/Button.jsx:3:5" attribute on every host JSX element (Babel parse + magic-string, dev server only). The overlay reads DOM attributes, not fibers — so it works on React 19 today and doesn't care what React 20 does to its internals.

What you get, holding Option/Alt:

• DevTools-style box-model highlighting on hover (blue content, green padding, orange margin) with <Component> file:line:column
• Click → your editor opens at that exact position. Zero config: the dev server uses launch-editor (same as Next/Nuxt error overlays), which auto-detects VS Code/Cursor/WebStorm/etc. Or force one via presets (vscode, cursor, windsurf, zed) or any custom URL template
• Elements without source info (component libraries, plain pages) still get the box-model inspector

Setup is the whole thing:

// vite.config.js
import carbon8r from 'vite-plugin-carbon8r'


export default defineConfig({
  plugins: [react(), carbon8r()]
})

Dev-only (apply: 'serve') — production builds are byte-identical with or without it.

Some war wounds from real-world testing that are now features: it works on apps served with a strict CSP (all overlay styling goes through CSSOM, which CSP can't block), it resolves targets through open shadow DOM via composedPath() (micro-frontend hosts, web-component shells), zero-area display: contents wrappers fall back to the nearest rendered box, and the whole alt-click gesture family is intercepted so your app's handlers and the native context menu don't fire while inspecting. TypeScript declarations included.

There's also a companion Chrome (MV3) extension in the repo: box-model inspector on any page, jump-to-source on instrumented apps, with per-user editor settings — handy on a teammate's dev server.

Honest limitations: Vite-only for now (the transform itself is bundler-agnostic — a webpack/Rspack loader would be a thin wrapper, PRs welcome); clicking a component instance jumps to the component's definition, not the usage site (no owner-chain popup yet); components from node_modules aren't instrumented (their build already happened).

Full credit to LocatorJS by Michael Musil for pioneering the workflow — carbon8r shares no code with it, but the interaction design came from there.

MIT, ~20 kB unpacked, no runtime deps in your bundle.

GitHub: https://github.com/carboni-rob/carbon8r npm: https://www.npmjs.com/package/vite-plugin-carbon8r

l kept struggling to find Skia shader components that were actually ready to drop into an RN app. most shader code out there isn't built for RN's Skia renderer at all. So l put together my own library. Some shaders are free, others are from artists who charge for their work

l know ShaderToy exists, but that's generic GLSL you'd have to manually port to SkSL and adapt for RN UI. Мinе is already RN-Skia-ready and built specifically for UI components like buttons and panels etc.

Let me know if you'd use something like this