[Bug] Selected options stays visible in dropdown if options are objects

[tbydza]

I define options using objects and after #217 there is problem with referential equality.

Data for my options and selected come from 2 different sources, but they have same properties.
Each option is identified by the label.
Because of that dropdown used to show only not selected options.

But change of this line caused that these option are no longer equal and they appear to be different options with same label.

And so the selected options stay in dropdown.

Example with screenshots

<script lang="ts">
  import MultiSelect from 'svelte-multiselect'
  const languages = [
  { label: `JavaScript`, value: `JavaScript` },
  { label: `TypeScript`, value: `TypeScript` },
  { label: `CoffeeScript`, value: `CoffeeScript`}
  ];

  const selectedLanguages = [{ label: `JavaScript`, value: `JavaScript` }]

</script>

<MultiSelect options={languages} selected={selectedLanguages}>
  <span slot="selected" let:option>{option.value}</span>
</MultiSelect>

Can you please fix this, or provide some workaround?

[janosh]

Interesting edge case. The simplest workaround would be to JSON.stringify() options before comparing. But that could be a noticeable performance hit if your options contain deeply nested values or if you have 1000s of options. Maybe better would be to add a new prop equal: (op1: Option, op2: Option) => boolean that allows users to specify a custom comparison function. I'll get back to this tomorrow.

[tbydza]

equal: (op1: Option, op2: Option) => boolean would be good.
Some libraries use prop like: by: keyof Option to know which property is identifier.
But I think equal is simpler and more flexible.

For my particular use case I have 10s maybe lower 100s options with simple structure:

interface CustomOption {
    label: string
    value: string
    disabled: boolean,
    order: number
}

[janosh]

@tbydza Sorry "tomorrow" turned into 2 weeks. Would be interested to hear your thoughts on #234 (if you have time to take a look). 🙏

[tbydza]

@tbydza Sorry "tomorrow" turned into 2 weeks. Would be interested to hear your thoughts on #234 (if you have time to take a look). 🙏

Don't worry, I also forgot. I looked at it and tried it. It looks good and I think it will solve my issue. But I don't know how it will affect #217 use case.

[janosh]

@tbydza Had a change of mind. A key function that maps options to a unique identifier seems like a much cleaner and more versatile API than having an equal() function.