I built a shadcn-style component registry for Slint

[stevekwon211]

I have been building slintcn: shadcn/ui-style copy-paste components for Slint native apps.

The idea is to make Slint apps easier to style without depending on a theme API: install components into your repo, edit the .slint files directly, and optionally host your own registry.

It currently includes:

• 36 UI primitives and 5 installable blocks
• dark/light theme tokens and base-color variants
• generated docs with live WASM previews
• an npm CLI for installing components into a Slint project
• adoption-mode flags for fitting components into an existing design system

Install:

npx slintcn@latest init
npx slintcn@latest add button card input dialog

Docs: https://stevekwon211.github.io/slintcn/docs/
GitHub: https://github.com/stevekwon211/slintcn
Intro: https://github.com/stevekwon211/slintcn/blob/main/docs/INTRODUCING_SLINTCN.md

Feedback wanted on component APIs, docs clarity, and which primitives/blocks should come next.

[eira-fransham]

Wow, fantastic work! The design is really simple and elegant, these would fit well into a few different themes. The live previews in the docs are lovely, too.

As for feedback, none of the components that I looked at had property docs - that seems like a pretty important part of the API! Otherwise, the interface seems pretty reasonable. Slint doesn't have the best story for designing expressive APIs for external components right now, so considering those constraints I think the limited API that you've gone with is very reasonable.

We're currently working on some features such as slots and component factories that would let external component libraries be more expressive (e.g. #6258, #2390). We're also planning support for optionals (#5164), which would also probably help with things like adding optional theme overrides for a single component.

It'd be great to hear your experience building something like this and how you think Slint's story for writing third-party components could be improved, that's definitely something that we want to have better support for.

[stevekwon211]

Thanks so much! That means a lot. The live previews were genuinely fun to build, and Slint → WASM is a really nice fit for this

You're right about the missing property docs. That's a real gap, and I'll fix it. The per-component pages already show variants, sizes, and the accessibility contract, so I'll add a Properties section next to those with descriptions for every in, in-out, and callback, generated from or kept close to the .slint files

On the third-party component story, these were the main things I ran into while building slintcn:

1. Trigger-wrapping components and silent layout collapse.
For components where the trigger is passed through @children — Tooltip, Select, Popover, ContextMenu, and now DropdownMenu / HoverCard / Menubar in v0.24 — I had to route the children through a HorizontalLayout shim and bind preferred-width / preferred-height to it. Otherwise, the parent layout can allocate a 0-width slot and the trigger visually overflows onto its siblings.

I hit this same issue seven separate times before recognizing the pattern. The tricky part is that it shows up as silent visual overlap, with no error pointing to the actual cause. Slots (#6258) would directly remove this footgun. Right now, this is probably the biggest “watch out” I’d give someone building a Slint component library

2. Reserved property names on Rectangle.
Since padding, radius, color, and visible can't be redeclared on a component that inherits from Rectangle, slintcn's Card ended up with properties like card-padding and card-radius. It works, but it feels awkward in user code. Some kind of cleaner override surface, or scoped property namespace, would make third-party component APIs feel much nicer

3. Optionals (#5164) would help a lot.
A lot of components have title / description / leading-icon style patterns where I currently end up doing checks like if x != "": Text { ... }. Optional-aware syntax would make those APIs and implementations much cleaner

The per-component theme override case you mentioned is also a big one. People want to tweak one Button, Card, or Dialog without forking the whole token table, and optionals seem like a natural fit for that

A few smaller rough edges I ran into: no local property inside callback bodies, no direct string + int concatenation outside interpolation, and not being able to set both width and min-width on the same element. None of these are blockers, but they are sharp first-time edges where the error signal can be limited

Overall, slots + factories + optionals would probably remove most of the awkward patterns in slintcn's source. Happy to share concrete examples with file pointers, or test early builds if that would be useful

Thanks again for the kind words

[ogoffart]

Thanks for sharing. I'm adding a reference in our docs: #11893

[stevekwon211]

wow very appreciates 🥹

[okhsunrog]

The github repo seens to be removed, why? @stevekwon211

[stevekwon211]

The github repo seens to be removed, why? @stevekwon211

unfortunately my team decided to hide the repository