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

Custom functions to determine whether or not to pin/unpin headroom element #96

Closed
jeffshaver opened this issue Jul 9, 2014 · 6 comments · May be fixed by #125
Closed

Custom functions to determine whether or not to pin/unpin headroom element #96

jeffshaver opened this issue Jul 9, 2014 · 6 comments · May be fixed by #125

Comments

@jeffshaver
Copy link

In a modified version of this that I changed, I added the ability to pass in two new options: shouldPinCheck and shouldUnpinCheck (couldn't think of better names). These are functions that must return true/false. They are fired inside the shouldPin/shouldUnpin functions in the return statement.

Therefore, if a headroom goes to unpin and the shouldUnpinCheck returns false, the headroom element shouldn't be unpinned. Same thing for the shouldPinCheck but opposite.

If it was useful to me, I thought it may be useful to someone else as well. Maybe this should be added into the codebase.

@mdarens
Copy link

mdarens commented Jul 10, 2014

👍 but maybe call them beforeUnpin and beforePin?

@jeffshaver
Copy link
Author

Those names work for me. I am not the best at coming up with function names xD

@WickyNilliams
Copy link
Owner

this has previously been discussed. the idea was to have the same thing but cancel the action if the regular onPin/onUnpin callbacks returned false. thoughts? this would negate the need for yet more callbacks/options

@gmclelland
Copy link

I think this would solve my problem of having the mobile menu disappear when the page is scrolled on a mobile device.
I could run a custom function on beforPin to check if the menu is open. If the menu is open then disable headroom.

@jeffshaver
Copy link
Author

@WickyNilliams This comment is a little late, but that would work for me.

@WickyNilliams
Copy link
Owner

Closing as this is effectively a duplicate of #38 and the PR #125 offers a potential solution

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.

4 participants