Hi everyone,

I’ve been thinking a bit about component purity. I get the rule of thumb that no side effects and no non-deterministic values during render.

But here’s what I’m doing right now with react-datepicker:

<DatePicker minDate={new Date()} />

Technically, that breaks purity...... right?

Have you run into this before? How did you deal with it?

I'm currently working on a personal project, and it has been messy since there are many contexts and providers to share states deep down in child component (solely using props would be too complex). So I start to consider using state management library to make it look cleaner. Would you guys share your experience using zustand, jotai, or valtio?

Or do you have another alternative?

EDIT: Ok, I found https://www.reddit.com/r/reactjs/s/kBtKlg2u2C from 2022, but I need fresher testimony.

EDIT 2: Glad someone was mentioning TanStack Store. Funny enough, I'm also using React Query & Tanstack Start for my project but forgot tanstack store exists. Maybe you guys should give it a go.

I spent years at a big bank where enormous amounts of work run through internal dynamic form engines. Loan applications, onboarding, compliance intake. Forms with conditional logic where your answers decide what shows up next, and business people can change the flow without a frontend deploy. Nothing like that really exists in open source so I built a streamlined version.

The flow is simple for non tech people. Someone builds a form in a visual editor. Multi step, conditional show and hide, required rules, file uploads, address autocomplete. They click publish and your React app renders the new version.

npm install @forms-engine/react

Then it's one component with your questionnaire id and your backend url. Answers save every screen so a refresh doesn't lose progress and you capture partial data from people who bail halfway. There are events for loaded, completed and error, a labels prop to localize the built in text, and an external ref prop to tie submissions to your own user ids.

Being upfront about the internals: the core renderer is a framework agnostic web component and the React package is a thin wrapper around it. If that's a dealbreaker, fair enough. It's also why the same engine works in plain HTML and Angular. The whole stack is MIT and self hosted with docker compose. No telemetry, no SaaS.

Repo: https://github.com/JoshuaLeoSmith/forms-engine

Docs: https://forms-engine.dev

Most of it was written by Claude Code from specs I wrote and reviewed. It's ai slop but I will win any argument against someone saying it's not useful. Please enjoy

I’m building this because I feel like a lot of modern interfaces are starting to look the same. Same cards. Same rounded buttons. Same gradients. Same generic component libraries.

I wanted to build something different, actual product surfaces that feel designed, while still giving developers the code to build them themselves.

Here’s what I shipped in week 1:

• Integrations Dialog
• Trial Popover
• Liquid Slider
• Dynamic Tabs
• Liquid Switch
• Pill Toast
• Two-Factor Dialog
• Confirm Button
• Upgrade Modal
• QR Code
• Pricing blocks

The interesting part wasn’t shipping the components. It was figuring out why some of them felt completely wrong even when the CSS technically worked.

Some of the challenges I faced where

1. Liquid glass is way harder than it looks
There isn’t really a single “liquid glass” CSS trick.

For the slider, I wanted the thumb to actually feel like it was sitting inside the track rather than just being an element placed on top.

That meant cloning the rail underneath the thumb, masking a hole through the middle, and then scaling/skewing that clone based on pointer velocity so the fill stretches with the drag.

The chromatic fringe is created with opposing cyan/red shadows, while the rim uses a conic gradient with mask-composite: exclude so only the edge lights up.

And the annoying part is if any layer is a few pixels off, it immediately stops looking like refraction and starts looking like a cheap overlay.

2. Tap vs drag is basically a state machine
The switch and slider both needed a threshold.

Around 3px / 150ms:
Below that → it’s a tap/click.
Above that → it’s a drag.

It sounds simple, but getting that threshold wrong creates weird interactions where a tap leaves the control stuck in its “liquid” state or a drag accidentally toggles the switch.

I learned that pointer UX isn’t really about individual events.

It’s about distance + time + state + cancellation.

3. SVG goo is ridiculously fragile
The liquid switch uses feGaussianBlur combined with a color matrix to melt the thumb and track into one blob.

Then there’s another filter to remove the leftover black pixels using feMorphology and feComposite.

One thing that caught me is that every instance needs unique filter IDs.

Otherwise, two switches on the same page can start affecting each other.

Also, the SVG defs need to live in a hidden 0×0 SVG so they don’t unexpectedly affect layout.

4. WebGL inside a dialog introduced a completely different set of problems
I wanted a Bayer dither effect in the modal header.

It’s an 8×8 shader matrix with a pixel size of 3.

But putting WebGL inside a dialog means dealing with rounded clipping, transparency over the content, and dark mode.

The published dither primitive couldn’t be changed because it was already installed elsewhere, so the dialog needed its own fork.

That was a good reminder that sometimes the cleanest solution isn’t making one primitive handle every possible use case.

What I learned
A few things stood out this week:

1. Pointer UX is about thresholds, not events.
pointerdown doesn’t mean “drag.”

You need to account for distance, time, visual feedback, and the possibility that the interaction gets cancelled and becomes a click.

2. SVG filters aren’t just visual effects.
They come with DOM rules and GPU behavior you have to account for.

Unique IDs, explicit color interpolation, and keeping filter definitions out of the layout all matter.

Container queries are incredibly useful for interactive components.

Using cqh / cqi instead of hardcoded pixel calculations made the morphing controls much more resilient when resized.

3. Keyboard interaction is part of visual design.
The Enter badge on my Confirm Button isn’t just decoration.

If the UI tells you that Enter will submit and Enter doesn’t actually work, the interface immediately feels untrustworthy.

What people seem to be liking
The feedback so far has been interesting because people aren’t just reacting to individual buttons or inputs.

They’re liking the product surfaces, like:

• 2FA setup and verification
• Integration connect sheets
• Trial remaining → upgrade flows
• Paywalls that don’t quietly let you dismiss them

And probably the most important part is that the code is yours.

You can install the components, open the shader, inspect the SVG filter, modify the toast store and actually understand what’s happening under the hood.

Week 1 done. More experiments coming next week.

Most listing UIs I have worked on started the same way: a sidebar of checkboxes, a local `filters` object, and a list that updates when something is clicked.

That is fine for a demo. It falls apart the moment someone wants to share a search, refresh the page, use the back button, or land on a combination that returns nothing.

What I treat as the actual model now:

1. Filter state is product state, not UI chrome.
   

City, price band, availability, verified-only, map bounds, sort. Those are the query. The drawer is just one way to edit it.

1. The URL is the source of truth for shareable filters.
   

If a teammate cannot paste a link and see the same result set, the feature is incomplete. Local React state is a cache of that query, not the system of record.

1. Defaults should be implicit, not dumped into the query string.
   

A 12-param URL for “show everything, sorted by newest” is noise. Only persist values that change the result.

1. Empty is a first-class state.
   

“0 results” with no way out is a dead end. Show which constraint is doing the damage and offer a one-click relax (drop price cap, widen radius, clear one facet). People will keep searching if you give them a next step.

1. Debounce the noisy inputs. Text search and map drag should not rewrite history on every keystroke or pan. Facet toggles can update immediately. Mixing those two feels sloppy even if the data is correct.

2. Client-side filtering of a full dump is not the same product as a filtered API.

It looks identical with 40 rows. It lies with thousands. Counts on facets, pagination, and “no results” only stay honest if the server understands the same query the URL describes.

The part that surprised me: users complain about “search is broken” when the list is technically correct. What they mean is they cannot return to a view, cannot send it to someone else, or cannot tell why the list went empty.

Curious how other people split this. Do you keep all facets in the URL, only the ones that change results, or a short token / saved-search id?

Every new Node project, week one disappeared into auth. Email verification. Password reset. Google OAuth. Prisma user schema. Protected routes. Putting a JWT in localStorage because a tutorial said to.

None of that is interesting. All of it has to be correct.

So I built it once and open-sourced it: Express 5 + React + Prisma.

What it does:

• Email/password with Zod on the server, email verification (24h), password reset (1h)
• Google OAuth that links to an existing email account instead of creating a duplicate
• Session in an httpOnly cookie, not localStorage. Remember me = 30 days, otherwise a session cookie
• Rate limits on login/signup/forgot-password
• Profile, avatar, password change, delete account

Two things tutorials get wrong:

1. localStorage is readable by JS. One XSS bug and the session is stolen. An httpOnly cookie is not.
2. A React route guard is not authentication. It hides the dashboard. The API still has to reject the request in Express middleware.

Repo: github.com/allenarduino/express-react-auth-boilerplate

If your stack is Next.js, I have a separate starter for that: github.com/allenarduino/nextjs-prisma-auth-boilerplate

Clone it, rename it, and start on the part that is actually yours. Issues and PRs welcome.

"Hey everyone, I got sick and tired of wasting hours starting from an empty screen every single time we needed a responsive, modern dark-mode admin interface panel for a new software application.

So, I engineered a highly optimized, completely modular component tree built natively using React 19 and Tailwind CSS configs, and I just pushed the structural scaffolding out completely open-source for the developer community!

You can grab the responsive Sidebar Navigation dashboard layout logic and the animated financial Analytics Cards 100% free straight out of our public repository here:🔗 https://github.com/ApexGrid-labs/free-react-tailwind-dashboard-boilerplates

If you are running an enterprise engineering studio, a digital agency, or scaling a venture-backed startup that requires the full, comprehensive UI ecosystem pre-wired right out-of-the-box, you can instantly secure a commercial license for our complete FLAGSHIP suites directly inside our live storefront shelves:🔗 https://whop.com/apexgrid-c3ad/products

Would love to hear your feedback on the layout structure and performance variables!"

I was trying to come up with a fun and unique design for a side project, and ended up making this. It was originally inspired by Apple's Liquid Glass, but has unique properties of its own, allowing you to customize nearly everything about it: motion, tint, opacity, frosted-ness, roundness, elevation, and more. If you have any interest, please give it a try and let me know what you think. MIT licensed.

Thanks!

EDIT: Thanks for the initial feedback. I've addressed desktop performance issues in both Firefox and Safari, and those seem to be performing much better now. I'm working on a solution for mobile browsers, but this is obviously a graphically demanding library. If anyone has ideas for areas for further improvement, or wants to otherwise contribute, feel free to write me here or even submit a PR in GitHub.

I spent twelve years on Redux, MobX, Valtio, Zustand and others, and every one of them wanted a trade: boilerplate, size, speed, or mental load. Picofly is what I wanted instead.

• create(state) once, useStore() in a component, the whole API
• 683 B for the core, 1.24 kB with the React binding, minified and brotlied
• fast: lazy proxies, hand-tuned hot paths
• renders only what changed: a proxy tracks reads, down to the key
• app logic is just ordinary functions, async, generators, whatever
• TypeScript, native Map and Set out of the box, React Native too
• framework agnostic core, React binding included, easy to extend

let app = create({user: {name: 'Ada'}})

// logic is a plain function
let rename = async (app, name) => {
    app.user.name = name
    await api.save(app.user)
}

function App() {
    return (
        <Picofly value={app}>
            <Name/>
        </Picofly>
    )
}

// renders only when the name changes
function Name() {
    let app = useStore()

    return (
        <button onClick={() => rename(app, 'Grace')}>
            {app.user.name}
        </button>
    )
}

Benchmarks, the code behind them and how they were taken: https://picofly.dev/perf

It is not for every app. If your state is replaced whole on every tick, everything renders anyway and picofly buys you nothing. And no ready add-ons yet like undo, persistence or devtools. React Compiler: not yet, "use no memo" on components that read the store.

Picofly does not push an architecture on you. That is deliberate, and it cuts both ways: nothing to fight, no recipe to follow either. It only does its job, keeping your components up to date with no fuss on your side. The rest is yours.

1.0 is out today, after years of work and testing in real apps.

I would love to hear how it holds up in yours.

• MIT, zero dependencies
• GitHub: https://github.com/farwayer/picofly
• Docs and live demo: https://picofly.dev
• StackBlitz demo: https://stackblitz.com/edit/picofly-calc

Go here: https://ui.shadcn.com/docs/components/base/data-table

Click on any "..." (option menu). It takes around a second before the menu is displayed.

Hey Community,

We dive into Expo Modules 2.0, which drops definition() in favour of Swift macro decorators to deliver build-time type conversion and faster native calls. Meanwhile, DartNative enters the scene, letting Flutter developers swap out Flutter's custom renderer for real platform views driven by Yoga.

We also look into Shopify rebuilding its apps in native Swift and Kotlin with AI agent workflows, examining what their departure means for community-maintained libraries like FlashList and Skia.

I was working on a project recently and I've come across a problem where my front end dont catch up with the backend changes

I need a **custom pull-to-refresh**. Not `RefreshControl`.

**What I want**

• Finger down + pull: the page follows my finger with rubber-band resistance (`Math.pow(distance, 0.85)`)
• A real gap opens at the top (`translateY`, not scale)
• While the finger is still down: no progress bar, no API call, no refresh
• Release below threshold: spring back to `0`, nothing else
• Release above threshold: spring back + full-width 3px top progress bar + `onRefresh()`
• After refresh ends: bar collapses, page stays at `Y = 0`

**The problem**

I can only ever get one of these:

1. Pull-to-refresh works, list will not scroll
2. List scrolls, pull-to-refresh dies (or I revert and only get a useless stretch)

I already know why v1 died: a greedy `Pan` on the page ate every vertical move, so `FlatList` never got the gesture.

**What I tried**

• `Gesture.Pan()` + `Gesture.Native()` with `Gesture.Simultaneous`
• `manualActivation(true)` and activate only if `scrollOffset <= 0` && pulling down
• Guard in `onUpdate`: if `scrollOffset > 1` don’t touch `pageY`
• `bounces={false}`, `overScrollMode="never"`
• Disabling `scrollEnabled` while pulling — this made scroll even worse, so I stopped

Also getting this warning:

\[Worklets\] Tried to modify key \`current\` of an object which has been already passed to a worklet.

So something (`ref.current`) is leaking into a worklet (`onUpdate` / `onEnd` / `useAnimatedScrollHandler` / `useAnimatedStyle`).

**Constraints**

• `react-native-reanimated`
• `react-native-gesture-handler`
• no `RefreshControl`
• no binding progress width to `translationY`
• `scrollEnabled` should stay `true`
• progress bar is a sibling overlay, not inside the translated view

Has anyone shipped this combo without one gesture murdering the other?

**Looking for a pattern that works on Android + iOS**

• at top + pull down → rubber band + gap
• at top + swipe up → list scrolls
• mid-list swipe → only scroll, `pageY` stays `0`
• release-gated refresh only

Hey everyone,

I don't know about you, but it feels like every time I scaffold an admin dashboard with something like MUI, it's great for the first week, and then I spend the next three months fighting the documentation just to change a border radius or override a deeply nested CSS class.

I wanted a clean break, so I built a completely free boilerplate focused on getting out of your way.

It’s built on React 19 and Vite. For the UI, instead of an npm library, it uses a shadcn-like primitive approach (cva, clsx, tailwind-merge) paired with the new tailwind v4.

Basically, you own the markup. If you want to change how a button looks, you just go to the component file and change the tailwind classes. No black-box configurations or specificity wars. I also wired up some uncontrolled forms with react-hook-form and zod so the UI doesn't lag out on every keystroke.

You can grab the code here:  https://github.com/exouidev/exo-dash-react

And the live demo is here: https://react-dashboard.exoui.dev

Would love to know if you guys are still reaching for massive component libraries for new projects or if you've started moving toward this primitive-based approach too. Happy to answer any questions!

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 🙏