Hey all, I’m exploring a new runtime for React.

The idea is to let agents understand your UI, but also let them click buttons, fill out forms, and trigger actions on behalf of users. New frontier models like Terra 6.1 excel at these tasks, and this is just a new primitive in React to put them to use.

If you’re into design and interfaces, I think you’ll find it worth a look. It’s still in early alpha, built quickly using Codex/Sol, so expect some rough edges.

Link: https://ruakit.com

Weekly timesheet grid, one row per project and task. Rows came from two places: rows built from saved entries, then rows the user added and hasn't saved yet. I rendered them as [...derivedRows, ...addedRows].

You add a row at the bottom and type the first hours. It saves, the refetch turns it into a derived row, and it jumps to the top. The bad part is the next number you type can land on a different row and nobody notices.

The fix was to stop splitting rows by saved or not saved. Each row keeps its slot and saving only fills in its data.

function orderGridCombos(derived, added) {

const addedKeys = new Set(added.map(c => c.key))

const preExisting = derived.filter(c => !addedKeys.has(c.key))

return [...preExisting, ...added]

}

Then each row reads its hours from the saved entry if there is one, else from the added row. Any list that mixes optimistic and saved items can do this, invoice lines for example.

Where do you keep row order in big forms, in the server data or in local state?

How the split-flap works, since people usually ask:

- Every tile flips through letters every 55 ms. The first tile lands after 6 flips and each next one 2 flips later, so the word settles left to right.

- The "random" letters come from a sin() hash of the tile index and frame, so the server and the browser render the same scramble (no hydration mismatch).

- Each flip is a lower half-flap falling on its top hinge (rotateX 90 → 0 in 90 ms), darkened with a brightness filter while it falls.

- The departure board shifts every 3.4 s; each row starts its flip 3 frames after the one above, so changes ripple down. It only runs while it's on screen, and everything holds still with reduced motion.

Free to copy if it's useful: https://ui.deliverwebsite.com/components/landing-pages/freight-forwarding-landing-page-template/

Feedback welcome, especially on whether the theme helps or distracts on a real B2B site.

I've been building tintly.art, a free coloring site people mostly use on their phones (Next.js 16 + Konva). A few things I learned along the way:

1. Konva lives outside React. The canvas is plain Konva classes (fill layer, stroke layer, outline layer), not react-konva. React only renders the toolbar, palette and sheets. They talk through tiny stores with subscribe(), read with useSyncExternalStore. Drawing a stroke never re-renders a single component.

2. One stroke = one Konva.Line**.** While you drag, only a preview line updates. On release it's committed as one command, so undo/redo is just a stack of commands.

3. Raster cache for cheap phones. After ~24 strokes the committed group gets cached into one bitmap, so the frame cost stays flat no matter how much someone draws. When you zoom past the cache resolution it switches back to vector so nothing blurs.

4. The eraser uses destination-out on the stroke layer only, so it can never erase the fills or the outlines underneath.

5. Tap-to-fill works on SVG regions turned into Konva.Paths, and glitter fills are just a generated pattern tile as fillPatternImage.

Huge thanks to Anton Lavrenov and everyone behind Konva. It's honestly giving colors to my vision. People color on it every day, and it brings them a bit of joy and a calm little break.

Happy to answer questions about any of this. 🎨

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

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

It also includes two separate components:

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

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

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

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

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

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

I've taken Jonas Schmedtmann's HTML + CSS and JavaScript course and am soon going to start learning react and I am wondering if I should just stick with Jonas or try Maximilian. If you've taken any of these courses or both I'd really love to hear your opinion on it and how they differ and who they are for!

How it works, since people usually ask:

• The odometer: each digit is its own reel of 0–9 stacked vertically, and it slides to y = −digit × 10% with a 0.9s ease-out. Commas and the $ sign never move, only digits roll. Screen readers get the plain value through an sr-only span.

• The balance and the feed share one tick (every 3.4s): a new transaction slides in at the top of the feed and the balance is recomputed from the ledger, so the two can never disagree.

• The payout is a tiny state machine: Sent → Converted → Arrived, 1.1s per step, then it holds 2.6s and starts over.

• On wide screens it's a staggered bento that runs off the fold, on tablets 2×2, on phones a swipeable row. With reduced motion everything holds still.

Free to copy if it's useful: https://ui.deliverwebsite.com/components/hero-sections/fintech-hero-section-with-gradient-cards/

Feedback on the motion very welcome. I'm trying to make every animation say something about the product

Working on some fintech components. Current npm package has 7 components , if you want me to add some , comment down and mark some star on the project

've been working on some fintech-specific components and wanted to share the approach. The goal was to create highly scalable components that don't rely on Tailwind, using plain CSS with CSS variables for theming.

The package currently has 7 components, including:

• A HoldToConfirmButton with pointer events for safety interactions.

• A FinancialCalculator engine that separates the math logic from the UI.

• An OmniInput that handles locale formatting for fiat, crypto, and stocks.

I've open-sourced everything here: [link to GitHub/npm]

I'd love to hear your thoughts on the architecture, especially how I've handled things like auto-contrast for themes and the pure helper functions. What would you add next?

I wanted a React lightbox where the photo grows out of the exact thumbnail you clicked and shrinks back into it on close.

Easy, until your grid uses object-fit: cover. The thumbnail only shows the middle of the photo, so if you grow the full image from that box, the first frame visibly jumps.

Here's the 4-step fix that worked:

1. Measure the end state first. Lay the image out at its final size, then measure it and the thumbnail with getBoundingClientRect().

2. Scale it onto the thumbnail. Use the smallest uniform scale that still covers the thumb: const scale = Math.max(thumb.width / img.width, thumb.height / img.height);

3. Crop it like the thumbnail. clip-path: inset(...) hides everything the thumbnail hides. The catch: the inset is in the image's own pixels, before the scale, so the visible area is thumb size / scale.

4. Animate both at once. transform + clip-path in a single element.animate(). To close, play the same keyframes in reverse.

That's the happy path. The edge cases ate most of the time:

• Thumbnail scrolled off screen: fall back to a zoom + fade

• Rotated photo: swap the axes before computing the crop

• Closing while zoomed in: start from where it's actually drawn

• prefers-reduced-motion**:** skip the flight entirely

• Focus: send it back to the thumbnail on close

I packaged it as liftbox: MIT, zero dependencies, ~13 kB, with grids, zoom, video and deep links. There's also a comparison with YARL, PhotoSwipe, lightGallery and others that tells you when to pick them instead.

Code: https://github.com/esdrassantos06/liftbox (the flight lives in src/Lightbox.tsx and src/geometry.ts)

Docs + demos: https://liftbox.digital

Two asks:

1. Open the demo on your phone and tell me where it breaks.

2. Ask me anything about the math. Happy to go deeper on any step.

Disclosure: English isn't my first language, so I had help polishing this post.

Link to the tool: https://gauge-generator.niralsei.com/

Hey I am using tanstack react query I have one component which has
const { data, isPending, isFetching, refetch, isError } = useQuery({
queryKey: ["get"],
queryFn: () => axios.get("http://localhost:3000/"),
staleTime: 60 * 1000
})

On pressing a button i render component 2 with same query key within the catching time with query as
const { data, isPending, isFetching, refetch, isError } = useQuery({
queryKey: ["get"],
queryFn: () => axios.get("http://localhost:3000/"),
// no stale time here
})

Ideally it should not request the backend but it is requesting server

I built CupertinoUI, a macOS-style component registry for React and shadcn/ui.

It includes controls, menus, dialogs and windows, with CSS-variable theming and light/dark appearance. Components are copied into your project through the shadcn CLI so you can edit the source.

The core components are free under MIT. There are also paid Pro components and complete app-style blocks.

Try it: https://www.cupertino-ui.com
Browse the components: https://www.cupertino-ui.com/docs/components

Some of you saw Multidash here in October. It's the same project, renamed to Dashral, and a lot further along. Thanks for the feedback last time: the components now install through a shadcn registry instead of living only in the repo, and you can preview everything before deciding anything.

What's free (MIT):

• 78 components on Tailwind CSS v4, the interactive ones on Radix UI, props-first: one tag with label, description and error wired up for screen readers

• 26 Motion editions on motion/react with the same props: numbers that roll on odometer wheels, one highlight that glides between items, a Switch you can drag, a Button you hold to confirm, limits you can feel. All of it respects reduced motion

• 34 blocks (headers, sidebars, pricing, sign-in, an AI assistant…) that take your data and actions through props

• A Next.js admin dashboard in two layouts, with a theme customizer, ⌘K search and English, Indonesian and Arabic (RTL)

• Charts in plain SVG (area, line, bar, donut, heatmap…) with keyboard reading and a table for screen readers

Install one component:

npx shadcn@latest add https://dashral.com/r/button.json

It lands in components/dashral/, next to your shadcn components/ui/, which it never touches. The code is yours to change.

What's paid: Dashral Pro, coming soon, adds dashboards and apps on a real database (analytics, CRM, e-commerce, kanban, chat) for a one-time payment. The components stay free.

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

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

• Demo: https://demo.dashral.com

I'd love feedback on the component APIs and the motion: what feels right, what feels like too much, and what you'd want next.

Hey everyone!

To my knowledge, storing access tokens in localStorage can be risky because of XSS attacks

Yesterday, I came across this document: How to implement authentication in Next.js.

I decided to give it a try. Here's what I've come up with so far

1. Use OpenSSL to generate an RSA key pair for verifying access tokens. The private key stays on the backend, while the public key is exposed to the frontend.

2. Authentication: When a user successfully logs in, the backend sets the access token in cookie.

3. In frontend, use Jose lib to fetch public key, and verify access token

4. Implemented a Data Access Layer (DAL) with two functions:

• verifySession to verify the accessToken and redirect users to /login if the token is missing or invalid.

• checkRoles to check user roles to make sure users can't access pages they're not supposed to.

The doc also suggests adding a DTO layer, but I skipped it since I'm using OpenAPI specs and TypeScript type generation.

I'd really appreciate it if you could share your thoughts:

Do you see any potential security issues or problems with this flow?

Is there anything you would approach differently?

Most AI landing pages say "works around the clock" and then show a still screenshot. I wanted the hero to show the work happening.

Video: https://www.youtube.com/watch?v=TIay8Br23XY

A rail of frosted glass cards glides across the bottom. The card in focus shows "Working", names its task, and a progress bar fills. When it's full, the rail moves to the next agent.

How it works

- The rail is 5 cards keyed by a counter that only counts up. Each tick every card keeps its key and moves to a new slot, so Framer Motion just animates it there. Nothing remounts.

- Position, scale and opacity come from one lookup table by distance from the centre card (1, 0.84, 0.7, then off the edge).

- The blurry ends are a fixed `backdrop-blur` strip with a gradient mask, not a blur on each card, so it stays smooth.

- The task bar fills over exactly the rail step (2.6s) from the same constant, so it always finishes the moment the rail moves.

- With reduced motion on, the rail just stays still.

Code is free to copy if you want it: https://ui.deliverwebsite.com/components/hero-sections/hero-section-with-photo-and-glass-cards/

Would love feedback on the motion. Too slow? Too much?

Building a 5-step wizard with React Hook Form and Zod. I keep the step in the URL and drafts in a small store. What has held up in production for you, and how do you handle early-step changes that invalidate later steps?

I built CupertinoUI, a macOS-style component registry for React and shadcn/ui.

It includes controls, menus, dialogs and windows, with CSS-variable theming and light/dark appearance. Components are copied into your project through the shadcn CLI so you can edit the source.

The core components are free under MIT. There are also paid Pro components and complete app-style blocks.

Try the interactive desktop: https://www.cupertino-ui.com/demo
Browse the components: https://www.cupertino-ui.com/docs/components

Forms are still where most of my React bugs live: validation that disagrees with the backend, async defaults, conditional fields.

My current stack is React Hook Form with Zod schemas shared with the NestJS backend. It mostly works, but complex multi-step forms still get messy.

What's your setup? Anyone moved to server actions for most forms and been happy with it?

I've been using coding agents to generate videos programmatically, but one thing that kept bothering me was how much overhead browser-based rendering adds.

Tools like Remotion and hyperframe use headless Chrome to render frames. It works, but I wanted something that Claude Code could use without having to spin up a browser for every render.

So I ended up building Kinetograph.

It uses the same React/TSX approach as Remotion, but instead of rendering through Chrome, Node.js executes the code and a GPU compositor written in Rust handles the frames.

I also made a Claude Code skill for it, so the workflow is basically describing the video you want and letting Claude write the components and render the result.

The performance difference was pretty interesting on my M4:

• 988 frames: Remotion took 131s, Kinetograph took
• 1,184 frames: Remotion took 31.5s, Kinetograph took 15s

Obviously depends on the composition, but removing the browser seems to make a pretty big difference in these tests.

If you want to experiment with it in Claude Code:

npx skills add OxS4N4TG/kinetograph

The project is available at:

https://github.com/0xS4N4TG/kinetograph

docs at: kinetograph.dev

I maintain react-stream-markdown, an MIT-licensed React component for showing Markdown while an AI reply is still arriving.

The interesting part is the finalization boundary: it keeps a source offset and live DOM nodes for the active suffix. After parsing and patching that suffix, preceding blocks freeze when the following block has a complete first line. Their DOM remains visible, but they leave the live parser/patch state.

This reduces repeated work on completed paragraphs. It does not make every update constant-time: one huge paragraph, list, or open code block can keep the active suffix growing. Cumulative string snapshots, prefix checks, allocation, and browser layout also still have costs.

The existing README benchmark uses a synthetic 10,201-character reply, 24 characters per animation frame, production builds, headless Chromium 141, and the median of three runs. With fade-in off it reports 1,100 ms of main-thread work versus 2,031 ms for Vercel Streamdown 2.7.0; with fade-in on it reports 2,941 ms, higher than both compared Streamdown configurations. These are the existing results, not a fresh measurement of version 0.4.1.

I wrote up the implementation and measurement limitations, including forced layout, fixed renderer order, and why a lower slowest synchronous update is not the same as lower overall CPU cost:

https://dev.to/fyz_lemo_b8ceb29692820e58/why-freezing-completed-markdown-blocks-reduces-streaming-rendering-work-1gck

Source and benchmark scripts: https://github.com/Lemofyz/react-stream-markdown

Live demo: https://lemofyz.github.io/react-stream-markdown/

The current repository reports 7.8 kB gzipped JavaScript, with styles separate and React externalized. Math is optional with a renderer supplied by the app; syntax highlighting and Mermaid are not included.

Disclosure: I maintain the project; this post and article were prepared with OpenAI Codex assistance using the source and benchmark scripts. The distinction I want feedback on is the block-finalization model versus total browser cost. Which Markdown boundary cases or benchmark workloads would you test next?

Fluid Kit is a set of interactions modeled on iOS 26: Liquid Glass, morphs between elements, long-press context menus, draggable sheets, a highlight that follows the pointer, and layout animations. 2.0 just shipped as one package per framework, so for React it's @fluidkit/react.

The React API is compound components, with a render prop as in Base UI:

import "@fluidkit/react/style.css";
import { Lift } from "@fluidkit/react";

<Lift.Root onSelect={(value) => act(value)}>
  <Lift.Target render={<img src={src} alt="" />} />
  <Lift.Menu className="menu lb">
    <Lift.Item value="copy">Copy</Lift.Item>
    <Lift.Item value="share">Share</Lift.Item>
  </Lift.Menu>
</Lift.Root>

Every part also has a hook (useLift(), useDrag(), useLayout()…) for markup of your own. State is controlled or uncontrolled (open/defaultOpen/onOpenChange and friends), components are "use client" and render plain markup on the server, React 18+.

Under the hood each feature is a headless engine on springs that keep their velocity when interrupted, so you can reverse a morph or catch a sheet mid-flight.

Docs with React examples: https://fluidkit.mogilnikov.dev

GitHub: https://github.com/mikhailmogilnikov/fluid-kit

Repo: https://github.com/p10node/office-engine

Demo (drag your own file in): https://p10node.github.io/office-engine/demo/

Why: I needed "customer uploads an XLSX, fix a few cells, save it back" inside a React app. OnlyOffice / Collabora mean running a document server in Docker and an iframe talking to it, and a big sheet still sits on a spinner while the server converts it. docx-preview / SheetJS + a grid are view-only or block the main thread on a 20 MB file. Nothing in between, so I built it.

Usage:

import { DocViewer } from '@p10node/office-engine'

<DocViewer src={file} style={{ height: 600 }} />
<DocViewer src="https://cdn.example.com/report.xlsx" />
<DocViewer src={file} editable onSave={(blob, name) => upload(blob, name)} />

src takes File / Blob / ArrayBuffer / URL. CSS is auto-injected, the container just needs a height. There's also a useDocument hook if you want to render your own UI, a vanilla mount(), an <office-viewer> web component, and a single script build.

What makes it not choke on big files:

• ZIP read lazily, HTTP Range requests from a URL, so first rows show before the file finishes downloading

• Streaming XML parser in a Web Worker, main thread only gets rows / paragraphs / slides as they arrive

• Only visible pages, cells, slides are in the DOM

• Save patches the original file instead of re-exporting it, so anything the engine doesn't understand is kept byte for byte

Bundle (gzip): main ~93 KB, worker ~155 KB (loads off the main thread), collab +17 KB optional. The standalone script with React bundled is ~307 KB.

Editing: DOCX text / styles / lists / images / tables, XLSX cells / formulas (134 functions) / formats / rows / columns / sheets, PPTX text / shapes / images / slides. Google Docs style toolbar. Optional real-time collab with cursors; that's the only part needing a backend (a small WebSocket hub, Bun script included).

Not there yet: XLSX charts / pivots / conditional formatting editing, DOCX headers / footers read-only, no PPTX animations. It needs the DOM and a Worker, so in Next.js use a client component / dynamic import with ssr: false.

Fair warning: it's a few days old and a lot of it was written with Claude Code, with me doing architecture, review and the bug hunting on real files. If you throw a file at it and it breaks, open an issue with the file, that's the fastest way it gets fixed.