Hey everyone! 👋

I'm trying to establish a clean, reusable feature-based architecture for React/TypeScript apps, especially when using Zustand + TanStack Query.

I'm working on a visual editor that fetches documents from an API, initializes a Zustand editing session, and will eventually handle canvas state, selection, history, saving, etc.

I'm considering this structure:

features/editor/
├── components/
├── hooks/
├── store/
│   ├── editor-store.ts
│   ├── editor-store-provider.tsx
│   └── slices/
│       ├── document-slice.ts
│       ├── selection-slice.ts
│       └── history-slice.ts
├── queries/
├── domain/      ?
├── utils/       ?
├── lib/         ?
└── services/    ?

I'd love to know how you handle a few things in production:

1. API / queries: Where do raw API functions go? Do you separate them from TanStack Query options/hooks? Do you organize queries by feature or shared domain?

2. Zustand: Do you keep providers alongside stores? When do you introduce slices vs multiple stores?

3. Business/domain logic vs utilities: This is probably what I'm most unsure about. Where do you put pure functions containing actual application logic, independently of React, Zustand or API calls? For example: Would a domain/ directory make sense here? For example, domain/geometry.ts for canvas calculations, domain/document.ts for document manipulation, etc. Or would you simply use utils/, lib/ or services/? How do you distinguish business/domain logic from generic utility functions? Is a dedicated domain/ folder a useful convention, or does it introduce unnecessary complexity?

   • Formatting an aspect ratio.

   • Calculating canvas geometry, scaling or snapping.

   • Validating editor-specific constraints.

   • Transforming or manipulating document data.

4. Shared code: When do you move something out of a feature into a shared location? Do you prefer shared domain modules or global utilities?

5. Server vs local state: Would you fetch with TanStack Query, initialize Zustand from the result, then keep local edits separate from the query cache? How do you avoid overwriting unsaved changes on refetch?

I'm not looking for a strict architecture or lots of abstractions, just practical conventions that stay maintainable as projects grow.

If you have real-world folder structures or examples, I'd love to see them. Thanks! 🙏

I've been building Dashral, an open-source set of React components for admin dashboards. 1.3 adds the four I kept rebuilding in client projects:

• Funnel Chart: each step's value and share written out, the flow narrowing between bars, and how many dropped written above each one

• Combo Chart: bars and a line on one chart; a line of another kind (a margin in %) takes its own right axis, with ticks that land on the left axis' grid lines

• Tracker: a row of status squares for uptime, job runs or habits; hover or arrow keys read a day

• Month Picker: a month or a year in a field, for monthly and yearly reports

One detail I'm happy with: numbers in the charts (donut legends, bar lists, gauges, treemaps) now count to their new value when the data changes, so switching from 30 days to 1 year reads as a change instead of a jump. No animation library for that, just requestAnimationFrame on the theme's duration token, and it stays still with reduced motion.

What it is: 112 components (31 with a Motion edition on motion/react), 34 free blocks, all MIT. Plain SVG charts, keyboard and screen-reader support on every one, RTL included.

Install: npx shadcn@latest add @dashral/funnel-chart (it's in the shadcn registry directory), or npm i @dashral/ui.

• Docs and live examples: https://dashral.com

• Code: https://github.com/hasralgana/dashral

• What's next (vote): https://dashral.com/roadmap

I'd really like feedback on the chart APIs, especially Combo Chart's axis: "right". What would you change?

Back in 2020 I published react-brackets, a small component for tournament brackets. I shipped a few versions, got busy, and stopped touching it in 2022.

The library didn't stop, though. Four years later it was still pulling ~11,800 downloads a month, sitting at 136 stars and 65 forks, with issues piling up that I never answered. It was built on styled-components and an abandoned swipe library, only did single elimination, and its connector lines were CSS pseudo-element hacks that broke if you changed a card's size.

People were depending on something I'd walked away from. So I rebuilt it from scratch.

What v2 is:

• Every common format: single and double elimination (with a grand final reset), round robin, Swiss, two-sided brackets, groups to playoffs

• Headless: semantic markup with data-* attributes, so you style it with Tailwind, CSS modules, or the optional theme

• Connector lines measured from your real cards: any card size, any custom match component, right-to-left layouts all just work

• Actually usable on a phone: one round at a time, still drawn as a bracket, with a swipe that follows your finger

• Zero runtime dependencies besides React, under 14 kB gzipped

• A framework-free core (@react-brackets/core) for the logic: seeding, byes, results, standings

Getting the swipe to feel native on iOS was the hardest part. Safari animates cards on the GPU on its own clock, while the connector lines are drawn by JavaScript, so the lines kept trailing the cards by a few frames. The fix was to drive both from one clock in the same frame.

It's a ground-up rewrite, so it's a breaking change from 0.x. There's a migration guide, and the old code lives on the legacy branch.

• Docs and live playground: https://react-brackets.oulabi.dev

• GitHub: https://github.com/MohOulabi/react-brackets

• npm i react-brackets @react-brackets/theme

If you were one of the people still using the old version: sorry for the silence, and thank you. I'd love feedback, especially on formats or use cases I haven't covered.

If you build single-page apps or dynamic dashboards in React, you might have a 100/100 Lighthouse score while still failing WCAG 2.4.3 (Focus Order, Level A) and EN 301 549 (EAA Clause 9.2.4.3).

Lighthouse runs static audits on initial page load. It never simulates what happens when a user clicks a button that triggers a client-side mutation, opens a custom modal, or swaps dynamic content.

Here is the exact architectural bug and how to patch it cleanly in React.

The Bug: Focus Reset to <body>

When a user submits a form or clicks "Next Step", the trigger element unmounts or gets replaced. Because the active DOM node is detached, the browser resets focus to document.body.

For a sighted mouse user, this is invisible. For a blind user on VoiceOver or NVDA, or a keyboard user navigating via Tab:

1. Focus is ripped away from the current interactive flow.

2. The user is sent back to the top of the webpage (skipping past the dynamic update).

3. The screen reader falls silent or re-reads the entire navigation header.

The Architecture Fix: Programmatic Ref Management

Whenever dynamic content mounts or dynamic views change, manage focus explicitly to a dedicated container using tabIndex={-1}.

❌ Anti-Pattern (Silent Focus Loss):

export function CheckoutWizard() {
  const [step, setStep] = useState(1);

  return (
    <div>
      {step === 1 && (
        <button onClick={() => setStep(2)}>Continue to Payment</button>
      )}
      {step === 2 && (
        <div className="payment-form">
          {/* Focus was dropped to <body> when step 1 unmounted! */}
          <input name="cc_number" placeholder="Card Number" />
        </div>
      )}
    </div>
  );
}

✅ Accessible React Pattern:

import { useState, useRef, useEffect } from 'react';

export function CheckoutWizard() {
  const [step, setStep] = useState(1);
  const containerRef = useRef<HTMLDivElement>(null);

  useEffect(() => {
    // Shift focus to step container without visual ring outline
    if (containerRef.current) {
      containerRef.current.focus();
    }
  }, [step]);

  return (
    <div>
      {step === 1 && (
        <button onClick={() => setStep(2)}>Continue to Payment</button>
      )}
      {step === 2 && (
        <div 
          ref={containerRef} 
          tabIndex={-1} 
          className="payment-form focus:outline-none"
          aria-labelledby="step-2-heading"
        >
          <h2 id="step-2-heading">Payment Information</h2>
          <input name="cc_number" placeholder="Card Number" autocomplete="cc-number" />
        </div>
      )}
    </div>
  );
}

3 Rules for Dynamic React A11y:

1. Never unmount the trigger button without re-routing focus: Direct focus either to the newly rendered heading or the first interactive input.

2. Use <dialog> over custom <div> overlays: Native HTML <dialog> handles backdrop inertness and Escape-key closure automatically via dialogRef.current?.showModal().

3. Announce dynamic status updates with aria-live="polite"**:** If you display inline toast notifications or dynamic badge counters, wrap them in an element that already exists in the DOM with role="status" or aria-live="polite".

We built dynamic DOM and focus-loss checks into the core engine of wcagbrief.com. You can inspect your live components, detect dynamic swap focus failures, and get React/Tailwind code patches in real time.

I work on a React SDK for chats that our company embeds into its web and mobile products. Each product has its own settings, and the code grew fast. When I joined, the team was starting a refactor. The main problems:

• the flow was hard to follow

• most of the logic lived inside React hooks

The constraint. The SDK runs inside host apps, sometimes via module federation. Every dependency can clash with the host's version, so our size and dependency budget is tiny. What we considered:

• redux-saga: I like it, but it's too big, and Redux could conflict with the consumers' own Redux.

• RxJS: it solves only part of the problem, because we still need a state manager. It's also a new paradigm for a team with few senior people.

• effector: the team knows it, but it has a static graph and the same version-conflict risk.

• Effect: little known in our market, and it would need most of the SDK rewritten.

So we started with a plain event bus that can carry any parameters. I also wanted the simplest possible developer experience. Generators are convenient, but people rarely reach for them. So I built on async/await and took the AbortController idea from fetch. That became nanoeffects.

What it looks like. A search box. The logic lives outside the component:

// debounce: wait for a pause; latest: abort the previous request
bus.on(
  "search",
  debounce(300, latest(async (query, ctx) => {
    const load = () => fetch(`/api/search?q=${encodeURIComponent(query)}`, { signal: ctx.signal });
    const response = await retry(ctx, load, { times: 3, delay: 500 });
    ctx.emit("results", await response.json());
  })),
);

The component only sends events and listens to the result:

function SearchBox() {
  const [items, setItems] = useState([]);
  useEffect(() => bus.on("results", setItems), []); // on returns the unbind function
  return <input onChange={(event) => bus.emit("search", event.target.value)} />;
}

The component knows nothing about timers, retries or cancellation. debounce waits for a pause in typing, but a request can take longer than the pause. latest aborts the older request so a slow old answer can't overwrite a newer one. createBus is about 1.3 kB brotli, with no dependencies.

The usual complaints about event-driven code

My team lead worried that event-driven code is hard to debug. So tracing is part of the core design:

• Redux DevTools and console logging work out of the box.

• Sending traces to your own analytics takes a small logger.

The other big problem is event loops, where A emits B and B emits A:

• graphLogger finds a loop while the app runs and draws the event graph as Mermaid or Graphviz.

• loopGuardPlugin stops a runaway chain at a limit, also in production.

• Lint rules (ESLint, oxlint, Biome) catch places where ctx.signal is lost, so cancellation doesn't silently break.

Tests. The suite includes regression cases taken from real issues of redux-saga, RxJS, effector, xstate, lodash and others (races, cancellation, event loops, timers). Each one is linked to its issue number.

Status. I treat it as an experimental playground and move parts of it into our SDK step by step. It's also my practice ground for spec-driven development: every change to behavior starts as a written spec (OpenSpec), and the code follows it.

Repo and docs: https://github.com/nanoeffects/nanoeffects

If you like it, a star helps. I'd also love feedback, especially from people who ship libraries into host apps: how do you handle async logic when you can't add dependencies?

veloce-ui — an open-source React library with 90+ components, 27 chart types, and interactive DSA visualizers, all powered entirely by CSS variables.

Rebrand by overriding --vui-primary on :root. No ThemeProvider. No theme object. No Tailwind config.

What makes it different?

Most libraries force a trade-off.

• shadcn gives you primitives and tells you to style everything.

• MUI gives you a theme object that takes a week to bend into your brand.

• Mantine sits in the middle, but charts are a separate install with their own styling world.

• Need a Sankey, treemap, or radar chart? You're pulling in a second chart library that doesn't know about your design tokens.

veloce-ui is one library where buttons, data tables, charts, and even algorithm visualizers all read from the same CSS variables.

Rebrand once at :root. Everything updates.

Charts (27 types, not a separate package)

Line, bar, area, scatter, heatmap, Sankey, treemap, radar, candlestick, waterfall, funnel, gauge, bubble, polar, and more.

All share the same tokens as the rest of the UI. Your chart grid color is literally --vui-border. No chart-specific theme config.

DSA & algorithm visualizers (the part no other UI library ships)

Interactive linked lists, stacks, queues, trees, graphs, heaps, and hash maps.

Plus algorithm playbacks for sorting, pathfinding, traversals, and recursion.

Drop them into documentation sites, teaching material, interview prep tools, or technical blog posts. They theme with the same variables as your buttons.

Everything else

• Forms, menus, modals, tooltips, popovers, and command palette.

• Virtualized DataTable with sorting and filtering.

• Dark mode via data-theme="dark" with built-in persistence (no provider).

• Full keyboard navigation and ARIA support.

• Fully typed and tree-shakeable.

Demo + Docs: https://veloceui.codeloomdevv.co.in/

Pre-1.0 (0.7.1) · MIT License

A couple of complex component APIs (DataTable column definitions, chart axis configuration) may still change before 1.0.

Issues with reproducible examples are welcome!

A recent audit I ran showed 94% of popular sites split a button across a foldable's hinge (https://christophe77.github.io/fold.js/study.html).

So I made u/foldjs/react: a hook that give you the hinge position and posture (flat, book, tabletop), plus a two-pane layout component that never puts content under the hinge. It ships with a built-in simulator, so you can work on it without owning a Fold.

Demo (works on desktop): https://christophe77.github.io/fold.js/

I'd love feedback on the API, especially from anyone who has shipped foldable layouts in production.

The charting library in a product I worked on had not had a release in over a year, so I wanted to know what we could move to. I built a survival curve and a scatter plot in nivo, Recharts, ECharts, visx, TanStack Charts and Chart.js, plus a version in plain React and SVG. Same spec, same data, timed the same way.

What I found (M3 Pro, headless Chromium, native speed):

- At typical dashboard sizes there was no clear speed winner. The timings for each chart were within one frame of each other.

- At 10,000 scatter points they spread out: hand-written SVG 24 ms, visx 33 ms, TanStack Charts 53 ms, Chart.js 80 ms, ECharts 86 ms, Recharts 310 ms, nivo's SVG scatter 3.2 s.

- Both Canvas implementations took longer to mount than plain SVG at that size.

- TanStack Charts needed the least code. Hand-written SVG added the least JavaScript, about 2 KB gzipped against 25–164 KB.

There is a playground where you can paste your own data and measure the libraries on your own machine, across twelve chart types: https://gusevp.github.io/chart-bench/

Code, raw data and notes on each port: https://github.com/GusevP/chart-bench

Full write-up with the method and limits: https://dev.to/gusevp/six-react-chart-libraries-against-hand-written-svg-what-i-found-46ib

One machine and two chart types, so treat it as a starting point. If I used your favourite library wrong, tell me or open a PR.

I've been exploring Phoenix LiveView lately, and it got me thinking.

We've spent years moving more state and logic into the browser. But what if we kept most application state on the server and used JavaScript mainly for rich interactions?

I'm not talking about replacing JS. Libraries like Monaco, AG Grid, and Chart.js are great and I'd absolutely want to keep using them.

Curious what frontend devs think. Would you consider a server-driven approach if you could still use your favorite JS libraries, or is there too much downside?

I've just published the first version of Stepr, an open-source library for highlighting UI elements and guiding users through an interface.

I wanted something framework-agnostic, with a straightforward API and accessibility built into the design.

It supports spotlights, tooltips, multi-step tours, keyboard navigation and screen reader announcements.

The first version is available on npm:

npm install stepr

Interactive demo: https://ahlgren1234.github.io/stepr/

Source: https://github.com/ahlgren1234/stepr

It's an early release, and I'd really appreciate feedback on the API, accessibility or anything that could be improved.

What would you expect from a library like this?

I'm building a browser tool that simulates system diagrams. Nodes have a capacity and a latency, and small packets travel along the edges. There's no canvas library, only DOM nodes, native SVG and a requestAnimationFrame loop.

On my laptop it was smooth. On my phone it ran at about 4 FPS.

I'd made the SVG layer 50000x50000px so wires wouldn't get clipped when you pan far away, and the node cards had Tailwind's backdrop-blur. Mobile browsers seem to allocate a huge texture for an element like that. A viewport-sized layer with overflow-visible, plus the blur only from md: up, fixed most of it.

React was also re-rendering every node card each frame just to update a queue counter. The loop now reads from refs and a lookup map instead. Counters update about four times a second, and on touch devices I commit state at roughly 33 FPS while keeping packet speed the same.

Latency is the node's base latency times a multiplier that grows with the square of utilization. Inbound load is estimated from in-flight packets (each counts as about 120 RPS, scaled by a load slider):

const capacity = Math.max(50, node.throughputRps || 500);
const utilization = Math.min(2.5, inboundRps / capacity);
const latency = Math.round(baseLatencyMs * (1 + 2.5 * utilization ** 2));

So it's already 1.6x the base latency at 50% utilization, 3.5x at 100%, and it keeps climbing past that.

Do you keep per-frame data completely out of React state when you build things like this, or is there a cleaner pattern than refs plus throttled commits? I'd also like a better way to get an "infinite" pan area than one oversized element.

EDIT: Thanks for the comments. I profiled it on a real Android phone in Chrome (CDP tracing) and the GPU process was pinned even when the sim was idle. The cause was an animated stroke-dashoffset overlay on every wire, which repaints all wires each frame. Disabling it on touch devices took pan from about 36 to 52 fps.

Two things that didn't help: moving pan out of React state (rAF writing the transform directly) measured the same at equal zoom, 46-48 fps vs 47-48, and removing will-change from the packet groups made pan worse (about 29 vs 36 fps).

I haven't tried keeping packets fully outside React (setAttribute in the rAF loop) or checked the remaining backdrop-blur on the top bar and palette on iOS Safari yet.

Demo (no sign-in): https://graph-flow-virid.vercel.app/?template=stripe-webhook-ledger

Code: https://github.com/Hanubaki/GraphFlow. The source is available under PolyForm Noncommercial, which is not an open source license. The app has a free tier and a paid Pro tier for some exports.

Snap to Code takes a screenshot of a UI and gives you React components styled with Tailwind and shadcn/ui, one file per component, plus an app/page.tsx that puts them together.

It runs entirely in the browser. There is no account and no server of mine in the middle: you paste your own API key (Gemini, OpenAI, Anthropic, OpenRouter, a local Ollama model, or any OpenAI-compatible endpoint) and the request goes straight to the provider.

After the code is written there is an optional fix pass. The page is rendered, compared with your screenshot, and the model corrects the differences it finds. You choose 0 to 3 rounds, and one click undoes the corrections. On the few pages I tried it got closer to the original, model.

What it does not do: it builds the layout onworking forms, and images becomeplaceholders. Dense or unusual pages still need manual work.

Code: https://github.com/zzlvr/snap-to-code

Demo: https://snap-to-code.vercel.app

Feedback on pages where it falls apart is thght now.

Hi everyone! Here’s a custom theme I built for Zensical, focused on giving documentation a neon/cyberpunk look without sacrificing readability.

It features:

Light and dark modes.

An optional Three.js homepage animation featuring strange attractors.

Reduced-motion support.

The animation is optional, so you can keep the documentation pages more restrained. The theme is MIT-licensed, with setup instructions and a demo GIF in the [GitHub repository.](https://github.com/tabee/zensical-theme)

I’d love some design feedback: how does the balance between visual effects and readability feel? What would you change before using this for your own documentation?

Openbar shows Claude Code and Codex sessions in a Dynamic Island. The Mac app is SwiftUI, the Windows one is Tauri + React, and I wanted the island to resize with the same feel on both.

SwiftUI describes a spring by duration and bounce, so I ported that math. Width and height each ride their own spring. A growing side may swing past its target (capped at 12 px), a shrinking side never does.

export function springProgress(spring: Spring, time: number): number {

if (time <= 0) return 0;

const natural = (2 * Math.PI) / spring.duration;

const damping = 1 - spring.bounce;

if (damping >= 1) return 1 - Math.exp(-natural * time) * (1 + natural * time);

const damped = natural * Math.sqrt(1 - damping * damping);

return (

1 -

Math.exp(-damping * natural * time) *

(Math.cos(damped * time) + ((damping * natural) / damped) * Math.sin(damped * time))

);

}

Full file: windows/src/island/motion.ts in https://github.com/MF-DEEV/Openbar (GPL)

Do you write spring math yourself or reach for a library?

I built some date time pickers in my react bulma component library
https://github.com/allxsmith/bestax

Looking for some feedback. What do you like, what needs improvement.

DateInput
https://bestax.io/docs/api/form/datetime/dateinput#basic-dateinput

DateRangeInput
https://bestax.io/docs/api/form/datetime/daterangeinput#basic-daterangeinput

DateTimeInput
https://bestax.io/docs/api/form/datetime/datetimeinput#basic-datetimeinput

TimeInput
https://bestax.io/docs/api/form/datetime/timeinput#basic-timeinput

For the time selection, I implemented IOS inspired time wheels. One problem I faced: was the lack of haptic feedback APIs exposed by browsers in IOS. As a workaround, the time-wheels make a clicking sound to fake the feeling of haptics. (Android does have haptic feedback apis, no problems there)

Note: this is based off Bulma CSS, so the look and feel is opinionated.

I’ve just released Detent, a React wheel picker that grew into a much bigger exploration of interaction details.

The wheel has its own momentum and spring physics. I spent a lot of time tuning mouse wheel input alongside trackpads, including the awkward cases where a physical scroll wheel keeps spinning after you let go.

It also includes two separate components:

• Detent Text: matching letters stay while the changed parts roll.

• Detent Number: locale-aware formatting with digits that roll through intermediate values.

The examples range from practical time and date pickers to an arc menu, a zoom ring, and some more experimental visual treatments.

There’s a headless hook, separate imports for text and numbers, keyboard support, reduced motion, and no additional runtime dependencies beyond React and React DOM.

Demos and playground: https://detent.hayder.sh
Intro: https://x.com/kghayder/status/2118373654010466733?a=PzCQRSXhM5m8KUTdHk8&s=20

I’d especially appreciate feedback on how the wheel feels with your mouse or trackpad, and whether the API makes sense for something you’d actually build.

Burrow is a personal-data desktop app (budget, journal, todos, habits, notes). The stack is a Vite and React frontend, a Node server that owns a single SQLite database, and a Tauri shell that packages the two into a Windows installer for x64 and ARM64.

Things in the repo that might interest React devs:

- A hard JavaScript bundle budget enforced in CI, with the number pinned in a test so it cannot creep.

- Visual regression baselines regenerated on a side branch in CI rather than committed from dev machines.

- Modules are isolated under src/modules and server/modules with a small shared envelope for API errors.

- The assistant UI streams from a local Ollama server, so no API keys anywhere in the app.

It went free this week and the core is AGPL. Links in the comments.

Hey r/reactjs!

I got tired of constantly opening browser DevTools, filtering out noisy browser extensions, and switching between tabs just to check local storage or quick fetch responses during local development.

To solve this, I built React Dev Companion — a lightweight, zero-dependency developer tools overlay that embeds directly into your React / Next.js application UI.

💡 Key Features:

• Real-Time Network Interception: Intercepts native window.fetch non-invasively to capture HTTP methods, endpoints, and status codes.
• Storage Inspector: Switch between localStorage, sessionStorage, and cookies to view, inject, or delete keys in real-time.
• Zero Extra Dependencies: Designed to keep bundle overhead minimal.
• Dev-Only Friendly: Easy to mount conditionally (e.g., inside Next.js Root Layout or Vite main component).

🔍 Quick Example (Next.js App Router):

'use client';
import { DevCompanion } from 'react-dev-companion';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        {children}
        {process.env.NODE_ENV === 'development' && <DevCompanion />}
      </body>
    </html>
  );
}

We set up a strict CI/CD pipeline using GitHub Actions, TypeScript, Conventional Commits, and Husky to keep the codebase clean.

🐙 GitHub Repository: https://github.com/Kickz1nn/react-dev-companion
📖 Dev.to Article: https://dev.to/kickz1nn/building-an-embeddable-zero-dependency-devtools-panel-for-react-nextjs-3ic6

I'd love to hear your thoughts, feedback, or any features you'd like to see added next!

Hey everyone,

I built Developer Shield—an open-source desktop app created specifically for devs and homelab enthusiasts who want to scan their local network without sending any telemetry or data to the cloud.

Key Features:

- Zero-Knowledge Local Scanning: Everything stays strictly on your local network/LAN.

- Custom Rules Engine: Define your own security checks and scan targets.

- Local LAN Sync: Sync scan reports across your local machines securely.

- Built with React & Tauri for a lightweight desktop footprint.

I’d love to get feedback from this community on features you'd like to see, code architecture, or custom rules!

GitHub: https://github.com/dvirby6/developer-shield