I came across the advice “assume that build might get called every frame” just today, and ah shit okay I might understand what’s happening, it’s doing the whole comment sorting algorithm each frame during transition animations (this doesn’t explain laggy scrolling though). Incidentally I was just coding up another view that stows query results instead of regenerating them each time.
Why the hell is it doing this in page transition animations though. The layout of the widgets in the next page doesn’t change during the animation and it would be a terrible transition animation if they did.
Why the hell is it doing this in page transition animations though. The layout of the widgets in the next page doesn’t change during the animation and it would be a terrible transition animation if they did.
It’s up to the developer whether or not the layout of the widgets in the next page change in the transition.
If you do fancy transitions like using the hero widget, you will get changes in the layout every frame.
This is Flutter allowing developers to do fancy graphics that they wouldn’t be able to do with other frameworks.
In the usecase of changing the sorting of comments a hero widget would even make sense (with the comment id as tag). If every comment has it’s own hero widget that would result in the user seeing on the screen how the comments move into their new positions.
You might not care about animations like the comments moving into the new order from the old order but’s the kind of thing Flutter can do. “Flutter is beautiful” and be as being one of it’s selling points besides the cross-platform nature of Flutter but animations like hero transitions are what you easily get with Flutter but not as easy in native development.
Incidentally I was just coding up another view that stows query results instead of regenerating them each time.
Flutter doesn’t have an internal concept that corresponds to the word view. Thinking in those terms might produce confusion.
If you use Bloc you would have a Bloc that receives events like (sort by length, sort by time, sort by vote) and outputs the comments in sorted form then a BlocBuilder widget that listens to the state from the Bloc and then renders the comments.
There are a bunch of different state management solutions besides Bloc that you can use but if you don’t use any existing state management library that’s likely sets you up for some pains.
You want separation of concerns where the UI is separated from the state management and the order of the comments are the state of the app.
As far as build being called frequently it’s worth noting that this doesn’t automatically mean that anything is redrawn. Internally, the build method produced an element tree and when the element tree is the same nothing actually gets redrawn. Only the elements that are changed get redrawn.
I came across the advice “assume that
buildmight get called every frame” just today, and ah shit okay I might understand what’s happening, it’s doing the whole comment sorting algorithm each frame during transition animations (this doesn’t explain laggy scrolling though). Incidentally I was just coding up another view that stows query results instead of regenerating them each time.Why the hell is it doing this in page transition animations though. The layout of the widgets in the next page doesn’t change during the animation and it would be a terrible transition animation if they did.
It’s up to the developer whether or not the layout of the widgets in the next page change in the transition.
If you do fancy transitions like using the hero widget, you will get changes in the layout every frame.
This is Flutter allowing developers to do fancy graphics that they wouldn’t be able to do with other frameworks.
In the usecase of changing the sorting of comments a hero widget would even make sense (with the comment id as tag). If every comment has it’s own hero widget that would result in the user seeing on the screen how the comments move into their new positions.
You might not care about animations like the comments moving into the new order from the old order but’s the kind of thing Flutter can do. “Flutter is beautiful” and be as being one of it’s selling points besides the cross-platform nature of Flutter but animations like hero transitions are what you easily get with Flutter but not as easy in native development.
Flutter doesn’t have an internal concept that corresponds to the word view. Thinking in those terms might produce confusion.
If you use Bloc you would have a Bloc that receives events like (sort by length, sort by time, sort by vote) and outputs the comments in sorted form then a BlocBuilder widget that listens to the state from the Bloc and then renders the comments.
There are a bunch of different state management solutions besides Bloc that you can use but if you don’t use any existing state management library that’s likely sets you up for some pains.
You want separation of concerns where the UI is separated from the state management and the order of the comments are the state of the app.
As far as build being called frequently it’s worth noting that this doesn’t automatically mean that anything is redrawn. Internally, the build method produced an element tree and when the element tree is the same nothing actually gets redrawn. Only the elements that are changed get redrawn.