Currently, users have to query for option children to get the selected item. Adding a prop to make this simpler would be a great dev enhancement.
cc @AdelheidF @dhrumil83
Add a read-only selectedOption prop to select with a reference to the active selection.
calcite-select
<calcite-select id=selection>
<calcite-option>high</calcite-option>
<calcite-option>medium</calcite-option>
<calcite-option>low</calcite-option>
</calcite-select>
// ...
<script>
selection.addEventListener("calciteSelectChange",
(event) => console.log(event.target.selectedOption, "was selected"));
</script>
@macandcheese @bstifle @paulcpederson Would the design system allow for multiple selection on select in the future? That would determine whether we use selectedOption vs. selectedOptions (like native select).
That's a weird one since the... not-styled-ness of a native "multiple" select is VERY apparent (vs. just the options which we can hide behind a styled dropdown). I feel like we'd probably want to invite the combobox, or a tile-select with "multiple" and no inputs showing (which, gets you close to that functionality of native multiple select):

for that kind of workflow.. but. Hm good question, it is nice to support all native permutations of what we re-create here. cc @bstifle
FWIW, I'm not vouching to support all native permutations. 😄 I don't think the multiple select use case is valid if the design system has a better replacement for it, which I think is what you stated:
I feel like we'd probably want to invite the combobox, or a tile-select with "multiple" and no inputs showing (which, gets you close to that functionality of native multiple select)
Installed.
@AdelheidF @dhrumil83 @codylawson Would any of you be willing to verify this on @next? 🙇♂️
Tested in our Vue app and can confirm it's working as expected! Thanks @jcfranco
Awesome, thanks @codylawson!