-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose Select and MultiSelect aliases for SelectNext #1619
Conversation
|
||
export default SelectNext; | ||
export const MultiSelect = Object.assign( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I chose MultiSelect
over SelectMulti
for consistency with SingleValueProps
and MultiValueProps
, but the latter allows for a nicer grouping of symbols when sorted alphabetically.
cf8da0f
to
5546abe
Compare
5546abe
to
d20abac
Compare
* and the value must be an array. | ||
* Defaults to false. | ||
*/ | ||
multiple?: boolean; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I considered moving this to SingleValueProps
and MultiValueProps
, but that breaks other things, so I decided to leave it as is.
With Select
and MultiSelect
, this prop's value will be implicit and consumers will not have to provide it, so it's not too bad.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1619 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 62 62
Lines 1066 1071 +5
Branches 410 410
=========================================
+ Hits 1066 1071 +5 ☔ View full report in Codecov by Sentry. |
@@ -21,20 +21,26 @@ describe('SelectNext', () => { | |||
* Whether to renders SelectNext.Option children with callback notation. | |||
* Used primarily to test and cover both branches. | |||
* Defaults to true. | |||
* @param {MultiSelect | Select | SelectNext} [options.Component] - |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not completely sure this JSDoc is correct
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The JSDoc here is only for information and not typed checked, so this is fine as long as the meaning is clear.
<code>SelectNext</code> (and its aliases <code>Select</code> and{' '} | ||
<code>MultiSelect</code>) are composite components which behave like | ||
the native <code>{'<select>'}</code> element. | ||
</p> | ||
} | ||
> | ||
<Library.Section> | ||
<Library.Pattern> | ||
<Library.Usage componentName="SelectNext" /> | ||
<Library.Usage componentName="MultiSelect, Select, SelectNext" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
d20abac
to
6495ccc
Compare
value={value} | ||
onChange={setSelected} | ||
onChange={newValue => setSelected(newValue)} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used an inline callback here just to demonstrate type is properly inferred with Select
, as this file is type-checked.
6495ccc
to
f13d045
Compare
}; | ||
export type MultiSelectProps<T> = BaseSelectProps & MultiValueProps<T>; | ||
|
||
export type SelectNextProps<T> = (SelectProps<T> | MultiSelectProps<T>) & { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than being a breaking change, are there any reasons to keep SelectNext
around? Can we replace all uses with either Select
or MultiSelect
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nop, just the breaking change. I already have PRs branches in both client and LMS replacing all SelectNext
instances and they all transparently work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main feedback I have is that we should make a major version update soon that removes SelectNext
from the public API and revises the documentation to make the preferred use of the new Select
/MultiSelect
components obvious. In its current state, I think the documentation will be confusing to someone who hasn't been following the discussions about the evolution here.
@@ -21,20 +21,26 @@ describe('SelectNext', () => { | |||
* Whether to renders SelectNext.Option children with callback notation. | |||
* Used primarily to test and cover both branches. | |||
* Defaults to true. | |||
* @param {MultiSelect | Select | SelectNext} [options.Component] - |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The JSDoc here is only for information and not typed checked, so this is fine as long as the meaning is clear.
f13d045
to
12d8e14
Compare
This PR exposes two new aliases for
SelectNext
, which areSelect
andMultiSelect
. These two implicitly havemultiple={false}
andmultiple={true}
respectively, and do not allow themultiple
prop to be provided.This change serves two purposes:
onChange
's argument type to no longer be inferred based on the type ofvalue
.Select
andMultiSelect
are now enforcing one of the two type paths whenmutiple
is true or false, fixing the type inference.For more context on the issue, check this comment and the ones below.
Select
can transparently replace existingSelectNext
usages, allowing us to eventually drop theSelectNext
symbol in the next major release.I tried to find a solution to the type inference at pure types definition level, but didn't quite get it, even after making types more complex, so I think this option is better, specially taking into consideration to additional benefit explained above.
Note
This PR is easier to review ignoring whitespaces.
TODO
Select
andMultiSelect
in client and LMS projects, where<SelectNext />
and<SelectNext multiple />
is used, to confirm they work.SelectNext
withSelect
. Everything works after a manual test, tests pass with a few minor changes, and typechecks pass.Out of scope
We can probably replace all usages in this library of
SelectNext
with eitherSelect
orMultiSelect
, as they will provide the same coverage, and promote their usage overSelectNext
.Additionally, we could even mark
SelectNext
as deprecated as a standalone component, and recommend using one of the other two.All that will come in follow-up PRs, to avoid distractions from the new API being introduced here.