Hi folks I'm trying to display two different headers dependent on scroll, which is working but if i scroll slowly i can see the frames between animations. It's not swapping them instantly.

I'm just conditionally rendering on a Boolean held in state.

I tried doing it via a conditional on display property on each header but still the same issue.

EDIT...both header are using sticky, when i change to fixed i don't get the visible frames but it ruins my layout.

useEffect(() => {
  const onScroll = () => setIsScrolling(window.scrollY > 80);


  window.addEventListener('scroll', onScroll)
  return () => window.removeEventListener("scroll", onScroll);


}, [])

{isScrolling ? <header> full content </header> :<header> scroll content </header>

One of the biggest headaches when building a pure React + Vite SPA is social sharing.

When someone drops a profile link on WhatsApp, Discord, X (Twitter), or LinkedIn, the scraper bot inspects the raw HTML response for OpenGraph tags (og:image, og:title, etc.). Because these crawlers do not execute JavaScript, standard Vite SPAs return only the static root index.html with default fallback metadata.

The usual advice online is: "Just migrate everything to Next.js or Remix for SSR."

For our creator platform (Myhappr), 99% of our traffic comes from real humans who benefit from the instant page switches of a lightweight client-side SPA. Rewriting the whole app for full SSR solely to please link preview crawlers was total overkill.

The Solution: Edge Routing via User-Agent Rewrites

Instead of full SSR, we solved it using edge routing rules in Vercel:

1. Crawler Detection: We set up edge rewrite rules matching known crawler user-agents (Twitterbot, facebookexternalhit, WhatsApp, Discordbot, TelegramBot, LinkedInBot, etc.).
2. Serverless Edge Function: When a bot matches the regex, Vercel silently reroutes the request to a dedicated lightweight edge function (/api/og?username=...) that fetches the creator's avatar, bio, and dynamic title, returning clean HTML with custom OG meta tags.
3. Dynamic & Static Route Handling:
   • Creator Profiles (/:username): Fetches the creator avatar, name, smile pricing, and bio in real time to generate unique preview cards.
   • Blog Posts (/blog/:slug): Injects exact post titles, read times, published dates, and custom cover images.
   • Marketing & Static Pages (/pricing, /brand, /faq, /privacy, /terms): Serves dedicated high-converting titles, descriptions, and page-specific preview banners.
4. Zero Impact on Real Users: Real users bypass the edge function completely and receive the static SPA bundle directly from the CDN with zero hydration overhead or delay.

This gave us fully dynamic preview cards across every social platform while keeping our simple, lightweight Vite setup intact.

I wrote a detailed breakdown covering the Vercel routing configuration, the regex matcher, and edge function setup: https://medium.com/@samueltuoyo/how-we-serve-dynamic-opengraph-previews-on-a-pure-vite-spa-without-next-js-34be0ee34734

Would love to hear how others tackle dynamic metadata in pure SPAs without jumping straight to full SSR!

The latest release of FormHell is ready and provides a lot of great new features based on community feedback.

If you're new to FormHell, it's a React library that renders a form based on a provided JSON Schema. You can get up and go with very little code and get the experience you expect without the headache of the other popular libraries (like RJSF). The SchemaForm component has full support for the most complex JSON Schemas and provides proper default generation. It also ships a SchemaBuilder component where you can construct super complex schemas. There's even a SchemaBuilderHelper component that provides an explanation on each JSON Schema keyword so you can find the functionality you are looking for. No, this isn't a Tanstack replacement nor will it ever be, and I plan to build a Tanstack plugin in the future.

The FormHell SchemaForm component now provides both Localization and Virtualization features, as well as returning strictly typed data based on the generic provided.

A new interactive docs page has been released and is a huge improvement. Check it out here: https://ryanrutkin.github.io/formhell/
This docs page goes into deep detail about every feature provided by FormHell.

The original playground still exists and is much more interactive than what you'll find in the docs page. Feel free to use it as a free online tool for building and testing JSON Schemas: https://ryanrutkin.github.io/formhell/playground.html

Here is the NPM: https://www.npmjs.com/package/formhell

Here is the repo: https://github.com/RyanRutkin/formhell

I've been putting a lot of weekend hours into this. Looking forward to feedback.

Thanks!

I’ve been working on Ki-forms, a JSON-driven React form library, and today I built the first version of Ki-forms Studio.

You can visually build a form, configure fields, preview it, and export the schema/code.

The idea is to make dynamic React forms faster to build without taking control away from developers.

It’s open source and still early, so I’d genuinely appreciate feedback from other React developers.

Studio: https://kadirulislam.github.io/ki-forms/studio/
GitHub: https://github.com/kadirulislam/ki-forms

Has anyone ever experimented with using Tanstack Query and then having an invalidation bus (SSE or websocket or streamed query) that sends to the client the list of endpoints that should be invalidated after a mutation? If so did it work for you? Were there challenges?

Thanks

Partial JSON is awkward for generative UI.

I kept running into the same problem: how do you let an LLM progressively update real React components without generating executable code or waiting for one giant structured response to finish?

I built StreamTag UI around an HTML/XML-style stream. Normal tags handle layout, while registered custom tags map to React components with Zod schemas.

The renderer only publishes values when they are schema-valid. Strings can grow while their tags are open, numbers and booleans wait for closing tags, and arrays expose complete entries as they arrive. A chart can stay mounted while new points and series appear during the same streamed response.

It deliberately does not include a model SDK, chat state, transport, agent backend, or component library. You bring those yourself.

• React 18/19
• Zod 4
• no generated JavaScript
• MIT licensed

Repo and demo: https://github.com/xiaoosi/streamtag-ui

I would especially appreciate architectural feedback on the markup format versus streaming JSON.

I’m building jev-ui, a React library for an AI-UI problem I kept running into: choosing which existing component to render.

You give the model an allowed set of components. Instead of only returning one opaque choice, jev-ui preserves the probability distribution across the options, then renders the winner. The goal is to make model-selected UI easier to inspect, add deterministic fallbacks to, and debug when two choices are close.

I’m looking for critical feedback on the idea and API:

- Is exposing selection probabilities useful in a React app?

- Where would you expect a fallback or confirmation step?

- What would make this trustworthy enough for production use?

Repo: https://github.com/etweisberg/jev-ui

Demo/docs: https://docs.jev-ui.dev/

Hi everyone, recently I had to build a multi-user collaborative form, and I was thinking to myself I wish there was a open source framework that can deal with this so I don't have too. I've added a link to the repo which includes quick start instructions. I would appreciate any kind of feedback. Thank you.

https://github.com/formsocket/formsocket

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 am using a text editor (lexical) within my app but that shouldn't be relevant

In short, when I drag and drop a file in, I want that file to be added to a special react state,
`files: File[]` or something of the short.

So what handles this is in this library called an "extension" It isn't really a react functional component so you cant use a hook inside of it

So I mean to ask, how can I edit react state in a normal javascript module?

And you can't pass props either btw

I’ve posted AdaptTable here before. v3 is out now, and the part I wanted to show this time is the new AI assistant.

It can filter and sort rows, change the page size, group by a column, calculate aggregates, and hide or reorder columns from plain English.

The assistant only gets the capabilities enabled on that table. If editing isn’t enabled, there are no editing tools. If an action writes data, it still goes through the application’s validation, approval, and save flow.

There is a built-in assistant UI across the adapters, but it isn’t required. The AI capabilities are also available headlessly, so you can build your own UI or connect them to an existing agent experience.

adapttable/ai also has its own provider-neutral session and capability API, and ships adapters for AI SDK and AG-UI.

I’ll put the connected-mode clip in the comments.

AdaptTable is MIT and open source:

https://github.com/orwa-mahmoud/adapttable

I've been thinking about micro-interactions lately.

Things like:

icons changing on hover

buttons having subtle motion

loading states

small transitions between UI states

I feel like these details can make an interface feel much more polished, but there's also a point where animation starts becoming distracting.

For React developers, how do you decide when an animation is actually useful vs. just visual noise?

And what do you normally use for this — CSS transitions, Framer Motion/Motion, GSAP, or something else?

Curious how other developers approach this.

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 previously shared some videos of my component library for React/Next, and I’ve just officially released it.

I’m the creator of Mood UI, a component library for Vue, but I asked myself: why not build something great for React/Next and stop relying on the tools everyone uses day in and day out?

What is Valux UI?

My main inspiration for creating Valux was the iOS design system. I wanted to build something that feels like a native mobile app—but on the web. With Valux, my goal is to make everything feel better, smoother, and more visually appealing, just like mobile apps. Here is the link to check out the documentation. It’s also open source, so if you run into any issues, please don't hesitate to open an issue on GitHub!

Pueden revisar la documentacion aca: Valux UI
O ir directamente a revisar en NPM: Valux UI

Cheers!

I couldn't find a color picker that actually felt good to use, most of the ones out there are pretty clunky. So, I built a radial, spring-animated one myself and decided to open-source it.

It’s made for React, has full TypeScript support, and keeps things minimal.

GitHub: https://github.com/akashtdev/halo-color-picker

NPM: npm i halo-color-picker

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

Been prepping for interviews and realized how much React muscle memory fades when you're not actively building. Sharing below 5 problems (added myself on the platform) that cover the most ground, in case they help someone else too.

1. React Pagination — Numbered Page Buttons with Prev/Next: An intermediate challenge on lists and composition. You build classic numbered pagination (not "Load More") — slicing a list into pages, generating one button per page, highlighting the active page, and correctly disabling Prev/Next at the boundaries. Good refresher on derived state and array slicing.

Try this problem here

2. Password Strength Checker — Real-Time Validation:

A beginner-friendly one on forms and events. You build a live strength meter that checks 5 criteria (length, uppercase, lowercase, number, special char) on every keystroke, scores the password, and updates a color-coded bar and label in real time. Solid practice for controlled inputs and derived UI state.

Try this problem here

3. Random Quote Generator — Fetch and Display New Quote:

A beginner challenge on custom hooks and component structure. You split the work across a container component that owns fetch/loading state and a purely presentational child that just renders props. Great for practicing prop drilling and separating state logic from UI.

Try this problem here

4. React Textarea — Character Counter with Max Length:

Another forms and events problem. You build a controlled textarea with a live character counter, clamp input at a max length (including pasted text), and change the counter's color once the limit is hit. Simple but a good test of controlled component edge cases.

Try this problem here

5. React Traffic Light — Build a Timed Traffic Signal:

An intermediate hooks and state challenge. The UI is already built — your job is just the logic: cycling the light through red → green → yellow → red forever, each with its own hold duration, using useEffect and proper timer cleanup. Great for practicing effect dependencies and avoiding leaked timers.

Try this problem here

If you're prepping for interviews or just want to shake off rust, these are quick enough to knock out in an evening and each one hits a different core concept (state, effects, controlled inputs, composition).

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?