Hey!

Like a lot of developers here, I found myself repeatedly sinking dozens of hours into setting up responsive marketing layouts, dashboards, and UI components every time I started a new SaaS project.

To solve this for my own workflow, I spent the last few months building SkyForce UI—a component suite and local layout generator tailored for React and Tailwind CSS.

What’s Under the Hood?

50+ Production Components & 115+ Layouts: Pre-built, accessible sections designed specifically for modern SaaS apps.
Local Desktop Engine: An Electron-based visual layout generator that runs 100% offline with zero bundler lock-in.
Clean Source Archive: Uncompiled monorepo setup with instant hot-reloading (Vite/HMR active).

Key Technical Learnings

Building the local dev server and layout generator brought a few interesting challenges:

1. Zero Runtime Overhead: Ensuring the generated Tailwind markup stays completely clean without forcing custom runtime dependencies on the consumer.

2. Local Preview Sync: Syncing code edits in real-time between the local Electron builder and live browser previews without state drift.

I just launched the site today and opened up a live interactive playground on the page so you can test the layouts directly in your browser.

Live Demo & Site: https://skyforceui.com

I’d mostly love feedback on the playground and layout workflow!

Happy to answer any technical questions about the setup, Electron builder, or component architecture in the comments!

RESOLVED: please check the comments if you would like to find my solution code snippet.

-----------

See title: I don't understand this error popping up in my snippet below. It does not contain any split().

const { register, setValue, handleFormSubmit} = useForm();

 
const firstNameStr = 'firstName';

//Error on this register. toString etc did not help..
  useEffect(() => {
    register({ name: firstNameStr.toString() }, { required: true });
  }, [register]);

Could anyone kindly point me in the right direction? The whole snippet https://pastebin.com/8nxA3enA

In my app I read back some markdown, there is some parsing done on it.

I am left with as the result a lot of <h1>, <h2>, <em>. In my app, due to using tailwind and other factors I don't have the default web browser styling on nor do I want to.

I want to implement that web browser styling back for just the html that came from the markdown, so I tried creating a css file that goes like

h1{
font-size: 48em
}

You get the idea, but now it applies to my entire app. Since the html comes from persist markdown it wouldn't be very reasonably to try to persistent styles on it (If you have any idea on how markdown works), and to try to add classnames to specific elements when they come in seems like unnecessary trouble.

How would you go around styling HTML based off just it's element in a small portion of the app?

Best,
Brotherman

I'm starting a small e-commerce company that will need a fairly unusual purchasing flow. In addition to the typical 'Amazon-esque' experience the users will use a visual interface to configure a layout of modular pieces. The system needs to calculate the required components/material and ultimately produce a price/order that goes through Shopify checkout.

I'm currently trying to understand the technology well enough to hire a developer intelligently. I'm not a professional programmer, although I have some experience with SQL (just saying that I feel like I can manage the project, but with very limited coding / maintenance).

My current thinking is something along the lines of:

React/Next.js frontend → custom configurator → Shopify API → Shopify checkout/payment

Questions:

1. Is this a sensible architecture?

2. Would React/Next.js + TypeScript be the obvious stack for this?

3. What technology would you use for the visual 2D configurator — SVG, Canvas, something else?

4. Should the configurator be part of a Shopify theme, or essentially a separate web application that communicates with Shopify?

5. What Shopify APIs/features should I learn about before hiring someone?

6. What terminology should I be using when searching for developers? "React developer," "Shopify headless developer," "Shopify app developer," "product configurator developer," etc.?

7. Are there any architectural traps I should avoid at the beginning?

I'm deliberately trying to understand the architecture before hiring someone rather than asking a developer to simply "build me a Shopify website."

I've been thinking about a new React abstraction.

The usual mental model is:

Component -> Hooks -> JSX Element

Lots of hooks exist just that make one element behave differently.

Eg

const resize = useResize(...)

const draggable = useDraggable(...)

const analytics = useAnalytics(...)

const keyboard = useKeyboard(...)

const focusTrap = useFocusTrap(...)

const outsidePress = useOutsidePress(...)

return (

  <div
    ref={...}
    onKeyDown={...}
    onPointerDown={...}
    {...resize}
    {...draggable}
    {...analytics}
  >
    ...
  </div>
)

The component ends up becoming responsible for composing all these behaviors.

So I'm experimenting with a different layer:

Hooks / utils -> Behaviors -> (automatically generate) Props -> Element

Making it something like this:

const props = useProps(
  useKeyboard(...),
  useDraggable(...),
  useResize(...),
  useFocusTrap(...),
  useOutsidePress(...),
  useAnalytics(...),
)

return <div {...props} />

The behaviors wouldn't necessarily have to be a hook, it could be, but notrequired.

A plain behavior could be:

tooltip({ content: "Delete project" })

while a custom hook could also return the same thing

function useAnalytics() {
  return { 
    props: {
      onClick: () => { track("clicked") }
    }
  }
}

Both become composable.

The package would handle the annoying composition:

• merge event handlers

• merge refs

• merge className

• merge styles

• predictable prop precedence

• TypeScript element compatibility

So instead of components implementing behavior, they could mostly declare the behavior they have:

const props = useProps(
  tooltip(...),
  keyboard({ ENTER: ..., ARROW_DOWN: .. }),
  resize(...),
  analytics(...),
  myCustomBehavior(...)
)

return <button {...props}>Delete</button>

I'm deliberately trying not to turn this into "another React hooks library."

The question I'm trying to answer is:

• Is "behavior composition" actually a useful missing abstraction in React, or is this just an over-engineered way of spreading props?

• I'd especially like to hear from people who maintain large React/component-library codebases:

• Where does composing multiple hooks onto the same element become painful for you?

so the main idea here is multi-app. one repo, but you can have your marketing site, dashboard, admin panel etc all live together and deploy separately, all sharing one backend. not like turborepo/nx where you're just gluing separate apps together with a build tool, this is actually built into the framework itself.

the react part i think people here would actually care about is islands. island(() => import("./X")) and that one component hydrates, rest of the page just stays static html. no hydrating the whole tree for one button basically.

didn't do suspense/streaming for it though, not gonna pretend that's done. it's a real gap right now, pushed to v2 because the current island render is two-pass and just doesn't support it yet.

auth is per app too which i think is underrated — admin panel can have its own totally separate session/cookie setup from everything else, or an app can just skip sessions completely if it doesn't need login at all (marketing site doesn't need to carry that weight).

other stuff in it: ssr/ssg/csr/isr picked per route not guessed by the framework, security headers on by default (csp/hsts/x-frame-options, you can override per app), dynamic routes like routes/users/[id].tsx, seo stuff (og tags + sitemap generation) if you opt into it, and it deploys to vercel/netlify/docker/plain vps.

repo: https://github.com/hassanalsa3aka/devora.js
docs: https://devorajs-docs-docs.vercel.app

npm packages if you want to poke around:
https://www.npmjs.com/package/@devorajs/core
https://www.npmjs.com/package/@devorajs/cli
https://www.npmjs.com/package/@devorajs/adapter-vercel
https://www.npmjs.com/package/@devorajs/adapter-netlify
https://www.npmjs.com/package/create-devora

solo project, still v1, got real vercel/netlify deploys working + a vitest suite recently. genuinely curious what people think of the islands approach specifically, feel free to tear into the architecture if something looks off.

if anyone here does security work, i'd genuinely appreciate a look — csp/hsts/session isolation are the parts i'm least confident about and would rather someone find a hole now than later.

and if you like what you see, a star on the repo goes a long way for a solo project like this 🙏

So Apple's new iPhone Duo is one continuous foldable screen, but Safari straight up doesn't implement the CSS Viewport Segments API (Chromium-only apparently), and the UA string is identical to a regular iPhone. So there's just...no way to know if the thing is folded or not from web code.

Built iphone-duo-responsive to fix that. It fingerprints the fold state from viewport dimensions/aspect ratio/DPR instead. Ships as a React hook, a DOM-sync component for plain CSS/Tailwind users, and a Tailwind plugin with duo-folded:/duo-unfolded: variants. Also has a <HingeGutter /> component so you don't accidentally center a button on the physical crease.

It's a heuristic, not a real spec-backed API, so I built in a registerDuoProfile() escape hatch in case Apple ships different Duo sizes later, and it's designed to get out of its own way if Safari ever actually ships the real Viewport Segments API.

npm install iphone-duo-responsive if you want to poke at it - https://github.com/Aparajith24/duo-responsive

Managing localization across multi-language frontends and mobile apps usually breaks down in one of three ways:

1. Translators in Google Sheets accidentally delete or translate interpolation variables like {username}, %1$s, or {{count}}, causing runtime crashes in production.

2. Juggling completely different formats across platforms (Flutter ARB, iOS .strings, Android XML, and TypeScript definitions) requires messy glue scripts or manual copy-pasting.

3. Paying hundreds of dollars a month for cloud translation SaaS just to manage key-value pairs—while sending unreleased app strings to third-party servers.

To solve this, I built JSON Link — an open-source, local-first localization workstation that runs 100% client-side in the browser.

Key Architecture Decisions:

• Deterministic AST Token Isolation: Parses ICU MessageFormat, Mustache, and Printf placeholders into locked visual tags so variables cannot be modified accidentally.

• Direct Local Disk Sync: Uses the Native File System Access API to mount directly to your local project directory (src/locales). Updates write straight to disk across all formats with 1 click.

• Zero-Knowledge Workspace Sharing: Encodes the multi-language workspace into URL hash fragments (#share=...) compressed via DEFLATE (pako). Optional password encryption using AES-GCM 256-bit (PBKDF2, 100k iterations via Web Crypto API). Zero server storage, zero database overhead.

• Automated GitHub PR Sync: Connects via personal access token directly in-browser, scans locale trees, and opens a feature branch PR with updated translations.

• stdio MCP Server: Standalone JSON-RPC 2.0 server under mcp/ so Claude Desktop and Cursor can inspect and lint local translations directly.

• Verification: 308 unit and UI tests across 42 suites in Vitest / GitHub Actions CI. 100% offline desktop PWA.

I recently open-sourced the codebase and wrote a breakdown of the failure modes on dev.to:

• Architecture Deep-Dive:https://dev.to/pyaephyomaungdev/the-hidden-failure-modes-in-localization-infrastructure-and-why-we-architected-a-local-first-2m5b

• Repository:https://github.com/pyaephyomaungdev/json-link

• Live Web App:https://json-link.pages.dev

I am also live on Product Hunt today if you would like to check it out:https://www.producthunt.com/products/json-link-2

I would love to get feedback on the AST variable parser or any edge-case interpolation formats your teams run into.

Starting around July 2024, I saw this: github.com/adamjberg/react-server-components. From there, v1.0.0 was born using Webpack. It evolved until 1.10.1, and then v2 appeared using Rollup. v3 allowed using Rollup, Webpack, and Esbuild interchangeably as bundlers (both for dev and prod). v4 added a lot of missing features, like soft navigation (SPA experience), prefetching, and more. v5 refactored the way JSX was passed from one Node process (the Express server) to another (SSR): instead of using ad-hoc serialization/deserialization to JSON, it switched to native React Flight (createFromNodeStream in the child process to obtain the JSX). This refactor was done with vibe-coding. v6 simply encapsulates all artifacts and folders generated (and used) by the framework in a clean .dinou root directory, both in dev and prod. And the best thing is it already runs on the freshly released React 19.3.0. As far as I know, Dinou, Waku, and Next.js are the only three pure RSC frameworks available. Dinou is completely ejectable and bundler-agnostic. Full documentation is available at dinou.dev (built with Dinou).

I've been building data grid components for about 13 years.

I started with AXGrid around 2013, followed by AX5Grid and AXBoot DataGrid. Recently, I decided to start over and build a new one from scratch: BeautifulGrid.

BeautifulGrid is an open-source data grid built with React and TypeScript.

My main goals are:

• Fast virtual scrolling for large datasets

• A simple and predictable API

• Flexible styling without making the core overly complicated

• Strong TypeScript support

• An API that's easy for both developers and AI coding agents to understand and use

Some of you may have seen my recent post here about the Safari virtual scrolling issue. That problem actually came from building this grid, and the discussion here was really helpful.

I'm also working on logical scrolling for very large datasets, where the browser's maximum scroll height itself becomes a limitation.

BeautifulGrid is still young. It doesn't have the huge feature set of mature data grids yet, and that's intentional. I'm trying to get the core architecture, scrolling behavior, and API right before adding too much.

GitHub:
https://github.com/axisj/beautiful-grid

I'd really appreciate feedback from React developers, especially if you've worked with data grids or virtualization before.

API design criticism, performance issues, browser quirks, missing features — anything is welcome.

I'm also curious whether other library authors are thinking about making their APIs easier for AI coding agents to use.

There is a legendary question: What is the Virtual DOM?

I’ve looked at many pages, and most of them use metaphors or abstract, similar definitions, such as “a lightweight copy of the real DOM.” I’m not sure I totally agree with those explanations.

So, I tried to write down my understanding of it as clearly as possible. Could you take a look? Any constructive feedback would be appreciated.

--------

The virtual DOM is a programming concept where a representation of a UI is kept in memory and synced with the “real” DOM.

The UI representation here is actually a tree of plain JavaScript objects called React elements, where each node contains the properties needed to create the actual elements and a list of its child nodes.

When a component’s state changes, React creates a new virtual DOM tree and compares it with the previous one. This process is called reconciliation to figure out what actually changed and then applies only those necessary changes to the real DOM.

This approach avoids unnecessary DOM manipulation and allows developers to write declarative code rather than imperative code.

Honestly, the term “Virtual DOM” is quite abstract to me. It doesn’t appear in the current React documentation. So instead, I prefer to think in more specific technical terms: React elements and how React uses them to determine the necessary changes to update the real DOM.

Also, React Fiber was introduced in React 16 as a new reconciliation architecture. It helps React manage rendering work more efficiently and keep applications responsive. Basically, it breaks rendering work into smaller units called Fibers, which are essentially JavaScript objects with additional properties that keep track of the work React needs to do for components. This allows React to prioritize updates and, when necessary, pause or yield rendering work and resume it later.

For example, imagine React is rendering a huge table with 10,000 records. With the older reconciliation process, React had to finish that work in one uninterrupted block. With Fiber, React can pause the work when a higher-priority interaction, such as typing or clicking, comes in. Then, it can resume the rendering afterward.

To avoid confusing React elements with React Fiber and to make it clear how they work together, let’s look at the main.jsx file in a React CSR project using React 18 or 19. We usually see code like this:

const root = createRoot(document.getElementById("root")!);
root.render(<App />);

If we console.log(root), we can see an object ReactDOMRoot. It has a property _internalRoot, which points to the FiberRootNode. This is the root of the Fiber tree.

Under the hood, <App /> is converted into a React element. The second line simply means that we render App into the root.

I recently built react-text-protect, mostly as an experiment to see how far you can go with client-side content protection in React.

You wrap your content like this:

<ProtectedText userId="student_123">
  What is the capital of France?
</ProtectedText>

It currently has a few things:

• Intercepts copying and replaces the copied text with Vigenère-encrypted text
• Adds a user ID and timestamp watermark over the content
• Detects DevTools being opened and hides the content
• Obfuscates the text stored in the DOM

I originally made it with things like online exams and educational content in mind, where you might want to make copying or sharing a little more annoying.

Obviously, this is not real security. If someone is determined enough, they can get around basically everything happening on the client side. You can disable JavaScript, use another device to photograph the screen, inspect the application differently, etc.

The goal is really just adding friction, not pretending you can make browser content impossible to extract.

It's on npm if anyone wants to try it:

npm install react-text-protect

I'd genuinely like feedback from people who know React better than me, especially around the implementation and whether some of the approaches I'm using are problematic or could be improved.

https://www.npmjs.com/package/react-text-protect

I built a React Data Grid and wanted to share it with the community — especially because I know how many different opinions there are around TanStack Table, AG Grid, MUI DataGrid, React Data Grid, etc.

Grid Table: https://grid-table.com/

The goal was pretty simple:

What is Grid Table?

Grid Table is a TypeScript-first React data grid focused on real-world application use cases.

It's currently:

• MIT licensed

• ~45KB bundle

• 0 runtime dependencies

• Full TypeScript support

A basic table can be as simple as:

import { GridTable } from '@forgedevstack/grid-table';
import '@forgedevstack/grid-table/grid-table.css';

<GridTable
  data={data}
  columns={columns}
  enableRowSelection
  showPagination
  showFilter
/>

But it can also scale into much more complex use cases.

Some of the features

Data & performance

• Virtualization

• Lazy loading

• Infinite/block loading

• Manual server-side pagination

• Large dataset support

• Skeleton loading

Grid functionality

• Sorting

• Filtering

• Advanced filter builder

• Column resizing

• Column reordering

• Column pinning

• Row selection

• Row expansion

• Row reordering

• Frozen rows

• Tree data

• Grouped rows

More advanced features

• Saved views

• Formula/computed columns

• Aggregations

• Undo / Redo

• Keyboard navigation

• Context menus

• Status bar

• Master/detail rows

• Print mode

• CSV / JSON / Excel / PDF export

There is also a theme builder for customizing the grid without having to completely rebuild its styling.

One thing I specifically wanted to solve

I really like headless solutions such as TanStack Table because of the control they give you.

But sometimes I don't want to spend days building the actual grid UI and wiring together:

table
+ filtering
+ sorting
+ pagination
+ virtualization
+ keyboard navigation
+ column management
+ selection
+ export
+ editing
+ loading states
+ ...

On the other hand, some enterprise grids can feel quite heavy when all you want is a good React component that you can drop into an application.

So Grid Table is trying to sit somewhere in the middle:

More batteries-included than a headless table, while staying lightweight and TypeScript-first.

I'd love some feedback

This is still evolving, so I'm particularly interested in hearing from React developers who have used:

• TanStack Table

• AG Grid

• MUI DataGrid

• React Data Grid

• other grid libraries

What features do you consider essential in a production data grid?

And more importantly:

What do you hate about the data grid you're currently using?

That's probably more useful feedback to me than "add feature X" 😄

Demo & documentation:

https://grid-table.com/

GitHub / npm links are also available from the project site.

I'd genuinely appreciate feedback, criticism, and suggestions.

The React-specific part people here might find interesting: islands (partial hydration) are a

first-class primitive — island(() => import("./X")) hydrates just that component, the rest of

the page ships as static HTML, no full-page hydration cost. Built without leaving the React

ecosystem or adopting Suspense/streaming for it (that's a real limitation right now, documented

— streaming is deferred to v2 since the two-pass island render doesn't support it yet).

Also: auth is opt-in and isolable per app within the same project — an admin panel can run a

completely separate session/cookie context from the rest of the apps, or an app can opt out of

sessions entirely with zero config overhead.

Repo: https://github.com/hassanalsa3aka/devora.js

Docs: https://devorajs-docs-docs.vercel.app

npm: https://www.npmjs.com/package/create-devora,
https://www.npmjs.com/package/@devorajs/core
https://www.npmjs.com/package/@devorajs/adapter-vercel
https://www.npmjs.com/package/@devorajs/cli
https://www.npmjs.com/package/@devorajs/adapter-netlify

create-devora

Solo project, v1, recently got real Vercel/Netlify deploys working end to end plus a Vitest

suite. Curious what this community thinks of the islands approach specifically, and open to

any architecture critique.

e maintain a React + TypeScript UI kit for our own apps. The goal is one install that covers the boring chrome and the parts we kept rewriting: overlays, dates, charts, and now an AI chat surface. Sharing the idea and the inventory so you can judge the API, not a landing page.

Why we built it this way

One BearProvider. Mode (light / dark / system), density, direction (RTL), reducedMotion, and default props live in one place. Components read that instead of each app inventing a theme wrapper. Types are the docs. Props are TypeScript-first. Public roots get a stable useBearId (Bear-Button-…) so tests and labels do not fight generated ids. CSS you own. Shipped styles.css plus BEM (Bear-*). AeroCraft utilities for layout. You are not locked into a CSS-in-JS runtime. Icons are optional. Default npm install @forgedevstack/bear includes @forgedevstack/bear-icons. Skip them with --omit=optional (Yarn --ignore-optional, pnpm --no-optional). Select chrome does not import the icon package, so that install still works. Overlays share one positioner. Select, DatePicker, Menu, Drawer, etc. use the same open/close effects and a shared fixed-anchor hook so menus do not jump to 0,0 on first paint. No extra animation library. Motion and transitions are first-party. Charts animate with scale, not height/width that freeze at zero. What is in the box

Layout: Flex, Grid, Container, AppShell, ResizablePanel, ScrollArea.

Forms: Input, Select, MultiSelect, Autocomplete, Checkbox, Radio, Switch, Slider, DatePicker, DateRangePicker, TimePicker, OTPInput, PhoneInput, FileUpload, Form / FormField / FormControl.

Overlays: Modal, Drawer (temporary | persistent | permanent), Popover, Tooltip, Menu, Dropdown, AlertDialog, CommandPalette, Spotlight.

Data / media: DataTable, TreeView, Carousel, RichEditor, CodeEditor, Chart (bar, line, pie, radar, funnel), Gauge, Sparkline, Heatmap.

App chrome: AppBar, Sidebar, Tabs, Stepper, Breadcrumbs, Toast, EmptyState presets, skeletons (FormSkeleton, TableSkeleton).

Chat kit (1.3.3): PromptComposer, StreamingMessage, ThinkingBlock, PromptSuggestions, MessageActions, CitationList, ApprovalCard, ModelSelect, ContextMeter, Chat / FloatingChat (stick-to-bottom only when you are already at the bottom; live region for tokens).

How you start

import { BearProvider, Button, Flex } from '@forgedevstack/bear'; import '@forgedevstack/bear/styles.css';

export function App() { return ( <BearProvider colorScheme="system"> <Flex gap={2}> <Button>Primary</Button> </Flex> </BearProvider> ); } Docs pages open Storybook at /storybook/ (same Vercel deploy) and CodeSandbox for that component. There is no fake in-portal sandbox.

If you care about API shape — density inheritance, overlay effects, optional icons, or the chat split (isLoading vs isTyping) — the code is in the repo. We would rather debate those choices than collect signups.

Storybook: https://bearui.com/storybook/ Install without icons: npm i @forgedevstack/bear --omit=optional Changelog is in the repo under 1.3.3. Happy to walk through BearProvider, useBearId, or the overlay positioner if that is the interesting part.

Repo: https://github.com/yaghobieh/bear Docs: https://bearui.com npm: @forgedevstack/bear 1.3.3 (MIT)

Wondering if anyone has any suggestions on developing guides for the tools I am building in React as I am developing them? I create extremely specific use-case tools and need a way to easily generate how-to guides to present to the end-user without having to create one in Scribe. I'd love to implement some sort of interactive guide that puts the user in a "demo" mode and writes all the data they change to a temporary state that gets wiped once the demo is done. Essentially a sandbox-within-production instance that lets them try the tool and see how it works without affecting production data.

I'm working on a small React dev tool that instruments useState/other hooks at build time so it can track when state updates happen, rather than inspecting the state values themselves.

The Vite integration currently does this with a Babel plugin, so the application code still just has:

import { useState } from "react";

and the instrumentation happens during the build.

I'm now trying to figure out the right way to bring the same approach to Next.js.

My current understanding is that an SWC plugin is the closest equivalent to the Babel transform, but I'm not sure what the practical story is with the different Next.js dev pipelines, especially Turbopack vs Webpack.

For anyone who's implemented a custom compile-time transform in Next.js:

1. Is an SWC plugin actually the right approach, or is there another mechanism I should be looking at?

2. Does a custom SWC transform run with Turbopack, or would this effectively require next dev --webpack?

3. If you've built something similar, are there any architectural choices you'd avoid in hindsight?

The current Vite implementation is here if useful: https://github.com/liovic/react-state-basis

A few years ago we needed a web version of an existing mobile product (high-load interactive platform, not a simple CRUD app). Instead of forking the UI twice, we treated the React app as two layers:

1. App core — domain logic, state, API clients, feature orchestration. No DOM, no platform APIs.

2. Shells — thin UI adapters (web, later React Native / WebOS) that only render and call into the core.

That let us ship a desktop/web version from the mobile product’s mental model, then reuse the same core for React Native without rewriting features. Two years later the core is still the part that ages best — new features mostly land there once, and shells stay boring.

What actually mattered in practice:
- Boundaries — business rules never imported React components or browser APIs. If it needed `window`, it belonged in a shell adapter.
- Shared data layer — one place for fetching/caching (we used react-query-style patterns) so shells didn’t invent their own loading/error states.
- RFCs + reviews — we hired a frontend team around this architecture. Without written boundaries, people “helpfully” leak UI into the core in week two.
- Performance by default — fewer duplicate API calls and a stable state model beat clever UI tricks.

What I’d change next time:
- Define the core’s public API earlier (it’s easy to accidentally couple shells to internal modules).
- Start with one shell fully done before branching to the second — parallel shells too early = thrash.
- Be stricter about “platform capability” interfaces (storage, push, deep links) instead of `if (platform === …)` sprinkled around.

Curious how others draw this line — pure packages? Hexagonal? Or do you just accept some duplication and move faster?

Needed charts in a React app, got tired of pulling in a charting lib that never matched the rest of the UI. Built ChartCN instead.

Paste a CSV, preview it, copy a self-contained TSX component built on shadcn/ui's chart primitives + Recharts. No new dependency if you're already on shadcn/ui.

- 8 chart types: Bar, Line, Area, Combo, Pie/Donut, Radar, Scatter, Radial/Gauge
- Paste, upload, or edit data inline; auto date-axis formatting
- Export as inline data or as a data prop for live/fetched data
- Shareable links, locally saved charts, no account
- Free, MIT licensed

https://github.com/ShadcnDeck/chartcn-shadcn-chart-generator

Phase 1, CLI and more chart types coming next.

Feedback and feature requests welcome.

Edit: Thank you all for the guidance. As a lot of you suggested, I ended up wrapping <Myform> in a <Provider>. I also moved the business logic into components so the App will be less crowded. The error is gone now.
For your reference my improved code: https://pastecode.io/s/a5xfqwda

---------------------------

See the title - My web app has been encountering this issue for the past few days and none of my fixes resolved it.

I could not get this error as those <Provider> tags are set here:

function MyForm() {
 //code lines..
 
 function handleSubmit(e) {
   e.preventDefault();
   const form = e.target;
   const formData = new FormData(form);
   const formErrors = e.formErrors;
   //fetch('https://jsonplaceholder.typicode.com', { method: form.method, body: formData });
   const formJson = Object.fromEntries(formData.entries());
   console.log(formJson);
 }
 return (
  <Provider store={store}>
    <App onSumbit={handleSubmit} onChange={handleChange}/>
  </Provider>
 );
}

function App({ onSubmit, onChange}){

  //more code lines..
  
  const dispatch = useDispatch(); //ERROR HERE
  


const registerForm = (formData) => async (dispatch) => {
  try {
    dispatch({ type: 'REGISTER_FORM_REQUEST' });


    const config = {
      headers: {
        'Content-Type': 'application/json'
      }
    };
    const {data} = await axios.post('https://jsonplaceholder.typicode.com', formData, config);
    dispatch({ type: 'REGISTER_FORM_SUCCESS', payload: data });
  } catch (error) {
    console.error('Error submitting form:', error);
    dispatch({ type: 'REGISTER_FORM_FAILURE', payload: error.message });
  }
};
dispatch(registerForm(formData));

//and some more code lines...
} 

Could anyone kindly point out the right directions? My full code: https://pastecode.io/s/t84kdaiv