The list is probably never long enough for this difference to matter that much and I could see object spread getting transpiled to Object.assign anyway but using Object.assign is faster than spread.

https://jsbench.me/q5lb5lumdv

I'll make a separate PR to address this (it happens in more places within ComboBox).

Actually, I get hit with an eslint rule error if I do that, so maybe we prefer this approach in v8

The docs for this plugin state that

Introduced in ES2018, object spread is a declarative alternative which may perform better than the more dynamic, imperative Object.assign.

which, along with readability, seem to be the arguments in favor of enforcing spread. In the benchmark I linked spread is ~80% slower in Edge and ~85% slower in Chrome, while Object.assign is ~6% slower in Firefox. May perform better indeed 😉. What I'm getting from this is that the performance is implementation-dependent so it could change tomorrow, but that even in the case where spread is faster it's not that much faster (and it's within the margin of error, +/- ~7%). Compared with the cases where spread is slower, it's much slower and well outside the margin of error. So where we think performance is critical we should prefer Object.assign.

So is performance critical here? That's not so clear to me. I'm of the opinion that we should strive for Fluent to be as fast as (reasonably) possible, leaving as many resources to our users as possible so in that sense all performance is always critical. Yet, it's not clear to me that this measurably affects the perf of ComboBox?

I think this change is simple enough that it's worth benchmarking spread vs object.assign in ComboBox itself to see what shakes out.

What do you think about running a ComboBox bench for this case?

ETA: I should note that in testing Firefox is in the neighborhood of 875 opts/s at the fastest while Chrome and Edge are around 1000 opts/s meaning Firefox is more consistent but slower overall.