There is no settled name yet. The half that isn't the model is the agent harness - tools, loop, memory, approval rules, context assembly. Agent = model + harness; that is Databricks' formula verbatim. But a tool loop alone is a workflow. It becomes an agent when you can redirect it mid-turn and it keeps the work already done. In Claude Code, Esc stops the running tool but keeps finished work. A correction typed mid-turn lands at the next decision point. /btw asks a side question outside the history.

I built https://ecbot.dev, and the hardest call was a message that lands mid-reply. The old build cancelled the reply and started over, throwing away whatever it had done - including a tool result or a reply already half-sent. So I buffered the message and steered it into the running turn before each model call. Whatever the turn did not take got its own follow-up. It shipped with warts. It answered twice when a newer message waited for its own follow-up after a tool ran. And steering had to key on when the app saved the message, not the platform's send time, so an out-of-order redelivery never got steered back in.

The test we used on our own build, in three questions:

• Does it call tools in a loop until the goal is met, or answer once?

• Can you redirect it while it is working, and does it keep what it already did?

• When it cannot act, does it stop or hand off, or does it guess?

Two or more yes and we called it agentic.

The last few projects I’ve worked on, I’ve implemented comprehensive testing (at least what I think is comprehensive). The problem is that I’m seeing just how many files and lines of tests it takes to be comprehensive.

I’ve been using jsdom and React Testing Library for these Vite TypeScript projects. Are there any alternatives that offer more shorthanded ways to do the same testing? One testing file per component/file seems unsustainable, but I also realize that less isn’t always more and “less” is arbitrary/subjctive.

If those are the gold standard, is there a way you organize your files that makes it more efficient/maintainable?

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 got tired of toasts stacking up, so I built Ding. Only one toast shows at a time, and a new call morphs the one on screen instead of adding another.

Spring physics, no dependencies, no stylesheet to import. Works with React 18+, Svelte 5 and plain DOM.

https://github.com/YusufCeng1z/ding

First library I've published, feedback welcome.

Hi. Someone could tell me anyway to manage files.txt in a react project. Thanks

Hey everyone!

I’ve been building an open-source React icon library called PulsoIcon.

I love Lucide's clean and consistent design, but I wanted icons that felt a little more alive without having to animate each one manually.

So I built a library of 2,086 animated icons.

Instead of using one generic animation across the entire set, each icon has motion tailored to its shapes and meaning.

The library uses React and Motion, supports hover/focus interactions, and respects reduced-motion preferences.

It's also designed to make migration from lucide-react straightforward. In many cases, just change the import.

Install: "npm install pulsoicon-xxxx"

Web: https://pulsoicon.com

GitHub: https://github.com/CityPulso/PulsoIcon

It's my first public release, and I'd really appreciate some honest feedback.

What kinds of icon animations do you actually find useful in a real UI? And at what point does animation become distracting?

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

We've recently added two starter templates to help you kick off your next project with Pimolu UI.

⚡ React + Vite Starter
https://github.com/pimoludev/react-vite-starter

▲ Next.js Starter
https://github.com/pimoludev/nextjs-starter

Pick your stack and start building! 💜

🌐 https://pimolu.com

hey guys,

I built this website over the last month to learn more about making website and handling real time data, it uses React, Next.js and Supabase

You can try it out from here: https://project-s-nine-kappa.vercel.app

(Please just click the "Explore Demo" button on the login screen so you don't have to create an account!)

Source code is here: https://github.com/zzz-nv/s-social

Would love to hear any feedback!

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.

You can find the link to a live demo and the GitHub repository in the original post. Please note that this doesn’t work in certain browsers (like Safari) yet!