-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Allowing to pass options to Select.Async #1199
Conversation
I'm concerned about the idea of supporting both Couldn't you achieve the same result by just returning default options the first time let defaultOptions = [/*...*/]
let initialized = false
function loadOptions () {
if (!initialized) {
initialized = true
return Promise.resolve(defaultOptions)
} else {
return fetch(/*...*/)
}
} |
You could, but i find it more confusing to have an options parameter that is omitted if you pass options to it and always do this kind of special handling you suggested. Imagine a search form with over ten Async selects that you want to preselect. I wouldn't want to implement this 10 lines of code for each of them and handle initialization state for all of them. |
That's totally fair. Your primary concern is maintainable application code and my primary concern (at least in this context) is maintainable library code. Those concerns won't always align. 😄
This sounds like a situation where you could create your own decorator component or HOC to DRY up application code. For example: import React, { Component, PropTypes } from 'react'
import { Async } from 'react-select'
class AsyncDecorator extends Component {
static propTypes = {
options: PropTypes.array.isRequired
};
loadOptionsWrapper (params) {
const { loadOptions, options } = this.props
if (!this.initialized) {
this.initialized = true
return Promise.resolve(options)
} else {
return loadOptions(params)
}
}
render () {
return (
<Async
{...this.props}
loadOptions={::this.loadOptionsWrapper}
/>
)
}
} |
In general, I am wary of implementing more than 1 way to achieve the same result within library code because of the reasons I mentioned above:
|
Yea sure, you can do many other things with HOC that are actually implemented in the library code, too :) I am not disagreeing with your points, they are all legitimate. |
I think your concerns are legitimate as well. 😄 I'll give this a little time to sink in and come back to it (unless Jed or another contributor beats me to it). |
To be fair, this is only applicable to the special, async variation of I'm not convinced that the For example, something like: class AsyncSelect extends Component {
constructor (props, context) {
super(props, context)
this.state = {
options: props.options || []
}
this._onInputChange = this._onInputChange.bind(this)
}
componentWillUpdate (nextProps, nextState) {
if (this.props.options !== nextProps.options) {
this.setState({
options: nextProps.options
})
}
}
render () {
return (
<Select
{...this.props}
onInputChange={this._onInputChange}
options={this.state.options}
/>
);
}
_onInputChange (inputValue) {
const promise = this.props.loadOptions(inputValue)
this._promise = promise
promise.then((options) => {
// Ignore all but the most recent request
if (promise === this._promise) {
this.setState({ options })
}
})
return inputValue
}
} Then again, I guess this isn't all that far off from what |
Okay. Have thought through this a bit more now and have a better understanding about how I believe I'll try my hand at refactoring |
Closing in favor of PR #1226. I refactored |
Hey Brian, How did you resolve this issue btw? |
Ok checked the code, passing options seems to work now with Select.Async 👍 Thanks |
With this PR you are able to pass default options to Select.Async. This allows you to set a default value without calling the Async promise.
See Issue #1138
Example: