[Masonry] Add a Masonry Component

[antoniopacheco]

• [ x] I have followed (at least) the PR section of the contributing guide.

fixes: #17000

TODO:

create better documentation
Create unit testing (I'm not familiar with Chai, so I would appreciate someone with more knowledge in this topic)
when
#23885 is done
we should either add examples on how the parent component can use the hook to send the current columns count
or use it inside of the component and allow a new param similar to:
https://next.material-ui.com/system/basics/#responsive-values

[mui-pr-bot]

Details of bundle changes

Generated by 🚫 dangerJS against 9f0f9ff

[mbrookes]

@antoniopacheco Appreciate you working on it, but if this has the same limitations of the v5 ImageList masonry variant component, what's the benefit of having a separate component for it?

[antoniopacheco]

@mbrookes thr imagaMasonry component renders children top to bottom.
For instance

Child1. Child3
Child2. Child4

This component will render it like:

Child1. Child2
Child3. Child4

[mbrookes]

Ah, got it, so it's the accessibility tree & tab index that's out of order.

[antoniopacheco]

Yes, that’s correct Matt, and this component might be dropped once all major browsers supports Masonry layout Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Matt <[email protected]> Sent: Saturday, December 12, 2020 1:01:52 PM To: mui-org/material-ui <[email protected]> Cc: Jesus Antonio Pacheco Morales <[email protected]>; Mention <[email protected]> Subject: Re: [mui-org/material-ui] [Masonry] Add a Masonry Component (#23954) Ah, got it, so it's the accessibility tree & tab index that's out of order. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#23954 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABSI2JGCDPSUA7OZEBXRARLSUPK4BANCNFSM4UV765CA>.

[mbrookes]

Looking at the code, it seems that this is simply reordering the data to put every <n>th item into its respective column:

https://github.com/mui-org/material-ui/blob/9f0f9ffe247839410e852e91872da6811cd74b15/packages/material-ui-lab/src/Masonry/Masonry.tsx#L32-L47

A masonry layout adds each item to the shortest column instead.

[oliviertassinari]

@antoniopacheco Regarding #23885, I don't think that we need to solve it in order to get a viable first version of the Masonry component in the lab. However, from my perspective, we can implement it in a different pull request but it would be great to get the perspective from other core team members on this API.

[oliviertassinari]

@antoniopacheco What's the next step with this effort? Having a quick view, it seems that we can:

• use the new styling approach of v5
• simplify the first demo. It should be dead simple, not a playground.
• add the missing chips/badges in the docs
• improve the tests
• fix the CI

Now, this was on the surface, if we focus more on the problem itself, the best source of information I could find is on: https://github.com/paulcollett/react-masonry-css/issues?q=is%3Aissue+. Some of the features we want but that we will likely need to make tradeoffs for:

1. SSR
2. Responsive number of columns
3. Logical tab index
4. Logical a11y read content
5. Animation when changing grid positions
6. Infinite loading
7. Drag and drop

I think that:

• 7 6 5 will need a JavaScript-based logic.
• 2 and 3 can only be solved at the same time if we rely on JavaScript or set the size, up-front.

How about the following solution:

• We start with the simplest features, no drag & drop, infinite loading, animation
• We implement a useResizeObserver hook Add ResizeObserver abstraction #22519.
• We implement the solution of https://w3bits.com/css-grid-masonry/. It solves 1, 2. 3. 4. It has the benefit to rely on the CSS grid.

@antoniopacheco @mbrookes what do you think :)?

[mbrookes]

What do you think about the proposed solution?

https://w3bits.com/css-grid-masonry/ ? I'll be kind, and call it a clever hack. But it comes with limitations, not least that the height of the items has to match the grid. I don't think it's sufficient as a general purpose solution.

This sounds promising from the description, but no doubt comes with other tradeoffs (there isn't a detailed explanation): https://css-tricks.com/piecing-together-approaches-for-a-css-masonry-layout/#order-shifted-elements-in-a-flexbox-layout

[oliviertassinari]

@mbrookes Yeah, the flex order approach might be the best one. I would be eager to explore it further.

[NicoSan20]

@mbrookes @antoniopacheco If I may, it would be appreciate if your library could add the objects first in the smaller column, and so on. Thank you in advance...

[oliviertassinari]

@NicoSan20 This is outside of the scope of this effort.

[mbrookes]

This is outside of the scope of this effort.

Uhh? This is the textbook definition of a masonry layout.

[oliviertassinari]

This is the textbook definition of a masonry layout.

@mbrookes The effort (this pull request) is exploring a JavaScript light solution. The behavior, while probably a better default, would require more effort. I'm not aware, the author or the core team is willing to invest enough for it, any time soon.

[mbrookes]

Oh, okay. So when you suggested a Google Keep style layout (basically this, but complicated by adding new items at the start rather than the end), what did you actually have in mind?

[antoniopacheco]

I like @mbrookes example on:
https://css-tricks.com/piecing-together-approaches-for-a-css-masonry-layout/#order-shifted-elements-in-a-flexbox-layout
it solves the issue when tabbing, and fills the smaller column.

the only unknown for me in here, is what happen if one of the items change height, (let's say a Collapse element).
IMO it shouldn't shift anything around to accommodate the rule "order by smaller column"

I can spare some time early next year to continue the effort for this feature.
I just want to wait to see what the community really needs, Oliver posted a survey to know this.
once we have results, I'll be ok working in any change needed.

[oliviertassinari]

So when you suggested a Google Keep style layout (basically this, but complicated by adding new items at the start rather than the end), what did you actually have in mind?

I was interested in the benchmark. Collecting a wide variety of approaches.

I think that the early results of the survey (6 answers) suggests that the grid column span approach or the flex order would be the most adequate solution. Maybe we should implement both, one for having column spanning, the other for exact dimensions. Maybe start with flexbox order and see how far we go?

[oliviertassinari]

Read-only access to the results of the survey https://docs.google.com/spreadsheets/d/1o1hlL8T2LROqGX-KO4KwPNbhp6kShCyTUm5uxQh0zwE/edit?usp=drivesdk (automatically updated as more developers answer it).

[oliviertassinari]

I'm closing as the effort has been stale for some time, thanks for the exploration