Svelecte: a Svelte select component that behaves like a native form field

A select that tries to look like a select, not like a widget

Svelecte is a flexible autocomplete and select component written in Svelte, initially inspired by Selectize.js, also usable as a custom element, and usable in forms where it behaves very similar to a standard select element.

That last clause is the design brief, and it is more demanding than it sounds. A combobox is easy to build as a listbox with a text input on top; it is harder to build one that a form library, a screen reader and a keyboard-only user can all cope with. The stated feature list is a checklist of exactly those problems: searchable, multiselect with a limit on the maximum number of selected items, simple arrays or complex objects as items, a custom item renderer called a formatter, the ability to create new items and possibly edit them, remote data fetch, virtual list support, i18n and basic ARIA support, SSR support, client validation support tested with sveltekit-superforms, lazy dropdown rendering, custom element usage, customizable styling, and drag and drop integration with svelte-dnd-action.

The credits explain where the behaviour comes from. Selectize.js is the main inspiration, sifter is the search engine, and svelte-tiny-virtual-list provided the virtual list functionality for versions 3 and 4.

So the search is not Svelecte's own algorithm. Sifter is a separate library, a filtering and scoring engine that Svelecte calls, and that is a decision with consequences: the matching behaviour you get is the behaviour of sifter, with its tokenisation and its scoring, and if you need a different one you are choosing a different component.

The custom element route is the other thing that sets it apart. A form and its component library are the two things most likely to disagree, and a component that can also be registered as a custom element means it can be used from a page that is not a Svelte application at all.

Installing it and a first field, in eleven lines

The installation is the usual one:

npm install svelecte

And there is one version rule to respect, stated as a note in the project documentation: for Svelte 4 use version 4, and version 5 is Svelte 5 only. The package metadata agrees, with a peer dependency of svelte ^5.2.7 and a version field of 5.4.0.

The minimal example in the documentation is short enough to memorise:

<script>
import Svelecte from 'svelecte';

const list = [{ id: 1, name: 'Item 1' }, { id: 2, name: 'Item 2'}, ...];
let myValue = null;
</script>

<Svelecte options={list} bind:value={myValue}></Svelecte>

Three things are visible in that snippet. The options are passed as a plain array, and the array may hold simple values or complex objects. The selection is bound with bind:value to a single variable, which holds the selected item rather than its index, and for a multiselect it holds the array of selected items. And the component is used as an ordinary element with a closing tag, which is how a Svelte component that has children or slots is used rather than the self-closing form.

The documentation site at svelecte.vercel.app is where the rest of the API lives, and the project publishes its changes on the releases page, with a CHANGELOG.md in the repository as well.

The features that solve the awkward parts of a real form

Several of the listed features address problems that only show up once the component is inside a real application.

Lazy dropdown rendering means the option list is not built until it is needed. On a page with a select over a few thousand records, rendering every option on mount is a visible cost, and a component that defers it changes the feel of the page. Virtual list support is the stronger version of the same idea, and it is the feature that makes a long list viable; the project credits svelte-tiny-virtual-list for providing that functionality in the earlier versions, which tells you the current implementation is at least partly built on the same idea.

Remote data fetch covers the case where the option set is not known in advance, which is the normal case for a user search. Creating new items, with the option to edit them, covers tag-style input where the user types something new and the form is expected to accept it.

The formatter hook is the extension point for appearance. It lets you draw each option yourself rather than accepting a string, which is what you need when the objects are complex and the label is one field of several, or when you want a colour swatch or an avatar next to a name.

Then there is the compatibility layer. SSR support matters for a SvelteKit application because a component that touches the window during setup will break the server render. Client validation support, tested against sveltekit-superforms, means the component's value can be validated the way a native form field would be. Drag and drop integration with svelte-dnd-action covers the case where the selected items need to be reordered, and the multiselect limit caps how many can be chosen at once.

And accessibility is in the list as i18n and basic ARIA support, with the word basic doing honest work. A combobox has to expose a listbox pattern, manage focus, and announce the active option, and a component that gets the ARIA attributes right is doing more than the styling.

How the package is built, and what the releases say about the pace of work

The build pipeline in the package metadata explains a lot about the project.

The dev script is vite dev, and the build script is vite build followed by npm run package, where package runs svelte-kit sync, svelte-package and publint. publint is a checker for package exports, so the published package is validated for the way it declares its entry points rather than only built. The exports map in the package.json has a single entry, with a types field pointing at ./dist/index.d.ts and a svelte field pointing at ./dist/index.js, and the files list ships the dist directory while explicitly excluding test and spec files from it.

There is a second build target. The standalone script runs rollup with rollup.config.standalone.js, and the repository has a bundle/ directory, which is the custom element build: a single file you can drop on a page and use without a Svelte runtime, since that is the point of the custom element support.

The rest of the tooling is a modern SvelteKit setup. The dev dependencies include @sveltejs/kit, @sveltejs/package, @sveltejs/vite-plugin-svelte, the Vite plugin, and both the auto and vercel adapters, which is why the documentation site is hosted on Vercel. The tests run on vitest with @testing-library/svelte, @testing-library/user-event and @testing-library/jest-dom, with jsdom as the environment and msw, the mock service worker, for network mocking. That combination tells you remote data fetch is tested at the network boundary rather than with hand-written stubs. There is a check script running svelte-check against jsconfig.json, and mdsvex.config.js for the documentation site.

The release history shows steady work with one long gap. The recent tags are v5.4.0 and v5.3.1, both published on 2026-10-06, and v5.3.0 from 2025-08-07, and the last push to the repository was on 2026-10-06. So two versions shipped within an hour of each other on the same day as the last push, after a year of no minor release. If you are tracking versions, the current line is the one to pin, and the gap before it means the changelog is where you check what changed.

Against the alternatives: Selectize, and the plain HTML select

The project names its own inspiration, and the comparison with Selectize.js is the most useful one available.

Selectize.js is a jQuery plugin. That is the structural difference, and it cascades into everything else. Svelecte is written in Svelte, so it is a component with props and bindings rather than a jQuery instance attached to an input element, and it can be rendered on the server, which a jQuery plugin cannot. Selectize also has no virtual list and no lazy rendering in the same sense, because a plugin that manipulates the DOM directly has to build the option list to search it. The comparison is not only about size or modernity: a component that owns its own rendering can be SSR-safe, can be typed, and can be styled with CSS variables from inside the design system.

The other comparison, against a plain HTML select, is the one a team should make explicitly, because the native element is the default choice and it is often the right one. A native select is accessible for free, it works on a phone, it needs no JavaScript to open, and it submits with the form. What it cannot do is search, create new entries, hold thousands of options comfortably, or render a custom row. Svelecte exists in that gap, and the project's own claim that it behaves very similar to a standard select element is an attempt to close it, so that a form written with it still validates and submits like a normal form.

The custom element route is what makes the third option possible. When the surrounding application is not Svelte, the same component can be registered as a custom element and used from plain HTML, so a team does not have to choose between the form and the component library.

Where Svelecte is the wrong tool

The first limit is the version line. Version 5 is Svelte 5 only, and the peer dependency asks for svelte ^5.2.7. A project still on Svelte 4 has to take version 4 of Svelecte and live in a different branch of the component's behaviour, and a project that upgrades Svelte has to upgrade the component at the same time. The documentation is explicit about this, which is better than discovering it from a peer dependency warning.

The second is the search behaviour. Because sifter is the search engine, the matching is not yours to tune. If your product needs token prefix matching, fuzzy scoring, or a particular ordering, you inherit sifter's rules, and the only way out is to write your own filtering and feed it in.

The third is that the accessibility support is described as basic. A combobox is one of the harder patterns to get right for screen readers, and a library that gives you ARIA attributes and correct roles is a good start rather than a guarantee. If your application has an accessibility audit attached to it, the component will need to be tested like any other custom control, and the documentation does not claim more than that.

The fourth is the styling responsibility. Customizable styling is a feature and a cost: the component ships without a design system, so someone on your team has to style it, and the visual result will be your responsibility rather than the library's.

The fifth is the release rhythm. Two versions on one day in October 2026 after a year without a minor release means the project is active but not on a predictable cadence, and a consumer who wants a stable dependency has to decide when to take a new tag. The CHANGELOG.md and the releases page are the places to check.

And the sixth is a scope point rather than a defect. Svelecte is a select component. It is not a form builder, it does not validate on its own beyond the client validation integration, and it will not tell you whether the user's input is sensible. That is your code's job, and the component is designed to stay out of the way of it.

Editorial conclusion

Svelecte is worth adopting for a Svelte 5 application that needs a combobox in a form, because it is built to behave like a standard select element rather than like a widget bolted on afterwards, because the value binding is a single bind:value on plain objects, and because it can be dropped into a non-Svelte page as a custom element when a form and its component library disagree about frameworks. It is the wrong tool if you are still on Svelte 4, and it is the wrong tool if you want a design system that arrives pre-styled. Before you install it, check three things: that the version you get is 5.x, which the project documentation says is Svelte 5 only, with Svelte 4 users pinned to version 4, and that the peer dependency asks for svelte ^5.2.7; that the search is powered by the separate sifter library, so if you need matching behaviour that differs from sifter, you are choosing a different component; and that the published package is built through svelte-package and checked with publint, so a break in the package exports shows up in the release rather than in your build.

Frequently asked questions

Official sources

1. License: MIT
2. mskocik/svelecte on GitHub
3. Project website
4. README
5. Releases