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

Fix: Recalculate height of ZoomElement when child element updates #15472

Conversation

Tomastomaslol
Copy link
Member

@Tomastomaslol Tomastomaslol commented Jul 3, 2021

Issue: #15368

What I did

  • Removed duplicated never called function browserSupportsCssZoom
  • Added an observer to "watch" for changes in child elements
  • Update calculated height when child elements are updated

In browsers without support for CSS zoom the height of the element needs to be known to be able to simulate zoom using transform. When the height of the child ZoomElement updates the height needs to be re-calculated.

New behavior

Kapture.2021-12-19.at.11.40.19.mp4

Current behavior

Kapture.2021-12-19.at.12.15.54.mp4

@nx-cloud
Copy link

nx-cloud bot commented Jul 3, 2021

☁️ Nx Cloud Report

CI is running/has finished running commands for commit f7739fb. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch


✅ Successfully ran 1 target

Sent with 💌 from NxCloud.

@darleendenno
Copy link
Contributor

Hey @Tomastomaslol is this ready for review?

@Tomastomaslol
Copy link
Member Author

Hi @darleendenno! Sorry, I took a long break from this PR to focus on other things.

I think I have figured out a decent solution to the issue described in #15368 and I'm planning to spend some more time improving the code and "productionize" it before it's ready for review.

I will let you know when I'm happy with the code and update the status of the PR. 🙂

@Tomastomaslol Tomastomaslol changed the title FIX: Removed duplicated function browserSupportsCssZoom Fix: Recalculate height of ZoomElement when child element updates in browsers that does't support CSS zoom Dec 19, 2021
@Tomastomaslol Tomastomaslol changed the title Fix: Recalculate height of ZoomElement when child element updates in browsers that does't support CSS zoom Fix: Recalculate height of ZoomElement when child element updates Dec 19, 2021
@stale
Copy link

stale bot commented Jan 9, 2022

Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks!

@stale stale bot added the inactive label Jan 9, 2022
…368-ZoomElement-do-not-resize-on-child-resize
@stale stale bot removed the inactive label Jan 18, 2022
@Tomastomaslol Tomastomaslol marked this pull request as ready for review January 18, 2022 07:27
@Tomastomaslol Tomastomaslol requested a review from shilman January 18, 2022 07:27
@ndelangen
Copy link
Member

@ghengeveld perhaps this is something you could take a look at? This seems like exactly the type of UI/UX/DX thing you'd be keen to review/comment on?

@shilman with the upcoming work on docs in future/base, how easy is it for this to be applied there too?

Does this change still really do anything when rendering in modernInlineRendering (which will be the default in 7.0 anyway @shilman @tmeasday ?

This feature seems like a no-brainer to me: of course should the height of the container grow with the size of the story's html output! But I find it hard to judge wether this implementation will be compatible with how things will be in 7.0.

@Tomastomaslol FYI, we've sort of feature-locked 6.x and focussed our full attention on cleaning the codebase modernizing it, so it can scale better and remove the many deprecations and mistakes we made (we all make them, right?).
Hence even though this is a clearly important feature, I'm not sure we can merge soon, and I'm pretty sure if it's merged it will be for 7.0, not 6.x.

Thanks for all your hard work, energy and skill on this PR!

@tmeasday
Copy link
Member

Does this change still really do anything when rendering in modernInlineRendering (which will be the default in 7.0 anyway @shilman @tmeasday ?

I'm not sure modern inline rendering really changes the behaviour of this component @ndelangen? Can you explain what you were thinking here, I'm missing something I think.

I think this PR should be considered as part of the doc blocks 2.0 work. I'm not quite sure what the exact plan is there @shilman.

@ndelangen
Copy link
Member

@tmeasday with inline rendering, the size of the container will just auto-update. so there's no need to keep it in sync, because the layout engine is doing that the natural way.
That's what I was referring to.

}): void => {
const observer = useMemo(
() =>
typeof MutationObserver === 'function'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need this check, MutationObserver has been available in all browsers since 2014. Save for Opera Mini which frankly nobody is going to be using to view their Storybook in anyway.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I strongly agree with this, Storybook 7.0 will target chrome100. If it's supported in there, don't bother downgrading, transpiling, of feature detecting!

useEffect(() => {
if (componentWrapperRef.current) {
setHeight(componentWrapperRef.current.getBoundingClientRect().height);
}
}, [scale, componentWrapperRef.current]);

useMutationObserver({
element: componentWrapperRef,
options: { subtree: true, childList: true },
Copy link
Member

@ghengeveld ghengeveld Jul 1, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

options should be defined outside the component render function (or memoized, but that seems silly), otherwise we'll have a new object with each render, which will cause the useEffect above to disconnect and re-observe each time.

@ghengeveld
Copy link
Member

Some small remarks but other than that (and PR checks) this LGTM.

return (
<ZoomElementWrapper scale={scale} height={height}>
<div ref={componentWrapperRef} className="innerZoomElementWrapper">
<div
ref={browserSupportsCssZoom() ? null : componentWrapperRef}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can just call browserSupportsCssZoom once, outside the component render function, put it in a variable and use that here. Otherwise we'll be running this check over and over again.

@ndelangen
Copy link
Member

ndelangen commented Jul 1, 2022

Thanks for the review @ghengeveld 🤝

@tmeasday
Copy link
Member

tmeasday commented Jul 4, 2022

@tmeasday with inline rendering

@ndelangen well if you are talking about inline rendering, then that hasn't changed in 7.0. The default was to inline render already. What's changed is the mechanism to do it, which doesn't affect how the browser lays things out AFAIK. I guess this is useful for non-inline mode? Although TBH I wasn't aware that a mutation observer would work there..

@ndelangen ndelangen merged commit 7690577 into storybookjs:next Sep 14, 2022
@Tomastomaslol Tomastomaslol deleted the issue-15368-ZoomElement-do-not-resize-on-child-resize branch September 26, 2022 00:47
jrencz added a commit to jrencz/storybook that referenced this pull request Feb 20, 2023
Problem, as described in [this thread](storybookjs#21138 (review))
affects stories rendered with custom elements using Shadow DOM. Such
stories are affected if at the moment ZoomElement measures the height,
component did not yet render its contents. Then, when component in a
story renders content, it doesn't trigger MutationObserver (mutation
callback is not called when Shadow DOM is altered).

ResizeObserver is added next to MutationObserver (orignally added via
storybookjs#15472), not replaces it, because MutationObserver is better supported
by older browsers than ResizeObserver.

Problem, as described in the original thread was mitigated by @JReinhold
with storybookjs#21163, but even after that fix Safari is excluded from using native
`zoom` and needs the fallback behavior.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants