-
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(Sidebar): add component #905
Conversation
Current coverage is 99.74% (diff: 78.57%)@@ master #905 diff @@
========================================
Files 137 140 +3
Lines 2286 2314 +28
Methods 0 0
Messages 0 0
Branches 0 0
========================================
+ Hits 2286 2308 +22
- Misses 0 6 +6
Partials 0 0
|
c488d15
to
ecabd5f
Compare
Wow, thanks! I'll get a review on this as soon as I can 😸 |
So excited for this one 🐶 |
@levithomason - I know you're super-busy - any chance you can review this week? 😁 |
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.
We need to figure out an API for the pushable/pusher. Given that these can appear anywhere in the tree, my first thought is a component/subcomponent. I believe it is only applicable to the Sidebar, so perhaps Sidebar subcomponents would make sense?
<Sidebar.Pushable>
...
<Sidebar />
<Sidebar.Pusher />
<Sidebar.Pushable />
This also follows our <Dimmer.Dimmable />
pattern and allows us to add props and features to each individually.
Pushable body
There is also the need to make the body
element pushable
for full page Sidebars. We could again borrow from the Dimmer.Dimmable
component and provide a page
prop which, like a page
Dimmer affects the body
, it would make the entire page pushable:
<Sidebar.Pushable page />
This might even make more sense as a Sidebar prop, since there is no need to place the "pushable" element in the tree and no need to support "pushable" children since it is only adding/removing the className to the body
:
<Sidebar page />
This would also need to render the Sidebar to the body using the Portal. It also would need to render a pusher
to the body.
Inspecting SUI core docs for full page Sidebars, this might be problematic. The pusher needs to wrap the React app mount node in order to work. I'm not sure on how to go about this since modifying React's render tree will break it. I'll leave it at this for now. Here is the markup required by SUI, per the core docs:
<body class="pushable">
<div class="sidebar"></div>
<div class="pusher">
<div class="root">my react app</div>
</div>
</body>
Given the tricky issues here, I'm OK adding page level pushers on a separate PR as I suspect it is going to be fairly involved.
Pusher
I think the <Sidebar.Pusher />
API makes sense in and applies to all use cases here. It seems it is always required. LMK if you disagree or see a better API.
Dimmed Pusher
The pusher can also be dimmed, http://semantic-ui.com/modules/sidebar#dimmed. My first thought on this is <Sidebar.Pusher dimmed />
. Let's add this for now.
I think in an ideal workflow something like a <Pusher dimmable />
would dim itself when the Sidebar was active. I have a couple ideas for this, but again, let's consider auto dimming on a separate PR and this one will just add the simple prop dimmed
.
I've left an initial review, this looks really great so far, thanks! |
Ah, I like the suggestions, I'll get on making them. Though with the holidays it might have to wait until next week. Hopefully I'll get to it sooner. I'll comment when it's ready for another review |
Added Sidebar.Pushable and Sidebar.Pusher with docs. |
Dynamic
|
Releasing this now, massive thanks @UnbrandedTech! |
Don't thank me, thank @fracmak. He Literally did all the work! |
Oh snap! Getting my friends confused there :D Thanks @fracmak! |
woo! excited to see this land! |
Any good practice how to hide the sidebar when click on any place outside its area and on a menu item? |
I would say using a click handler on the outer element that's controlling the visibility of the sidebar would be enough since click events bubble. You can then add a click handler to the sidebar itself to preventDefault() if the click wasn't on a link. |
|
||
this.setState({ animating: true }) | ||
|
||
this.stopAnimatingTimer = setTimeout(() => this.setState({ animating: false }), duration) |
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 was thinking about it, any reason we aren't using the transitionend event to trap the animation finishing instead of hard coding 500ms?
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 actually did not know about this event, thanks for pointing it out. The primary reason I added this hack was because we have a Transition component that will soon be merged and take over this task, #813.
Support for this event seems solid, I'd merge a PR updating this bit of code if you want to open one.
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'll work on this later this week, there's one gotcha with the event, if the tab/browser isn't active, those events never fire, so you have to be careful with handling that edgecase
Fixes #197, Replaces PR #774.
Adds component with examples