-
-
Notifications
You must be signed in to change notification settings - Fork 32.5k
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
[Masonry] Observe every masonry child to trigger computation when needed #29896
Conversation
@material-ui/lab: parsed: -0.09% 😍, gzip: -0.12% 😍 |
Even though it fixes the issue but I am not sure if this is the experience most people want because the masonry item shifted when there are spaces available. @danilo-leal Do you think this is weird from a designer's perspective? Screen.Recording.2564-11-26.at.14.14.17.mov |
Also, another demo should be added to the docs. 😊 |
That is the property of masonry though. The next item is pushed to the shortest column.
Ah, good call :) |
I agree it looks a bit odd :\ @hbjORbj could you link how other Masonry implementations behave in this scenario? Just to do some benchmarking |
In fact, I think I may be able to come up with a solution so that those masonry items can maintain the original order. I can figure out if computation is running due to a change in masonry item's "height" and then do not set new
Sure I will look. |
The behavior is weird to me too but after quickly looking at other Masonries out there, it seems that this is indeed how they behave if the column max height size is filled?! (As Benny mentioned). What made it confusing though was that the cards moved to different columns without any transition/animation whatsoever, so I felt lost. I know it's a different interaction (drag and drop), but I think we could draw some inspiration from https://muuri.dev/. Check their Grid Demo — how each tile moves smoothly whenever you change some of them from their place. It's just an idea. I haven't interacted with a Masonry with Accordions out on the wild yet to be able to contribute with confidence, so I'm just thinking out loud... |
@danilo-leal I agree with you. I will definitely check it out!! |
resizeObserver.observe(container.firstChild); | ||
} | ||
if (masonryRef.current) { | ||
masonryRef.current.childNodes.forEach((childNode) => { |
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.
Shouldn't we still observe the masonry container?
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.
Ok, I got it from the PR description, nevermind :)
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.
Changes look good, I've tested the new sandbox, looks much better. Before we merge, let's add new demo illustrating this (something similar to the codesandbox could be beneficial).
Also, please add some unit tests, to make sure we don't break this again in the future.
I added a demo and a test :) Since a number of issues need this PR to be merged, as @mnajdova suggested, I will go ahead and merge this once approved, and then look into the animation effect @danilo-leal suggested in a separate PR. cc @siriwatknp |
@material-ui/lab: parsed: -0.09% 😍, gzip: -0.12% 😍 |
Closes #29692
Closes #30453
Before:
ResizeObserver API
was only observing the masonry container and the first child (which we expected will cause issues in the future). As a result, changes in the dimension of children other than the first do not trigger computation (needed for correct layout of masonry). Code sandboxAfter:
ResizeObserver API
no longer observes the container but now it observes every children. Code sandboxPreview: https://deploy-preview-29896--material-ui.netlify.app/components/masonry/#main-content