Skip to content
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

isLoading is broken in rc2 #1228

Closed
mikecousins opened this issue Sep 19, 2016 · 6 comments
Closed

isLoading is broken in rc2 #1228

mikecousins opened this issue Sep 19, 2016 · 6 comments

Comments

@mikecousins
Copy link

There seems to be a change in functionality between rc1 and rc2 with regards to the isLoading prop. In rc1 our selects appear and they don't have the loading spinner going. In rc2 they show Loading and the spinner is spinning even though I've explicitly set isLoading to false.

@TheSharpieOne
Copy link
Contributor

is this for Select or Select.Async? Because the isLoading prop was removed from the Select.Async. Not too sure if it was intentional or not, but even with the code before this change (in rc1), setting isLoading to false would not have the desired affect with the Select.Async component. It would only set isLoading to true if the prop was true.

@mikecousins
Copy link
Author

Yeah it's for async. What's the correct way to handle it now on rc2? My spinner just keeps spinning on rc2 and works fine on rc1. Before I was setting isLoading to true when i fetched new data from the server and set it to false when it was done. Now it just constantly spins.

@TheSharpieOne
Copy link
Contributor

if you are using loadOptions(inputValue, callback), you can either return a promise (such as return fetch(url).then(resp => resp.json()).then(someOtherMapping)) or call the callback when your options. I believe previously, you could return the result directly, but now you have to do the one those two thing. I only use the callback method since I debounce using lodash.debounce and I know that it works for me (it only spins while loading for me). I have not personally tried/tested returning the promise.

If you return a promise, you need to make sure that promise eventually gets resolved (it will keep spinning until that happens).

You have to do one of those two things. If you have something in your loadOptions that does something like checking that the inputValue has a certain length (since that is now in user-land), you still have to use the callback or return a [resolved] promise (return Promise.resolve(myEmptyOptions), even with an empty options set ({options: []}). Without that, it will keep spinning. I think this is most likely what is happening.

@mikecousins
Copy link
Author

I'm calling the callback with the options currently and that's what seems to be broken and/or changed.

callback(null, { 
          options, 
        }); 

@TheSharpieOne
Copy link
Contributor

Can you post your whole component or at least your load loadOptions. If you are able to recreate it using something like webpackbin.com that would be best.

@mikecousins
Copy link
Author

mikecousins commented Sep 21, 2016

Thanks for that. Writing a simpler solution on webpackbin made me think about it some more. I actually had some error conditions that return out in my loadOptions method. These weren't calling the callback like the happy path did and I guess that is why the spinner kept going. Weird that the spinner stopped in old versions with this code...

For example:

http://www.webpackbin.com/E1SV8g3hW

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants