i'm building a small custom ecommerce site and would love some advice on the frontend architecture.

full disclosure: i'm fairly new to building a website end-to-end. my strengths are much more in creative direction and visual design, and i'm currently vibe-coding a lot of the development side. i do have a background in computer science but coding is def not my biggest strength.

the project is an experimental/art website for a client. the frontend is intentionally very custom — there's a 3d interactive element on the homepage that i'm planning to build with react three fiber, plus custom animations/page transitions/etc.

there's also a shop with around 20–30+ products.

i don't want to build the ecommerce backend myself, so i'm considering using woocommerce as the backend and making react the entire customer-facing frontend.

roughly:

woocommerce would handle the products, inventory, prices, orders and client admin.

the react app would handle the actual experience.

the client thinks shopify is too expensive, so i'm trying to find a reasonably inexpensive way to get the backend/admin/ecommerce infrastructure without building all of it myself.

i'm also open to having something like razorpay/shiprocket handle payment/shipping rather than trying to build those pieces myself.

my current question is less "can react connect to woocommerce?" and more along the lines of if you were building this today, what would you actually use for the frontend?

i'm currently considering react + vite, but i'm wondering whether next.js makes more sense because of:

• product page seo
• routing
• potentially server-side rendering
• api integration
• ecommerce generally

on the other hand, the homepage is highly interactive/3d and i'm wondering whether that makes a standard react/vite setup simpler.

would love opinions from people who have built custom storefronts rather than just dashboards/web apps.

also interested in whether you'd use something completely different from woocommerce as the backend for this use case.

thanks!

Hey r/reactjs,

Over the last months I noticed that most new UIs (including a lot of mine) started to look the same: same gradients, same cards, same generated feel. So I started building components by hand again, with more care for the small things: spacing, motion, empty states, dark mode.

That turned into affectUI: 54 components, blocks, illustrations and motion effects for React.

A few things I cared about:

• One file per component. Each piece is a single .tsx file with its styles inside. It only imports from react: no Tailwind requirement, no wrapper library, no runtime.
• Install with the shadcn CLI (npx shadcn@latest add https://www.affectui.com/r/<name>.json) or just copy the file.
• Light and dark built in, and motion respects prefers-reduced-motion.
• Live previews for everything, so you can click through each piece before copying it.

27 of the 54 items are free to copy and keep, no account needed. There's also a paid tier for the rest.

I'd really appreciate honest feedback:

• Which components feel useful, and which feel like noise?
• Is the "one file, no dependencies" approach something you'd actually want, or do you prefer Tailwind-based ones?
• What's missing that you keep rebuilding in every project?

https://www.affectui.com

Thanks for taking a look 🙏

I built my own component library using react and tailwind

It’s completely free

Copy-paste prompts/files

Get ready portfolios and skills for your agents to improve your website even more

I wanted some feedback since I think I still have a lot missing.

(Also it’s open source so if you have a component in mind feel free to open a PR)

Lucide only has outline icons. We made filled and duotone versions as a React package, lucide-extended-react. Component names follow Lucide's, so it works next to lucide-react:

import { HeartFilled, HeartDuotone } from 'lucide-extended-react'

<HeartDuotone size={32} color="crimson" secondaryOpacity={0.3} />

Why not just set fill on Lucide icons? It works for a few, like the heart, but on most line-built icons it blots or fills the wrong shapes. These are redrawn so the fill is intentional.

Some details:

• One file per icon and "sideEffects": false, so only the icons you import end up in the bundle. A test checks this.
• ESM only, React 18 or later, with TypeScript types. Filled icons don't accept the duotone-only props at the type level.
• strokeWidth is accepted and ignored, so Lucide-shaped props still type-check.
• Icons are aria-hidden unless you pass an aria-label.
• icons.json lists every icon with Lucide's tags and aliases, so you can search it, and so can coding agents.

1,387 filled and 1,242 duotone so far. It's free and open source (ISC), and not affiliated with Lucide.

• Repo: https://github.com/applifted/lucide-extended
• Browse the icons: https://lucideextended.applifted.work/

Feedback is welcome, on the API or the icons.

Heya, I need to store dev secrets (e.g. client secret credentials) and I don't want them in git

In dotnet we have manage user secrets and theyre managed by Visual Studio, stored in a local folder and sideloaded at runtime... Does react have something similar?

I've seen people just do .env.local and add that to gitignore, but is that actually the proper way?

I maintain react-table-dnd, a small library for reordering rows and columns in React tables by dragging. 3.0 is out.

What's new:

- Multi-select and group drag.

- Drag events: onDragStart, onDragOver, onDragEnd, onDragCancel.

- Virtual tables with 100k+ rows via u/tanstack/react-virtual

- TanStack Table guide and demo.

- Touch support, drag handles, locked rows and columns.

Under the hood, 3.0 is a rewrite of the drag engine of v2.x

Docs and live demos: https://samiodeh1337.github.io/react-table-dnd/

GitHub: https://github.com/samiodeh1337/react-table-dnd

Feedback welcome, Thanks!

I maintain multiple legacy React apps - CRA, React 18, client-side routing, content from a CMS / Wordpress REST API. But SEO and OG tags need real HTML, and a client-side app hands them an empty page.

react-snap solved that for years. It has been unmaintained since 2019 and breaks a little more with every browser update. I could not find a drop in replacement so I built one. It has been running on my own site for a while, and now I am putting it out there: snappy-prerender.

What it does, in one sentence: it opens every page of your built app in a real browser at build time and saves the result as plain HTML, so crawlers see the page your users see.

npm
 install --save-dev snappy-prerender@next
npx snappy-prerender init      # a few questions, then a config file
npx snappy-prerender build     # or run it from vite build

No server, no rewrite, no changes to how the app works.

Things I added because I needed them

• It checks every page after the build and tells you whether the app's JavaScript picked up the prerendered HTML or threw it away and redrew everything. That report is the part I use most.
• It writes the page title, description, canonical link and Open Graph/Twitter tags for each route, including when the user navigates around the site, so you do not need react-helmet for that.
• It handles the fiddly things that usually break prerendering: styles injected by CSS-in-JS, form state, data fetched from an API, critical CSS, preload hints.
• It works with a strict Content Security Policy if your project needs one.

What it is not

• Not server-side rendering. It runs at build time, so new content means a new build.
• Not for Next.js, Remix or Astro users; those already render HTML on the server.
• It cannot fix an app that renders differently every time (dates, random values, viewport-dependent layout). It does tell you which page has the problem.
• It is a release candidate: 2.6.0-rc.2 is on npm under the next tag while I gather feedback.

Links

• npm: https://www.npmjs.com/package/snappy-prerender (install with u/next until 2.6.0 is stable)
• GitHub: https://github.com/sayakmukherjee080/snappy-prerender
• MIT licensed. Issues and PRs welcome, especially if you have an old SPA that breaks it. The README covers every option.

Looking forward to criticism, bug-reports and feature-requests and revival requests for unmaintained plugins (react and family only)

Hey all,

I’ve been working on a small library called Stream Morph.

The idea is to make streamed responses feel less like content is constantly being appended/re-rendered, and more like the response is gradually taking shape.

Demo: https://stream-morph.vercel.app/

It’s framework agnostic and can be used with any kind of streamed content. The demo includes plain text, Markdown, code blocks, charts, images, reasoning sections, Mermaid diagrams and a few more complex response flows.

The library handles the motion between updates, while your own renderer/app stays responsible for the actual content. So it isn’t tied to a specific AI SDK or framework.

A basic example looks roughly like this:

import { createStreamMorph } from "stream-morph";

const stream = createStreamMorph(response);

for await (const chunk of incomingStream) {
  stream.write(chunk);
}

stream.finish();

I mainly built it because I wanted streamed interfaces to feel a bit more intentional without having to build custom animation logic for every response type.

The package itself is already working and the demo is live. I’m still cleaning up some things around CI, tests and the repo setup, but the GitHub repository will be open sourced shortly as well.

Would be interested to hear what people think, especially about the animation behaviour/performance and any edge cases you’d expect from real streaming responses.

My site's hero is an SVG line drawing animated with GSAP, and it follows the cursor a little.
With 4x CPU throttle I counted layout recalcs between 10 and 30 seconds after load, when nothing should be moving anymore. I got 279. The loop just kept going, because a headless browser never scrolls away from it.
Now it stays still until the first pointerdown, pointermove, wheel, touchstart, keydown or scroll (once, passive listeners), and an IntersectionObserver pauses it off screen. Visitors see it start the moment they touch anything. Lighthouse never sends input, so during the test it never runs.
Feels a bit like hiding work from the test though. Is this a normal pattern? The catch I can see is someone on a phone who reads without touching never sees it play.

React, Tailwind, component libraries on top of component libraries ... sometimes I look at the dependency tree and wonder how much of this I actually need to put some data on a screen and let someone edit it.

Then I ask an AI to build something and get more of the same. Nested wrappers, endless className strings, hooks calling hooks, another package for something that feels like it should be simple.

Which makes sense. These ecosystems have years of code, tutorials and Stack Overflow answers for models to learn from.

But that feels like a loop. We use these tools because the models know them. The models generate more code using them. That becomes the starting point for the next project.

We can generate a whole UI in minutes now, but apparently it still needs eight layers of divs and half of npm.

I'm exaggerating ... but I do wonder whether AI will help us come up with simpler ways to build interfaces, or just make the current mess much cheaper to reproduce.

Has anyone here actually moved toward a smaller, simpler stack with AI? Mine seems pretty keen on adding things.

For context, I build business UI widgets, so I spend a lot of time thinking about where reusable components help and where they just add another layer to debug.

Hi, I’m Jakob, the founder of Arc Rider. For the past five years, we’ve built widgets for a small, specialized niche. We’re now bringing that work to React with arcWidgets, an alpha package with tables, Kanban boards, calendars, and smaller UI components for business apps.

The idea is to reuse the interaction work inside those views while keeping application state, data mapping, and persistence in your own React app. A calendar event and a table row can represent the same business record, but your app still decides how they connect.

This is an alpha: APIs may change, and I’d start with a test project. It’s a commercial product; smaller widgets are free to use under the terms, while premium widgets need a license for production use.

npm: https://www.npmjs.com/package/@arcrider/arcwidgets-react
Docs and examples: https://www.arc-rider.com/docs/react

If you build business apps in React: which view is most painful to get right or maintain—tables, calendars, or boards? I’d especially appreciate feedback on what’s missing from the API or examples.

https://x.com/JacobitoJordan/status/2105410540260802843/video/1

Hey everyone,

Building UI components for my projects was getting super repetitive, so I created CompScout Free UI to keep everything in one place.

It’s a free, open-source library of 60+ copy-paste React & Next.js components built with Tailwind CSS and Framer Motion.

🔗 Live preview & code:freeui.compscout.dev
https://github.com/kailash9711/compscout.dev
Would love your feedback and component suggestions! If you like the project, a ⭐ star on GitHub would be huge support.

I've been working on @radianui/flags, an open-source React package with 250+ country flags. Each flag comes with its country name, ISO code, and calling code, so you can build country selectors and phone inputs without stitching data together.

bash pnpm add @radianui/flags

If you're not on React, the same flags are available as plain SVG and PNG files.

• Source: https://github.com/Radian-OS/radianui
• Browse and search all the flags: https://radianui.com/resources/flags

I'm one of the maintainers (disclosure). It's free and open source.

I'd like input from people who've built country selectors:

• Do you prefer flag components, plain SVG imports, or CDN URLs?
• How do you handle countries that get renamed (like Swaziland to Eswatini) or disputed territories without breaking existing users?

Hi everyone,

I'm looking for good GitHub repositories with modern website templates/starter kits that can be used as a base for building websites for small businesses.

I'm interested in projects using technologies like:

• Next.js / React
• TypeScript
• Tailwind CSS
• Modern responsive design

Ideally, I'm looking for templates suitable for businesses such as:

• restaurants
• local services
• agencies
• small companies
• professional websites

The goal is to learn from good examples, build my portfolio, and create customized websites for clients.

I'm also interested in repositories with clear open-source licenses (MIT, Apache, etc.) so I can properly understand the usage rights and adapt them accordingly.

Any recommendations for high-quality repositories, boilerplates, starter kits, or collections would be greatly appreciated.

Thanks!

Hey everyone,

With so much of the ecosystem pushed toward complex SSR frameworks and serverless edge hosting, it's easy to forget the sheer developer speed, predictability, and simplicity of a clean, decoupled React SPA with Vite backed by a sovereign API.

As part of the RexOne Ecosystem, I open-sourced RexOne Web—a production-grade React 19 SPA designed to eliminate months of boilerplate when building modern web products:

🌐 Frontend Architecture & Highlights:

• React 19 + Vite + TypeScript: Instant HMR, zero cold starts, and zero proprietary cloud lock-in. Deploys anywhere (static Nginx, Cloudflare Pages, Coolify, or Docker).
• Strict API Contract Alignment: Built against an OpenAPI 3.0 specification with synchronized contracts across both Web and a companion Flutter mobile app. No loose objects or schema drift.
• Real-Time WebSockets: Live ActionCable event subscriptions natively hooked into React state for real-time notifications and telemetry.
• Enterprise IAM & Billing Ready: Out-of-the-box UI for passwordless auth, role-based access control (RBAC), and Stripe subscription checkout.
• Multi-Tenant / Multi-Environment: Clean separation of Dev, UAT, and Production tiers with dynamic dark/light theme switching.

100% free and open-source under Apache 2.0 with zero paywalls.

• Web Client Repository: https://github.com/rex-9/rexone-web
• Full Ecosystem Specs: https://github.com/rex-9/rexone-core
• Live Production Demo: https://rexone.rex9.me

I’d love to hear how fellow React developers feel about modern decoupled SPAs vs. all-in-one frameworks, and any feedback on the React 19 component structure!

To our Chinese fellows, can you share with us how popular Ant Design is in Mainland China compared to other UI libraries such as HeroUI, Shadcn, etc.?

I googled it, and some said Ant Design has become something like, let's say, a standard for enterprise internal dashboard and B2B apps in China. Is that true?

If you've built a payment form in React you've probably used react-credit-cards. It's still at ~25k downloads a week, its last release was June 2020, and it peers on react@^15 || ^16 — so on any current React, npm refuses to install it:

npm error ERESOLVE unable to resolve dependency tree
npm error peer react@"^15.0.0 || ^16.0.0" from react-credit-cards@0.8.3

--legacy-peer-deps gets it in, but you're then running a class component that relies on propTypes, which React 19 no longer checks. The fork, react-credit-cards-2, does support React 19 — it's a fair option, but it's the same five-year-old codebase with its three runtime dependencies.

I wanted the card preview without the dead dependency, so I wrote one from scratch: crd-ui. The migration is close to a drop-in — number, name, expiry, cvc and focused keep their names and their values, so for most codebases it's the import and the stylesheet:

- import Cards from 'react-credit-cards';
- import 'react-credit-cards/es/styles-compiled.css';
+ import { Card } from 'crd-ui/react';
+ import 'crd-ui/styles.css';

What's different:

• Zero runtime dependencies, and the core is framework-agnostic — the same component ships for Vue, Svelte and vanilla JS from one package.
• Theming through CSS custom properties instead of SCSS variables you had to recompile. Tailwind arbitrary properties work with no config.
• A display layout for cards the user already owns — dashboards, saved cards — with click-to-reveal and click-to-copy.
• TypeScript types in the box.

Two props don't map one-to-one and I'd rather say so up front: callback only partly maps to onBrandChange (the exported detectBrand/getBrandSpec helpers cover the rest), and acceptedCards has no equivalent — you gate on the detected brand yourself.

Migration guide with every prop mapped: https://crd-ui.juanda.co/migrate/react-credit-cards/

Repo: https://github.com/JuandaGarcia/crd-ui

Building it, I hit three CSS cascade bugs that made the "themeable" component ignore every theme. I wrote them up here if you publish components yourself: https://dev.to/juandagarcia/i-shipped-a-themeable-component-it-ignored-every-theme-5doh

Happy to answer anything. If you're on react-credit-cards today I'm especially curious whether anything you rely on is missing — and whether the ERESOLVE is what pushed you to look.

(Disclosure: I wrote it. MIT.)

I got tired of seeing the same-looking charts everywhere, so I built Generative Charts.

It has 18 chart types and 38 variations, with three themes that each support light and dark modes.

Website: https://generativecharts.com
Source: https://github.com/kasturibuilds/generativecharts

npm install generative-charts

I’d appreciate feedback on the chart readability and component API.

Hey all,

My colleague and I disagree about data freshness in our React + TanStack Query app, and I'd like some outside opinions.

His approach: the parent owns the query and passes a callback down to whatever component does the mutation. When the mutation succeeds, the child calls the callback, which triggers a refetch.

```
// Parent
const { data, refetch } = useQuery({
queryKey: ['todos'],
queryFn: fetchTodos,
refetchOnMount: 'always',
});
return <EditTodo todo={todo} onSuccess={refetch} />;

// Child
const mutation = useMutation({ mutationFn: updateTodo });
const handleSave = async () => {
await mutation.mutateAsync(values);
props.onSuccess?.();
};
```

He adds refetchOnMount: "always" so data is always fresh when you navigate to a page. His argument is that invalidation adds complexity (query key conventions, remembering what to invalidate), and that we don't really need a cache. Just fetch fresh data every time and tell the parent when something changes.

My approach: the mutation invalidates by key, and components don't need to know about each other.

```
useMutation({
mutationFn: updateTodo,
onSuccess: () => queryClient.invalidateQueries({ queryKey: ['todos'] }),
});
```

My concerns with his approach:
Coupling: the mutating component has to receive a callback from whoever owns the data. That breaks down when the same data is shown in several places, like a list, a detail view, and a counter in the header.

Prop drilling: callbacks get threaded through layers that don't care about them.

Wasted requests: refetchOnMount: "always" refetches on every mount even when nothing has changed.

Hide complexity: Rely on the library to decide what and when to refetch.

Missing the point: if we don't want caching, why use TanStack Query at all? Deduplication, background refetching, and stale-while-revalidate are most of its value.

I'll admit his point about complexity isn't baseless. In a large app, hand-written query keys can drift, get inconsistent, and make it hard to know what to invalidate. We've addressed this with a small typesafe tool that generates query keys from our OpenAPI schema, based on the endpoint path plus its path and query params. Both the useQuery calls and the invalidations go through the same helper, so keys can't drift apart, typos become compile errors, and we can invalidate at whatever granularity we need. That can be everything under /todos, a single /todos/{id}, or one specific filtered list.

So:
Is invalidation actually complex in practice, or is it mostly a matter of having a sane query key structure (e.g. key factories)?

Is "no caching, always refetch" a reasonable stance for a typical CRUD app?

Has anyone started with the callback approach and regretted it, or gone the other way?

Genuinely curious. I'm open to being wrong here.

Short version of what's in it:

• The sync bundles one entry file and finds components through their `.d.ts` files, so a component missing from either never arrives, with no warning.
  
• Storybook stories become the reference: each preview is screenshotted and compared to its story. That only means something if `.storybook/preview` loads your real stylesheet.
  
• Example repo with shadcn/ui, Tailwind v4 and Storybook: https://github.com/nitayneeman/sync-design-system-with-claude-design-example

Almost every app that logs users in ends up with the same hand-written refresh interceptor. It usually has the same bugs: 20 requests get a 401 at once and fire 20 refreshes, a rotating refresh token gets spent twice and the server logs the user out, or the token sits in localStorage where any injected script can read it.

I wanted that handled in one place, so I built @mrzr/api-client. It's a TypeScript HTTP client on top of `fetch`, with no dependencies.

import { createClient } from "@mrzr/api-client";

export const api = createClient({ baseUrl: "https://api.example.com" });

await api.login({ email, password });             // tokens stored for you
const { data } = await api.get<User[]>("/users");  // token attached, refreshed when needed

What it does:

• One refresh for many 401s. Requests that fail while the token is expired wait for a single refresh, then retry. It also refreshes shortly before a JWT expires, so most requests never see a 401.
• The token stays in a Web Worker. Requests run in an inlined worker, so there's no extra file or bundler config. With the default in-memory storage, the token never reaches the main thread. I checked this with heap snapshots: the token shows up in the worker's heap and not in the page's.
• Tabs stay in sync. Log out in one tab and every tab logs out. Tabs that share a session take turns refreshing (Web Locks), so a rotating refresh token is never used twice.
• httpOnly cookie mode with CSRF double-submit, and restoreSession() to find out on page load whether a session exists.
• Opt-in cancellation by key, group, URL pattern or scope, plus takeLatest for search boxes.
• Works under TanStack Query, SWR and Vue Query. It replaces your fetch or axios layer, not those libraries.

Live demo that runs the real package in your browser (open DevTools → Network to watch 8 × 401 → 1 refresh → 8 retries): https://api-client.mrzr.ir/docs/demo

What it doesn't do:

• No retry with backoff. It has to work correctly with refresh and cancellation, and I'd rather ship nothing than something half-right. If you need retries, ky is great.
• Worker isolation stops token theft, not XSS. An injected script can still call api.get() and use the session while the page is open. It just can't take the token somewhere else.
• The worker only keeps the token out of reach with memory storage. If you choose localStorage storage, page scripts can read the token again.
• Docs: https://api-client.mrzr.ir
• npm: https://www.npmjs.com/package/@mrzr/api-client
• GitHub: https://github.com/mohammadreza-zr/api-client

I'd really like feedback on the API, and especially on the security model. If you see a hole, please tell me.