-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
fix: Remove open prop of SlideOverPanel
#104627
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
fix: Remove open prop of SlideOverPanel
#104627
Conversation
Instead, we expect the panel to be rendered conditionally.
SlideOverPanelopen prop of SlideOverPanel
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #104627 +/- ##
========================================
Coverage 80.52% 80.52%
========================================
Files 9330 9330
Lines 400755 400740 -15
Branches 25695 25689 -6
========================================
- Hits 322721 322713 -8
+ Misses 77568 77563 -5
+ Partials 466 464 -2 |
| </Container> | ||
| </SlideOverPanel> | ||
| {isPanelOpen && ( | ||
| <SlideOverPanel position="right"> |
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.
@gggritso how would you feel about about making SlideOverPanel extend the Container component? Does that make sense and would it be helpful? The reason I ask is because having a child container with border=primary feels like it's specifying border on the wrong component
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.
That sounds like a good idea! If we do that,
- I could throw out the
panelWidthprop and let people pass in a width more naturally, if needed - I could set some good default styles, like a left border (missing in some UIs) and maybe a little box shadow on the left for depth
- Get rid of some wrapper elements, like you pointed out
TkDodo
left a comment
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.
great work 🙌
It's not used, let's just get rid of it.
As of #104627, the contents of the Widget Builder are "deferred", which means that the panel opens up early, and the contents render while it's animating. Unfortunately by default, the panel is blank while loading. This PR adds a loading skeleton with placeholders. I also had to change how we set up the intersection observers. In short, we can't use normal refs anymore because the containers for the chart mount _late_. Instead, I'm using callback refs, which fire once the elements are mounted. **e.g.,** https://github.com/user-attachments/assets/0549f98a-19c1-482c-b6c0-743e05b1628f This PR is best enjoyed with whitespace off!
Right now,
SlideOverPanelcan be opened/closed by passing<SlideOverPanel open={isPanelOpen}or by conditionally rendering it withisPanelOpen && <SlideOverPanel. This is problematic because when there are two ways to open/close something, it means there are multiple ways we need to account for when thinking about animations and deferring rendering the contents.This PR removes the
openprop.SlideOverPanelnow must be rendered conditionally with&&in JSX. This required an update to how the contents are deferred on mount, but otherwise behaviour is preserved.I was pushed towards the
isOpen &&API due to a practical problem in Dashboards, but I also think it's a reasonable choice overall.Rationale
Consider:
Imagine that the container has a panel, and a preview which both take up half the screen and slide in from opposite sides. The container takes up the full screen, and is shown over some background content. It's offset against the main sidebar.
There are two major problems.
display: none. The former is messy, and error prone. It's easy to accidentally leave this in, and cause issues with clicks. The latter is difficult, how do I coordinate settingdisplay: nonevs. the panel and preview when they slide? This is the case in the Widget Builder.Containerfor some reason? e.g., the container might have some kind of context, or something else that needs to be remounted or re-rendered that might cause a re-mount of the panel. In that case, deferring the content of the panel won't work, since it's relying on theopenprop state changing, but on initial mount there is no change. This is also the case in the Widget Builder. It's not possible to have a deferral mechanism that works both on mount and on prop change!If the API is
isOpen &&these problems are solved. I can just mount/unmount the entire tree, and everything works as expected. Since there is only one way to show/hide the panel, I can use one deferral method, and I don't need explanations in the doc for how to handle animations and deferral.In short, controlling mounting/unmounting is a lot easier than controlling an
openprop because I don't have to worry about keeping surrounding components in the DOM just to make animations and deferred rendering work.