Closed atmgrifter00 closed 3 months ago
I'm not against enabling extensibility through protected methods. _value
is interesting, but in some sense, if you're going to take extend there is an author responsibility in my mind on doing that. I also think there is value is that over increasing complexity within the base component.
Thoughts from @kingoftac, @radium-v, @bheston, @scomea?
Unfortunately @microsoft/fast-foundation
is being deprecated, refer to #6955.
🙋 Feature Request
We have a need to provide filtering capability for the
Select
, which was a mostly painless process, save for one unfortunate implementation hack. Ultimately, we had to provide an override to theset value
implementation so we could reference our overriddenoptions
reference which returns a filtered set of options (just like theCombobox
). However, in theSelect
base implementation it ultimately sets its private_value
field. The only solution I had was to sidestep our linter and do something likethis['_value'] = newValue;
.I'm not sure if the ultimate answer is to make
_value
protected
or some other more official extensibility support, but I think the ideal results in clients not having to write the kind of code I mention above.🤔 Expected Behavior
I should be able to extend
Select
to provide filtering support without having to write non-type safe code.😯 Current Behavior
Couldn't come up with a way to provide the behavior I needed without writing non-type safe code (ala
this['_value'] = newValue;
).💁 Possible Solution
Make
_value
protected
.🔦 Context
💻 Examples