Using the dropdown for inputs & code modularity.

[nohehf]

Hi @janosh !
First, thank you for this amazing component. It is really a charm to work with it :)

I have had a case where I would like to use the dropdown for text input, not a select.

The existing dropdown multi-select and its features would make for a great, enhanced, and customizable version of a datalist.

The current closest result to this you can get is achieved with something like:

<MultiSelect
  options={suggestionOptions}
  allowUserOptions
  noMatchingOptionsMsg=""
  createOptionMsg=""
  maxSelect={1}
  required={1}
>
  <span let:option slot="option">
    Whatever custom slot
  </span>
</MultiSelect>

But this is not really usable as it has some perks, as it doesn't feel like an input:

• Text is not editable without removing the whole element
• "Card" look
• ...

It would be nice to separate the Multiselect component into multiple components. It would allow the drop-down to be used for inputs and probably serve other use cases.

I know this is not the standard use case for the component, though it would make the library even more versatile and improve the overall quality/clarity.

If this seems useful to you, I can start working on a MR (tho I cannot promise any ETA). The first step would be to split the component, then use adapt the dropdown to make it usable outside of the multiselect, and last maybe export an Input component.

Let me know what you think and thanks again for the amazing work!

PS: I have a lot of TS errors in my editor related to Options type, in the form of:

Argument of type '...' is not assignable to parameter of type 'Option'.
  '...' is assignable to the constraint of type 'Option', but 'Option' could be instantiated with a different subtype of constraint 'Option'.

PS2: Just wondering, why isn't the lock file committed ?

[janosh]

Thanks for bringing this up! And for #220! 👍

It would be nice to separate the Multiselect component into multiple components. It would allow the drop-down to be used for inputs and probably serve other use cases.

I've thought about this once or twice but so far have lacked motivation because I didn't need it myself. But if you want to tackle this, feel free. PRs welcome!

PS: I have a lot of TS errors in my editor related to Options type, in the form of:

Do you mean using when using the component or developing it? Either way, I'd appreciate any and all fixes!

PS2: Just wondering, why isn't the lock file committed ?

Life on the edge. :)
I never encountered a need for them yet with Svelte. No clashing transitive dep version. Maybe because the deps tree of my Svelte projects is more shallow than with other frameworks. So all the lock file did for me was clutter up git history.