-
Notifications
You must be signed in to change notification settings - Fork 485
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
[Sheet] Triggering a re-build in child widget within the first 200ms or so seems to fully break the bottom sheet #372
Comments
Been looking a bit into reproducing it. It seems that the issue may be because, when my widget rebuilds, the bottom sheet checks for the bottom sheet closing threshold. Given that the state changed while the bottom sheet is opening, that threshold is not met and instead it closes back automatically. |
I have a similar issue. My sheet is closing on re-renderings but only on some devices. Which seems to be caused by the closing threshold. Did you find a solution? |
@codeOfJannik No. I decided to temporarily stick with the older |
I faced the same issue when my child widget is a ListView.builder I have solved it by changing stops parameter from [0,1] to [1] |
I confirm this works! I've have also had major issues with sheet and using riverpod but also other widgets like ExpansionTile while using initialExpanded. Just adding [1] to stops property for example CupertinoSheetRoute makes everything work. Thank you mohamad-jawad |
The following structure of the code, and there are cases of asynchronous changes to the widget such as bloc/provider (just changing the text of the text does not count)
Solution: SingleChildScrollView must be work with a ScrollController I traced the sheet source code, and guessed that the widget rebuilt the position, so I tried to add a ScrollController to the SingleChildScrollView to control its scrolling behavior, and unexpectedly, everything worked fine when I added the ScrollController. I don't know how it works, maybe you guys can submit a PR to fix it |
@gukong No idea how/if your solution works (I did not try it). But be careful because P.s. once you properly manage the reusability/disposal of the scroll controller your solution might stop fixing the bottom sheet problem. |
@AlexDochioiu Sorry, the code above is just a simple example. I'm managing the lifecycle of the ScrollController in the StatefulWidget, and yes, the ScrollController is destroyed in the disposed method. So far, he's working. Also, I found another solution that doesn't require a ScrollController to be set. Replacing CupertinoPageScaffold with Material, the issue of sheet not displaying has been unexpectedly fixed. Also again, I don't know how it works.😆 |
Yes, eventually I found the code that caused the sheet to not appear The
As for why it's 1.0, because when I print the log, pixels are 1.0. yeah, it's not elegant |
Another thing, the pre answer is not correct, controller should set to |
any update to this? I have the same problem. It happens when some widget in scroll changes its size, then bottom sheet closes |
PR #432 should resolve this problem. The current workaround for using the PR commit in dependency_overrides:
sheet:
git:
url: https://github.com/jamesblasco/modal_bottom_sheet.git
ref: dba14d95a8d90060fdf6ab4b5d9a50f14e1ad28b
path: sheet |
i also forked the repo and merged PR #432 with another few fixes. |
I am using a (riverpod) Consumer Widget which gets built by
builder
when pushing SheetRoute. This widget starts on a loading state but very quickly changes to a data state (after checking some database value).This causes the bottom sheet to not come up at all anymore. I can however see the barrier, and click on it to dismiss. Adding an artificial delay of 250ms when changing from
Loading
toData
state seems to fix this issue.P.s. This issue does not happen with the official bottom sheet (from material package) and with the old modal_bottom_sheet package. Seems to be limited to the
Sheet
package.The text was updated successfully, but these errors were encountered: