-
Notifications
You must be signed in to change notification settings - Fork 4.1k
async-select-refactor #3372
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
async-select-refactor #3372
Conversation
00b5374
to
3996f29
Compare
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.
LGTM -- would prefer @JedWatson has a look too
const promiseOptions = inputValue => | ||
new Promise(resolve => { | ||
const promiseOptions = inputValue => { | ||
return new Promise(resolve => { |
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.
Is this change just for readability?
constructor(props: Props) { | ||
super(); | ||
super(props); |
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.
👍
3996f29
to
c2ecc1d
Compare
c2ecc1d
to
b2cbdaa
Compare
955232b
to
abbe492
Compare
I'm not really into this project, but this PR looks good to me. |
@Methuselah96 thoughts on closing this in light of the refactor to TypeScript? |
This is significantly out of date since |
Async Select Refactor
Overview
Previous Async Select was a composition of makeAsyncSelect, manageState and the base Select component in the following order.
makeAsyncSelect(manageState(Select));
This meant the async logic from the exported Async Select was not able to leverage the helpful abstraction of controlled properties like onChange and inputValue that manageState provides.
This PR aims to rectify this by changing this composition order, to the following:
manageState(makeAsyncSelect(Select))
In doing so we are afforded a bunch of niceties:
AFAIK the api also doesn't change, so this might even be possible to ship as either 2.3.1 or 2.4.0 @JedWatson