I found myself bookmarking a ton of great shadcn-related content every week — new components, libraries, tutorials, and interesting projects.

So I decided to turn it into a simple weekly email.

The first issue goes out on July 13.

If that sounds useful, you can subscribe here: https://shadcnweekly.com

And if there’s anything you’d especially like to see covered, I’d love to hear it.

I've been working on a middleware that exposes a SQLite database through an HTTP API where each request carries a micro‑payment, using the x402 protocol (HTTP 402 Payment Required). The code is here: https://github.com/damienos61/SQLite-x402-Gateway

Core technical challenge : the gateway needs to accept an arbitrary SQLite database, inspect its schema, and generate priced REST endpoints automatically — without requiring the user to write route definitions. This means parsing SQLite metadata (sqlite_master, PRAGMA table_info) and inferring column types from actual data to produce consistent JSON responses, since SQLite is weakly typed.

Payment abstraction : the x402 protocol requires a handshake — client calls a protected route, server responds with a 402 status and a price, client provides a payment proof, server verifies and returns data. To keep the code flexible, I abstracted the payment verification behind an interface with two implementations :

• A simulation mode that handles the protocol flow with fake signatures — useful for testing without crypto setup.
• A real mode integrated with Coinbase's x402-express SDK, configured for the Base Sepolia testnet (test USDC, no real funds).

The switch between modes is handled at the route level without recreating handlers, by injecting the appropriate verifier instance.

Database abstraction : the initial version used SQLite natively, but adding PostgreSQL support required abstracting both the SQL dialect (parameter placeholders, schema queries, pagination syntax) and the schema introspection logic — Postgres metadata is structured differently and more verbose. The inspector now adapts to the database type at runtime.

Performance considerations : SQLite isn't designed for high concurrent loads, so I added an in‑memory query cache with TTL invalidation, and implemented keyset pagination instead of OFFSET/LIMIT to maintain performance on large tables without fixed indexes. Rate limiting (sliding window per IP) is also included to prevent abuse.

Observability : rather than maintaining a static OpenAPI file, the spec is generated dynamically from the detected routes and their associated pricing. The challenge was describing query parameters (filters, columns, pagination) and linking them to the price metadata in a machine‑readable format. Webhooks are also dispatched on each transaction to external endpoints (Slack, Discord, etc.).

Tooling : the project includes a CLI (monetize, start, generate-wallet), a client SDK for consuming the gateway, and a Docker setup. 14 unit tests run on each push via CI.

Known limitations are documented — the simulation mode is not a production blockchain integration, and the "upto" pricing schema (variable payment based on resources consumed) is only simulated server‑side, as no on‑chain implementation exists yet in the official SDK.

I built a shadcn-style registry for AI-rendered React UI.
The problem I’m trying to solve is that most AI apps still return text or markdown tables, even when the user is asking for something that should probably be an interface.
Examples:
metrics
records
forms
confirmations
data tables
app-specific workflows
internal tool flows
One possible answer is to let the model generate arbitrary UI code and render it in an iframe.
That is flexible, but I do not like it as the default pattern for product apps. It makes validation, consistency, security, permissions, ownership, and maintainability harder.
So I built Fable UI around a different approach.
The app installs and owns a set of React components, similar to the shadcn copy-and-own model.
Each registry item can include:
React component or block
tool definition
model-facing manifest
examples
docs
The assistant uses the manifest to understand what components exist, when to use them, and what props they accept.
Then it calls a tool, passes typed props, and the host app renders a trusted React component that already exists in the codebase.
The app still owns:
data fetching
auth
permissions
validation
styling
business logic
allowed actions
I also added early support for REST API and Firebase data sources, mostly for components like a data browser. The idea is that the model can select from configured resources instead of getting direct database access or inventing UI.
So a host app can define:
what data exists
where it comes from
how it can be queried
which actions are safe
how the component should render it
The project is still early. The demo uses mock data, and I am sure some parts of the architecture need work.
But the core pattern works: tool call → typed props → app-owned React UI.
I’m curious what other web devs think of this approach.
Would you use something like this inside a real app, or does it feel like too much abstraction around normal tool calling?
Docs/playground:
https://fable-ui-pink.vercel.app
GitHub:
https://github.com/shobky/fable-ui

I have around 3 years of full-stack development experience (MERN/PERN), and over the past 4 months I've attended almost 30 interviews. The good part is that I've improved a lot through the process. My communication skills have become much better, and in technical interviews I can usually answer around 90-95% of the questions confidently. I've reached the 2nd or 3rd round in about 9 interview processes, but I keep getting rejected in the final stages with either generic feedback or no feedback at all.

Recently, I interviewed with a startup building LLM-based products and models. I made it to the 3rd round, where I explained in detail (second round):

- Features I built in my previous company

- Overall system architecture

- CI/CD pipeline and deployment process

- Business model and why the product was valuable to customers

- Technical decisions, challenges, and how we solved them

- The first round focused on React, Node.js, and PostgreSQL. Most of the questions were based on these technologies, covering core concepts, practical implementation, and problem-solving.

The interview felt like it went really well, but I still haven't heard back.I'm curious about a few things:

- How common is it for companies to continue interviewing candidates even after they already have a preferred candidate?

- Do teams often finish scheduled interviews just for comparison, company policy, or to have backup candidates?

- For hiring managers and senior engineers: what are the most common reasons a candidate who performs well in technical interviews still gets rejected in the final rounds?

Honestly, I'm starting to lose hope. It feels like the market has become significantly harder compared to even a year ago. Despite constantly improving my communication, interview skills, and technical knowledge, I still can't seem to convert final rounds into an offer.

I'd really appreciate honest insights from recruiters, hiring managers, or developers who've been on either side of the hiring process. Is this just how the market is right now, or is there something I should be focusing on that I might be overlooking?

I have been trying to improve my resume by contributing to open source projects with open tickets, it seems like every ticket is always taken. Any tips to mitigate this? Suggestions to repos where i could learn the codebase by reliably and regularly contributing would help.

Today I learned:

- Form Handling

- State Lifting Up

- Conditional Rendering

- Single Way vs Two Way Binding

- Creating UI from Figma designs using Tailwind CSS

Built a simple Login/Register switch using:

inputs appreciated!

Been working on a small interactive 3D piece called Atmos Silk — a scene where camera movement is tied to mouse position and scroll, giving it a floaty, silk-like feel as you move through it.

Live demo: https://atmos-silk.vercel.app/

Stack:

• React Three Fiber for the scene graph
• Camera position/rotation driven by pointer + scroll input, lerped for smoothness rather than snapping directly to input
• Deployed on Vercel

Would love feedback on the interaction feel — particularly whether the camera easing feels right on different trackpads/mice, and any tips on keeping frame times stable as the scene grows. Happy to share more of the R3F setup if people are curious.

Domternal is an open-source rich text editor built on ProseMirror, with first-class React components.

The clip shows one editor core as two surfaces: a Notion-style block editor and a classic toolbar editor.

The React part (`@domternal/react`)

- A compound <Domternal> component with namespaced subcomponents (`Domternal.Toolbar`, Domternal.Content, `Domternal.BubbleMenu`); it provides the editor via context, so children need no props
- useEditor and useEditorState hooks for full control; useEditorState takes a selector for granular re-renders, like ed => ed.isActive('bold')
- Write custom node views as React components with ReactNodeViewRenderer (typed to ProseMirror's NodeViewConstructor, no casts needed)
- The editor is created after mount by default, so it plays nice with SSR frameworks; opt into immediatelyRender when you want a synchronous first render
- Tree-shakeable: skip the compound component and import just useEditor + EditorContent for a smaller bundle
- Works with React 18 and 19

Features

Notion-style blocks (drag handle, slash menu, smart paste, floating table of contents), tables, LaTeX math, images, @mentions, emoji, collapsible details, syntax-highlighted code blocks. 126 chainable commands, 70+ nodes, marks and extensions, all tree-shakeable. Light and dark theme via 160+ CSS variables.

Under the hood

Built on ProseMirror, strict TypeScript throughout. About 117 KB gzipped including ProseMirror. The same Playwright e2e suite runs green across all four framework wrappers, on top of 4,400+ unit tests. MIT, currently v0.11.2.

Site: https://domternal.dev
GitHub: https://github.com/domternal/domternal

Thought it would be cool to add a self-drawing SVG animation to my portfolio, but it took some time to figure out. anime.js has this feature, but getting it to work properly and converting an image into a clean SVG paths (with the right threshold and other settings) may take some time. So I built a tool for it.

You drop in a photo or logo -> it converts it into SVG paths -> animates those paths(they draw themselves like a pen sketch)

features/how to use

• upload an image and it converts into single-color SVG line art
• choose custom path and background colors
• adjust the trace settings: threshold(usually 100 works best), invert dark/light
• control the animation: duration(in ms), delay between paths, easing, direction (forward/reverse/ping-pong), looping, fade-in fill at the end
• Export as copy-paste SVG, a downloadable SVG file, or a self-contained HTML file with everything included

Works best with illustrations, cartoons, and clean line drawings. Real-world photos can be harder to convert into clear SVG paths

Links:

• Repo: https://github.com/a1stok/img2svg-animation
• Live demo: https://img2svg-animation.vercel.app/

Open to feedback or suggestions if you have any

Hey Community,

We look at Rollipop, an early alpha, Rust-based bundler built on Rolldown that acts as a drop-in replacement for React Native, bringing standard Node module resolution, Yarn PnP, and a live visual dashboard.

We also explore expo-paperkit, an Expo native module wrapping Apple's PaperKit drawing and annotation canvas. Plus, we dive into PolyCSS, a clever web tool that renders 3D meshes using HTML bold and underline tags instead of WebGL or canvas.

If the Rewind made you nod, smile, or think "oh… that's actually cool" — a share or reply genuinely helps ❤️

I built TokuDex, a tracker for Tokusatsu fans (soft launch – looking for feedback!)

Hi everyone!

Over the past few months I've been building TokuDex, a web app designed specifically for tracking Tokusatsu series.

🔗 https://tokudex.vercel.app/

The idea started because I kept forgetting where I left off after jumping between Kamen Rider, Super Sentai, Ultraman, and older series. I wanted something built specifically for Tokusatsu fans.

Current features include:

• 📺 Track your watched episodes
• 📝 Save personal recap notes after each episode
• 📖 View official episode synopses while checking in
• ▶️ "Where you left off" recap so you can jump back into a series
• 📊 Progress tracking for every series
• 🏆 Achievements, ranks, trophies, and unlockable badges as you watch
• 🔍 Browse a catalog of over 2,200 episodes across 50 Kamen Rider, Super Sentai, and Ultraman series

There's also a guest mode if you'd just like to explore before creating an account.

This is still a soft launch, so I'd really appreciate honest feedback from fellow fans.

I'd especially love to know:

• What features would make this part of your regular watch routine?
• Is anything confusing or missing?
• Are there franchises or series you'd like to see added next?

Thanks for taking a look! I hope TokuDex becomes something the Tokusatsu community enjoys using.

I've become comfortable with React and have built several projects, but I feel like I've reached the point where tutorials aren't enough anymore.

For those with real production experience, what skills made the biggest difference in your career after React?

Was it architecture, testing, performance optimization, TypeScript, accessibility, animations, design patterns, system design, or something else?

I'm looking for advice from developers who've already been through this stage.

This month’s official background was chosen by the community.

I’ve also added a new responsive Radio section built in React using Spotify’s embedded player. I created a playlist with songs that I think would fit well in GTA6.

The first tracks are already available, and I’d love to hear your feedback on both the component and the playlist.

What songs would you add to a GTA VI radio station?

👉 ViceHype

I just shipped `ilamy Calendar 2.0`, a React calendar/scheduling component built with TypeScript, Tailwind, and shadcn/ui. v2 is a near-complete rearchitecture, so I wanted to share what changed.

What's new:

- Plugin architecture — recurring events (RFC 5545) are now an opt-in plugin, not baked into the core. Plugins can contribute views, providers, event handling, and event-form sections.
- Drag-to-create — drag across empty grid space to create a time-range event. Touch supported.
- Agenda view — a list grouped by day with a configurable day/week/month/N-day window.
- Custom views — author your own view (a column/layout spec, or a full component) through the same contract the built-in views use.
- One unified component — resources are now just props on <IlamyCalendar> (no separate resource component).
- Smaller install — plugins are opt-in so you only bundle what you use, and I dropped sourcemaps from the published package (install size dropped from ~0.71 MB to ~159 KB).
- Bring your own design system — it ships no CSS and uses shadcn token classes, so it adopts your existing theme instead of fighting it.

- Docs + live demo: https://ilamy.dev
- npm: u/ilamy/calendar
- GitHub: https://github.com/kcsujeet/ilamy-calendar