-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
feat(Sticky|Visibility): add scroll context #1978
feat(Sticky|Visibility): add scroll context #1978
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1978 +/- ##
=========================================
+ Coverage 99.8% 99.8% +<.01%
=========================================
Files 148 148
Lines 2568 2572 +4
=========================================
+ Hits 2563 2567 +4
Misses 5 5
Continue to review full report at Codecov.
|
@mariolamacchia Thanks. |
@mariolamacchia Seems to work as expected. My positioning requirements can be likely be handled using the on* events and css. Thanks for the rapid PR. |
@mariolamacchia I spoke too soon. You didn't change the hardcoded window.* to use the scrollContext instead.
->
Sticky sections are staying visible and stacking up as I scroll. |
@@ -9,6 +9,9 @@ export interface VisibilityProps { | |||
/** Primary content. */ | |||
children?: React.ReactNode; | |||
|
|||
/** Context which sticky element should stick to. */ | |||
context?: object; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd assume the description here would match the Visibility component:
/** The scroll context visibility should use. */
src/modules/Sticky/Sticky.js
Outdated
@@ -66,11 +66,15 @@ export default class Sticky extends Component { | |||
|
|||
/** Whether element should be "pushed" by the viewport, attaching to the bottom of the screen when scrolling up. */ | |||
pushing: PropTypes.bool, | |||
|
|||
/** Context which sticky should attach `onscroll` events. */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Let's match the style of the typings comment, no backticks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm using the same descriptions from the SemanticUI docs. I'll use this one, without backticks, for both
src/modules/Sticky/Sticky.js
Outdated
@@ -66,11 +66,15 @@ export default class Sticky extends Component { | |||
|
|||
/** Whether element should be "pushed" by the viewport, attaching to the bottom of the screen when scrolling up. */ | |||
pushing: PropTypes.bool, | |||
|
|||
/** Context which sticky should attach `onscroll` events. */ | |||
scrollContext: PropTypes.object, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on the usage, looks like these should be .isRequired
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same as below
@@ -20,6 +20,9 @@ export default class Visibility extends Component { | |||
/** Primary content. */ | |||
children: PropTypes.node, | |||
|
|||
/** The scroll context visibility should use. */ | |||
context: PropTypes.object, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs to be .isRequired
here given usage in code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a default value of window
. isRequired
means that the user must specify the value, right?
I'm curious as to the reasoning behind <Visibility context={div} />
<Sticky scrollContext={div} /> |
@TimNZ |
@levithomason I'm using the names from the SemanticUI docs, although it isn't very consistent:
|
Thanks for the explanation @mariolamacchia, let's keep the parity for now then 👍 |
Released in |
Visibility BREAKS server side rendering!!! |
Hi @mariolamacchia, thank you for adding the context prop for the Visibility component! 👍 👍 for moving so fast on this. However, I've tried using it and |
@frogbandit we have a new component being added to the library to solve this issue, #1879. It is a Stateless functional components do not support refs, so we cannot be sure that a component passed in on |
Fixes #1959.