Scrolling down to bottom of screen when Redux store changes

[brianegan]

Scrolling down to bottom of screen when Redux store changes

[brianegan]

Hey all, just pushed up a new PR that adds two callbacks for this purpose. Please see #55 and let me know your thoughts on the naming!

[brianegan]

Hey all -- what would you like this callback to be called? What I can think of:

• onPostFrame - this is the system callback used on the hood, but maybe not very clear
• onDidChange - good alignment with the onWillChange callback

Other suggestions welcome!

Also, one more question: Would you want this callback to run after the First build and after every state change, or only after the state changes?

[kitoko552]

I got the same problem as hash404 got. I agree with Alexandre.
I'm looking forward to updating!

[brianegan]

Ah, this is an interesting case. We have the onWillChange property on the StoreConnector, but I haven't quite implemented this functionality just yet and I do know it's important. I'll look at good ways to handle this.

[AlexandreRoba]

Any update on this?

[AlexandreRoba]

I'm also kind of stuck on this. I need to set the position on a ListView on the "selected" item when the presenter is built. Unfortunattely the only way to scroll the ListView is to use a ScrollController... The ScrolleContoller can only be called once it has been attached to the ListView which happens in the build method. I'm setting a Timer in the build method that will animate the listview 10ms after is has been built... But this is ugly :(

[brianegan]

Hey @AlexandreRoba -- sorry, not sure how I missed your message. I'm actually playing around with this right now, and hope to publish something this weekend!

[AlexandreRoba]

Hey Brian, IMHO onDidChange speaks for itself :)

[brianegan]

Thanks @AlexandreRoba -- Would you want this callback to run after the First build and after every state change, or only after the state changes?

Or should I make 2 callbacks: onFirstBuild and onDidChange? Or is the onFirstBuild even necessary? Just trying to support the important use-cases!

[AlexandreRoba]

Hey Brian, I’m not an expert (YET!!!) on flutter nor on Redux so my opinion is probably the most valuable yet… I have a question: A state change does not always trigger a call to build? (if distinct is true and the == operator on the state gives a different resutl)t? In what a First build is different than a Build from a state change? Aren’t those alway triggering a ‘First Build’ for presentation component? Sent with Unibox

…

On Jun 11, 2018, at 11:38 AM, Brian Egan ***@***.***> wrote: ***@***.*** -- Would you want this callback to run after the First build and after every state change, or only after the state changes? Or should I make 2 callbacks: onFirstBuild and onDidChange ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .<embedded image>

[brianegan]

Hey hey, thanks again for all your feedback -- yah, it's a bit tricky since there are some intricacies in how builds are handled in Flutter. There are 3 types of builds that could happen:

1. The first time the ViewModel is created and the builder function is run.
2. Every time the ViewModel changes (not the App State necessarily, as you could use distinct to limit the number of rebuilds for performance reasons)
3. Whenever Flutter decides it needs to rebuild the Widget. This could happen if the user rotates the screen, or if a Widget above the StoreConnector request a rebuild, or if the user navigates to a new route. This one is largely out of our hands and depends on the individual app / how Flutter rebuilds.

I could add callbacks for the first 2 instances, but not the 3rd. I could either:

1. Merge these two callbacks into onBuildViewModel or something like that
2. Keep them separate: onFirstBuild and onDidChange.

[AlexandreRoba]

Having them separated gives us the option to handle them differenlty if needed… Might be the safer choice but again.. Not an expert :) Sent with Unibox

…

On Jun 11, 2018, at 11:58 AM, Brian Egan ***@***.***> wrote: Hey hey, thanks again for all your feedback -- yah, it's a bit tricky since there are some intricacies in how builds are handled in Flutter. There are 3 types of builds that could happen: The first time the ViewModel is created and the builder function is run. Every time the ViewModel changes (not the App State necessarily, as you could use distinct to limit the number of rebuilds for performance reasons) Whenever Flutter decides it needs to rebuild the Widget. This could happen if the user rotates the screen, or if a Widget above the StoreConnector request a rebuild, or if the user navigates to a new route. This one is largely out of our hands and depends on the individual app / how Flutter rebuilds. I could add callbacks for the first 2 instances, but not the 3rd. I could either: Merge these two callbacks into onBuildViewModel or something like that Keep them separate: onFirstBuild and onDidChange . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .<embedded image>

[brianegan]

Cool, thanks again. That was my gut feeling as well, so I'll go that route.

[dviluk]

brianegan commented 8 days ago

Hey hey, thanks again for all your feedback -- yah, it's a bit tricky since there are some intricacies in how builds are handled in Flutter. There are 3 types of builds that could happen:

1. The first time the ViewModel is created and the builder function is run.
2. Every time the ViewModel changes (not the App State necessarily, as you could use distinct to limit the number of rebuilds for performance reasons)
3. Whenever Flutter decides it needs to rebuild the Widget. This could happen if the user rotates the screen, or if a Widget above the StoreConnector request a rebuild, or if the user navigates to a new route. This one is largely out of our hands and depends on the individual app / how Flutter rebuilds.

4. also when you open the keyboard

[brianegan]

Hey all -- this change has now been published as part of flutter_redux 0.5.2. Please play around and let me know whatcha think / if ya run into trouble :)