Fixed
Status Update
Comments
cl...@google.com <cl...@google.com>
cl...@google.com <cl...@google.com> #2
I'm not sure what you mean by onSizeChanged. Which size? Children of the scroller?
In this case, how do you expect onSizeChanged modifier behave differently from onPositioned other than performance?
In this case, how do you expect onSizeChanged modifier behave differently from onPositioned other than performance?
ap...@google.com <ap...@google.com> #3
Sorry, the scroller thing was just an example of when a onPositioned
would be call a lot without the size changing.
In this case, how do you expect onSizeChanged modifier behave differently from onPositioned other than performance?
I imagine it would act similarly, but only for the size, and not position.
ap...@google.com <ap...@google.com> #4
Oh, I see, thanks for explaining.
I imagine notification only about size change can have some performance wins against position + size notification..
Cc-ing Andrey and reassigning to George, they both have some insights I'm sure. It would be handy to have `Modifier.onSizeChanged`, especially it it will be faster
I imagine notification only about size change can have some performance wins against position + size notification..
Cc-ing Andrey and reassigning to George, they both have some insights I'm sure. It would be handy to have `Modifier.onSizeChanged`, especially it it will be faster
Description
This is partially in response to
A sample use case is when db write happens but the paging source does not invalidate in time, resulting in paging source loading wrong data.