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

If onInit get called many times, where to fetch data #104

Closed
panuavakul opened this issue Feb 10, 2019 · 6 comments
Closed

If onInit get called many times, where to fetch data #104

panuavakul opened this issue Feb 10, 2019 · 6 comments

Comments

@panuavakul
Copy link

panuavakul commented Feb 10, 2019

Hi according to the StoreConnector 's onInit

  /// A function that will be run when the StoreConnector is initially created.
  /// It is run in the [State.initState] method.
  ///
  /// This can be useful for dispatching actions that fetch data for your Widget
  /// when it is first displayed.

So I'm assuming that I should dispatch some action here to fetch data from API and initialized my widget. However, there are many times that when the widget is rebuild, the StoreConnector is also rebuilt and the onInit is called, namely when focusing and unfocusing on TextFormField, which cause the onInit to be called multiple times resulting in unwanted API call.

This seems to be Flutter intended behaviour. flutter/flutter#14124
So I'm wondering how is everyone dealing with this problem?

Thanks

@brianegan
Copy link
Owner

Hey there -- in general, any time you see a Stateful Widget running initState over and over, it means the Widget is not being properly reused by Flutter. Often, Flutter thinks it's an entirely new Widget and needs to replace the old one. This generally shouldn't happen, but can in some cases.

To fix this issue, you can assign a key to the StoreConnector Widget. Then, when it is rebuilt, Flutter will know the two Widgets are the same (by comparing the keys) and it will not dispose & re-run initState.

Could you please try assigning a Key to the StoreConnector and seeing if it solves the problem? If not, please provide a small code sample that demonstrates the issue!

@panuavakul
Copy link
Author

Hi, thanks for the reply, I tried to assign a key in the StoreConnecter, but it still get called multiple time. The more I looked at it it seems that the more I debug, I found that Flutter's material routing handler get called multiple times. Like let's say if my StoreConnector is in MyOtherPage The handler get called randomly like when TextFormField get focus. I would assume that since the handler is called, a new MyOtherPage will be created causing the StoreConnector to also be initialized and onInit to be called.

Navigator.push(context, MaterialPageRoute(builder: (context) {
  /// This get called many times
  return MyOtherPage();
}));

I'm not sure if this is related to flutter_redux anymore, but it seems like all my screen are affected by this but I just didn't notice.

I will try to provide a minimal working code asap. Thanks again.

@brianegan
Copy link
Owner

brianegan commented Feb 11, 2019

Ah, yes -- the Widget tree can be rebuilt at any time. However, StatefulWidgets are meant to be rebuilt, especially if you have a key there.

I'll take a look and see what might be causing the issue, if you happen to reproduce with a small sample that'd be great because I haven't had that problem and have some tests to ensure it doesn't happen, but there could definitely be a mistake / bug / unhandled case in there.

@panuavakul
Copy link
Author

Hi, I'm sorry for the late reply. After a more detailed debugging, I found that the problem is that I share some of the loading state between different screens (not a very good way to do this) and some how they are still alive behind the current screen even after I pop it some how and when the current screen state changes, it also affected the other screens and trigger the routing action, and hence everything is rebuilt and onInit is called. I'm sorry, I should have checked more before creating an issue.
I'm not sure if I should close this so please feel free to close this.
Thanks.

@brianegan
Copy link
Owner

brianegan commented Feb 16, 2019

It's a mistake I've made before as well :) In that case, I'll go ahead and close this one out since I couldn't find anything wrong and have tests covering this case.

@naiveai
Copy link

naiveai commented Jun 6, 2019

@panuavakul I seem to be having a very similar problem to this right now... if you don't mind, I would very much appreciate some details on how you ended up fixing this?

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

3 participants