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

Floating Button Behaviour #7

Closed
clragon opened this issue Nov 19, 2021 · 18 comments · Fixed by #8
Closed

Floating Button Behaviour #7

clragon opened this issue Nov 19, 2021 · 18 comments · Fixed by #8

Comments

@clragon
Copy link
Contributor

clragon commented Nov 19, 2021

The scroll to top button currently appears at a fixed scroll off-set.

I would be very interested in a behaviour similar to the SliverAppBar with floating: true,
where the button would only appear if the user is scrolling up.

(I also hope I am not too annoying with all the requests)

@NamanShergill
Copy link
Owner

Hmm, how do you think that should be implemented? Would a gesture detector detecting a scroll up be enough?

@NamanShergill
Copy link
Owner

(I also hope I am not too annoying with all the requests)

No please, any feature requests to improve the library are welcome!

@clragon
Copy link
Contributor Author

clragon commented Nov 20, 2021

Would a gesture detector detecting a scroll up be enough?

Probably? I tried looking at how the slivers do it in the source code, but its convoluted, so I didnt figure it out.

@NamanShergill NamanShergill mentioned this issue Nov 21, 2021
Merged
@NamanShergill
Copy link
Owner

@clragon can you check out #8 if that is the implementation you are looking for?

@NamanShergill NamanShergill linked a pull request Nov 21, 2021 that will close this issue
Merged
@clragon
Copy link
Contributor Author

clragon commented Nov 21, 2021

oh yeah this is brilliant.

I was thinking it might even be nice to have a small off-set that the user has to scroll up before it shows up,
(which could be configured, like the promptScrollOffset)
but that might complicate the implementation alot.

@NamanShergill
Copy link
Owner

oh yeah this is brilliant.

I was thinking it might even be nice to have a small off-set that the user has to scroll up before it shows up, (which could be configured, like the promptScrollOffset) but that might complicate the implementation alot.

yeah, it will be hard to account for all the edge cases. I will release this implementation for now and update it later if I can think of a consistent way to implement that

@clragon
Copy link
Contributor Author

clragon commented Nov 21, 2021

maybe something like tracking the point at which the user first started scrolling up (when the scroll notification gets triggered) and whenever the user scrolls we compare it to the offset.
when a down-scrolling notification occurs, we simply set the point of first scrolling up to null again.

@NamanShergill
Copy link
Owner

@clragon Added in the PR, is that what you required?

Also I am having trouble with the parameter names being clear with their purpose so if you think they should be renamed to something else please let me know

@clragon
Copy link
Contributor Author

clragon commented Nov 21, 2021

this works wonderfully!
I dont think I can come up with any better names.

Though I think the doc string for scrollOffsetUntilVisible is incorrect?

If alwaysVisibleAtOffset is true, what offset should the user scroll in the opposite direction (ex, upwards scroll on a non-reversed vertical ScrollView) before the prompt becomes visible.

doesnt this only trigger when alwaysVisibleAtOffset is false?

@NamanShergill
Copy link
Owner

Right, I'll fix that

@clragon
Copy link
Contributor Author

clragon commented Nov 21, 2021

it also seems that the button will not show up in a NestedScrollView, if alwaysVisibleAtOffset is false,
and a scrollcontroller is passed to both the NestedScrollView and the ScrollWrapper.

I assume thats because of how the NestedScrollView works.

@NamanShergill
Copy link
Owner

NamanShergill commented Nov 21, 2021

it also seems that the button will not show up in a NestedScrollView, if alwaysVisibleAtOffset is false, and a scrollcontroller is passed to both the NestedScrollView and the ScrollWrapper.

I assume thats because of how the NestedScrollView works.

It's working fine for me, did you add NestedScrollView.sliverOverlapAbsorberHandleFor(context); to handle the overlap between the header and body, in a builder function inside the body? It's possible that it is showing up but is hidden behind the header due to the overlap.

Example:

NestedScrollView.sliverOverlapAbsorberHandleFor(context);

@NamanShergill
Copy link
Owner

Ah, wait.

The issue here is you are not supposed to pass a scroll controller in that case @clragon
That is how it works with ScrollViews inside the body of NestedScrollView, they are supposed to use the PrimaryScrollController

@clragon
Copy link
Contributor Author

clragon commented Nov 21, 2021

ah, I see. Yeah, I kind of suspected that.

@NamanShergill
Copy link
Owner

If you pass a scroll controller to a CustomScrollView without using the ScrollWrapper you will face a similar issue, where the CustomScrollView will start scrolling free from the NestedScrollView

@NamanShergill
Copy link
Owner

I will add a warning in the readme for this

@NamanShergill
Copy link
Owner

The new version is up on pub.dev

@clragon
Copy link
Contributor Author

clragon commented Nov 21, 2021

very nice 👌

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

Successfully merging a pull request may close this issue.

2 participants