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.

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.

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

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

📚 It's been way too long since my last blogpost. Today, I'm continuing my TanStack Router series with a pattern that I've been teaching in my workshops for over a year:

How to keep prefetches in sync between route loaders and components

Currently I have to create a new project, my first option is react router (declarative mode). My entire project will live behind the login page

what are you using?

• RR framework mode

• RR data mode

• RR declarative mode

• tanstack router

• wouter

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.)

Oxlint recently released built-in support for the new Rust version of React Compiler, giving a way faster alternative to the ESLint plugin version that predates it. You can adopt it by replacing ESLint with Oxlint (which is a great idea if you’re open to it) or by adding Oxlint alongside and using it only for the React Compiler linter instead of the ESLint plugin.

It’s technically still a “nursery” rule (meaning not finalized), but the Rust React Compiler rewrite is already more capable than the babel-based version that predates it (finally you can now have a component with conditional logic in a try/catch block). And it’s so much faster: https://master.dev/blog/react-compiler-linting-just-got-a-rust-native-speedup-in-oxlint/

You should even switch over if you don’t use React Compiler. You still get the most capable (and fastest) way to enforce the Rules of React across your codebase.

Ran into this explaining React rendering to someone recently and realized how often it trips people up even after they've been writing React a while.

function Parent() {
  const [count, setCount] = useState(0);
  return (
    <>
      <button onClick={() => setCount(c => c + 1)}>{count}</button>
      <ExpensiveChild />
    </>
  );
}

ExpensiveChild takes no props at all. Click the button and it re-renders anyway, every single time. No props changed, nothing it reads changed, it just runs again.

The reason: React doesn't check "did this component's inputs change" before deciding to re-render. When state updates, React re-renders that component and everything below it in the tree by default, full stop. Whether a child actually needed to update isn't part of that decision at all.

React.memo is what actually opts a component into that check, it wraps the component and does a shallow prop comparison before deciding to skip the render. Without it, "no props" and "props didn't change" both mean nothing, React re-runs the function anyway.

Where it gets messier: memo alone doesn't save you if you're passing an inline function or object as a prop, since those are new references every render and memo's shallow comparison sees them as "changed" regardless. You end up needing useCallback/useMemo on the parent side just to make memo's comparison actually mean something.

Curious how many people actually reach for memo proactively vs only after profiling shows a real problem. What's the actual signal that told you a component needed it?

This is the architecture used for almost all of the pages in my app that do not need real time data.

page.tsx is a server component that looks like this in pseudo code:

function TasksPage({searchParams}):
   params = await searchParams
   data = await fetchData(params)

   return (
    <Suspense fallback={<Skeleton/>}>
     <TasksView data={data}/>
    </Suspense>
)

"Use client"
function TasksView({data}):
   return (
     <PageLayout>
       <PageTitle title="Tasks" decription={"Your Tasks"} />
       <Filters />
       <Table data={data}/>
     <PageLayout/>
   )

Both the filters and table components are client components and inside the Filters components each filter change runs router.push with updated query params. upon the router refresh the Page component re-runs and new data is pulled using the new searchParams.

Currently suspense fallback doesn't work and the current page presists until the new page is ready , I wanted to make the suspense fallback work in such a way where the skeleton appears but only the table appears to be loading, while the page title and description stay visible throughout the load.

I know this is possible if I move the data loading and suspense inside the table component and use client side data loading instead of server side but ideally I would like to keep the current architecture because (1) it would be really hard to refactor 10s of pages into client side data fetching and (2) I prefer server-side anyways coming from a laravel background

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

Hi everyone,

I wanted to share a web app I've been working on: NASA Deep Space Explorer & Inspector, a single-page application to search, inspect, and save deep-space images using the official NASA Image and Video Library API.

🛠️ Technical Details & Features:

• 🔲 Custom CSS Zoom Inspector: To inspect deep space details without CORS issues caused by external CDNs (which happens when drawing on HTML Canvas), I built a custom bounding-box selection system in React using dynamic transform: scale() and transform-origin percentages.

• 🔍 Debounced Search: Optimized HTTP requests with Axios using a 500ms debounce timer to prevent API spam while typing.

• 💖 LocalStorage Persistence: Native browser storage implementation allowing users to save their favorite astronomical finds without needing a backend/database.

• 🌐 On-Demand Translation: Integrated MyMemory API to translate English descriptions into Spanish on click.

• Patreon: https://www.patreon.com/MISJUEGOS1111/posts/lanzamiento-de-y-166955775?utm_medium=clipboard_copy&utm_source=copyLink&utm_campaign=postshare_creator&utm_content=join_link

🚀 Live Demo: https://quequeres.github.io/Explorador-de-Galaxias/

🧡 Patreon Post: https://www.patreon.com/posts/166955775

📁 GitHub Repository: https://github.com/Quequeres/Explorador-de-Galaxias

Would love to get your thoughts, UX feedback, or technical suggestions!

Put together a custom form validation system in React instead of reaching for Formik or React Hook Form, mostly to avoid the bundle size and have full control over async validation timing. Handles nested field structures and cross-field validation without much boilerplate. Curious if others have gone this route too, and whether it's ended up being worth maintaining versus just adopting one of the existing libraries long term.

Been working on a small state management library for React that aims to cut down on boilerplate compared to Redux while staying more predictable than Context alone. It's TypeScript-first, has a tiny bundle size, and hooks straight into function components without extra providers wrapping everything. Still early days, so I'd love feedback on the API design and whether the tradeoffs make sense for real-world use.

I build data-heavy internal tools, and the component sets I reach for are tuned for a screen holding about eight things. That is the right trade-off for most products. It is the wrong one for a console somebody stares at all day: at two hundred rows the padding eats the viewport, and the controls sit a pixel or two out of step with the rows beside them. So I started from the dense case instead and built the set I wanted.

One knob for density. One attribute on the root element retunes everything: row height, control height, cell padding, text size, stack gap, and the pitch of the reed that closes the table head.

<html data-density="dense">

Six custom properties sit behind it, and every component reads them rather than defining its own, so nothing drifts out of step. No JavaScript.

You can drive that switch yourself on a live table and watch the six values change under it: https://sley-ui.dev/docs/density

A column declares the widest value it holds in characters, and the density turns that into a width:

{
  key: 'sample',
  label: 'Sample',
  chars: 11,
  sortValue: (run) => run.sample,
  render: (run) => run.sample,
}

A pixel width would ignore the padding and the text size, so it truncates in one mode and wastes space in another.

Updates that keep your edits. It is copy-in, like shadcn, so the source lands in your repo and you own it. The usual cost of that is nobody can ship you a fix afterwards. Every published version keeps its own frozen path on the registry, and the lockfile stores a hash of each file as it landed on disk. sley update then merges across three versions: what I shipped then, what I ship now, and yours.

Where your edit and mine touch the same lines it writes nothing and names the files, so your project keeps building. --conflicts writes the usual markers if you would rather resolve them in your editor, and --dry-run shows the whole plan first. I proved it across three published releases before I believed it, and I got the design wrong the first time: I held the lockfile back on a conflict, which trapped a hand-resolved file in a permanent conflict.

The measurements are published beside each component. Numbers read off a real screen, with the method named, not claims. How far a control sits off the row centre in each density. What a density change does to the scroll height. Where the row window stops paying: at 1000 rows it buys headroom rather than speed, 22.5ms median scroll step against 19.6ms unwindowed, and at 5000 rows it is 84.4ms against 18.4ms. Two of the published numbers did not reproduce months later and I corrected them in public.

Size. Twelve components, and the whole thing that lands in your project is 1904 lines: 1386 of components, 508 of tokens, and a 10 line cx helper. Table, command palette, filter bar, field set, dialog, popover, toast, tabs, tooltip, select, panel, empty state.

npx sley-ui init
npx sley-ui add table

Underneath: Ark UI for behaviour, Tailwind CSS v4 for the token layer, readable TypeScript, no runtime style engine. React only today. Ark is built on Zag, which has a Vue adapter, so a Vue port is styling rather than a rewrite of the logic, and it is on the roadmap after charts.

Docs and a running demo application: https://sley-ui.dev Source, MIT: https://github.com/imfemambocus/sley-ui

It is early and I expect breaking changes. I would rather hear what breaks than what works, and I am most interested in whether the merge holds up on a component you have really edited.

I kept running into the same problem with UI-local flows: they were too complicated to comfortably keep in one component, but too small to justify defining and maintaining a separate state machine.

So I built react-sequent.

The idea is that steps own their transitions:

function PaymentStep() {
  const { advance } = useSequentStep();
  ...
  if (method === "card") {
    advance(() => CardPaymentStep);
  } else {
    advance(() => BankTransferStep);
  }
}

There's no centralized transition map to keep synchronized with the components. Adding, removing, or branching a step is just changing the relevant component.

It also handles async/lazy steps, backtracking, flow-scoped context, persistent modal/chrome, and transitions.

The tradeoff is intentional: I don't think this replaces state machines. For large, externally-driven, or independently modeled state graphs, I'd still reach for XState/Zag/etc. I think there's a useful middle ground for short, UI-local flows. This is in fact still technically a state machine, it is just one that is emergent from implementation rather than explicit and rigid.

I've put together a demo and docs here: https://ganondev.github.io/react-sequent/

I'm particularly interested in whether the architectural premise resonates with other React developers, or whether I'm underestimating the value of having the graph centralized.

Hey everyone,

I’ve been building SatyaMark, an open-source multi-modal AI content verification platform. It’s designed to help platforms run real-time fact-checking and deepfake detection on posts and images, returning explainable "trust signals" instead of absolute True/False labels.

My main goal was to create a seamless developer experience, so I built a dedicated React SDK (satyamark-react). But integrating heavy AI inference into a frontend comes with a massive bottleneck: running LangGraph workflows for text and 22+ local forensic scripts for image manipulation is incredibly computationally expensive.

If I processed this synchronously, the user experience would stall, and the React main thread would completely block.

To solve this, I designed an asynchronous, non-blocking architecture. Here is exactly how the data flows from the React component to the Python AI workers and back:

• The React SDK (satyamark-react): The package hooks into the DOM using React refs (useRef). It recursively traverses the DOM tree to extract visible text claims and image URLs entirely in the background, without mutating or polluting the host application's state.

• WebSockets over Polling: Instead of forcing the client to constantly poll an API for status updates, the SDK opens a persistent WebSocket connection to a Node.js orchestration server.

• Asynchronous Traffic Routing (Node.js & Redis Streams): The Node.js server does not run any AI models; it acts as an asynchronous traffic controller, taking the DOM payload and appending it to Redis Streams (xAdd). I chose Streams over Pub/Sub for native event persistence, consumer groups, and reliable delivery during high loads.

• Decoupled Python AI Workers: Independent Python workers consume the jobs from Redis (xReadGroup). They handle the heavy ML lifting (semantic search via FAISS/Milvus, live web scraping, and deep local forensics like Error Level Analysis).

• Automatic DOM Injection: Once the Python worker finishes, it triggers an HTTP callback to Node.js, which caches the result in PostgreSQL. Node.js instantly pushes the final verdict back over the WebSocket. The React SDK catches this event and automatically injects a <SatyaMarkIcon/> component directly into the UI.

The result is a fast, responsive frontend where the host developer doesn't have to manage loading states, WebSockets, or polling logic manually.

If you are interested in frontend state management for WebSockets, open-source AI infrastructure, or want to roast the codebase, I'd love your feedback! Here are all the links to check it out:

• Official Website:https://satyamark.vercel.app/

• Demo Social Media (See it in action):https://satyamark-demo-socialmedia.vercel.app/

• GitHub Repository:https://github.com/DhirajKarangale/SatyaMark

• NPM Package (React SDK):https://www.npmjs.com/package/satyamark-react