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

Query block grid view #27067

Merged
merged 8 commits into from
Nov 20, 2020
Merged

Query block grid view #27067

merged 8 commits into from
Nov 20, 2020

Conversation

ntsekouras
Copy link
Contributor

@ntsekouras ntsekouras commented Nov 18, 2020

Description

This PR will add support for Query block to show lists as a list or a grid. It's part of Query block missing functionality: #24934

Notes

I have added a wrapper ul in the markup of QueryLoop and each entity's blocks in a li to be semantically correct. That seems fine to me, because it makes the styling possible and now all blocks are without any wrapper besides the main one for post-content. (cc @mtias )

I followed the design suggestions in comments to match the Latest Posts controls for displaying list/grid.

Since it's not clear yet what we'll do with QueryLoop regarding 'merging' with Query, I have added the grid settings and handling in Query even though they apply to QueryLoop. For the record I don't think for now these blocks will be merged and QueryLoop will probably remain as a wrapper, but that's a separate matter...

In this implementation a single property is needed columns and can be declared as a single top level property, but I have declared it as an object in an attempt to maybe be more flexible to be extracted later into an implementation of @youknowriad 's __experimentalLayout (check PR here: #26380). This can change..

How to test this

  1. Under FSE, create a Query block
  2. In Inspector controls change the Columns attribute
  3. View the changes in front-end as well

Screenshots

query-grid

Other thoughts

If this PR goes well and lands eventually, by augmenting the PostFeaturedImage block to have specific height(css) could lead to nice grid of posts/pages etc..

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.
  • I've updated all React Native files affected by any refactorings/renamings in this PR.

@ntsekouras ntsekouras added [Feature] Themes Questions or issues with incorporating or styling blocks in a theme. [Feature] Full Site Editing [Type] Feature New feature to highlight in changelogs. [Block] Query Loop Affects the Query Loop Block labels Nov 18, 2020
@ntsekouras ntsekouras self-assigned this Nov 18, 2020
@@ -22,11 +22,19 @@
"exclude": [],
"sticky": ""
}
},
"layout": {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is the attempt for having a structure similar to __experimentalLayout. Check PR's description for more info.

Copy link
Member

Choose a reason for hiding this comment

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

Should it be experimental then?

Latest Posts block defines two attributes:

"postLayout": {
"type": "string",
"default": "list"
},
"columns": {
"type": "number",
"default": 3
},

We can always tweak providesContext to support some grouping if that makes it easier:

"providesContext": {
	"queryId": "queryId",
	"query": "query",
	"layout": {
		"columns": "columns",
		"type": "layout"
	}
}

@github-actions
Copy link

github-actions bot commented Nov 18, 2020

Size Change: +2.37 kB (0%)

Total Size: 1.2 MB

Filename Size Change
build/annotations/index.js 3.8 kB +1 B
build/autop/index.js 2.83 kB -1 B
build/blob/index.js 665 B +1 B
build/block-directory/index.js 8.72 kB +1 B
build/block-editor/index.js 133 kB +6 B (0%)
build/block-library/editor-rtl.css 8.96 kB +10 B (0%)
build/block-library/editor.css 8.96 kB +10 B (0%)
build/block-library/index.js 147 kB +423 B (0%)
build/block-library/style-rtl.css 8.23 kB +123 B (1%)
build/block-library/style.css 8.23 kB +123 B (1%)
build/blocks/index.js 48 kB +3 B (0%)
build/components/index.js 172 kB -3 B (0%)
build/compose/index.js 9.93 kB -18 B (0%)
build/data/index.js 9.58 kB +778 B (8%) 🔍
build/date/index.js 11.2 kB -2 B (0%)
build/deprecated/index.js 769 B +1 B
build/dom/index.js 4.92 kB +1 B
build/edit-post/index.js 306 kB -2 B (0%)
build/edit-site/index.js 23.1 kB -65 B (0%)
build/edit-site/style-rtl.css 3.86 kB +11 B (0%)
build/edit-site/style.css 3.86 kB +11 B (0%)
build/edit-widgets/index.js 26.4 kB +5 B (0%)
build/editor/index.js 43.3 kB +662 B (1%)
build/element/index.js 4.62 kB +2 B (0%)
build/format-library/index.js 6.86 kB -2 B (0%)
build/i18n/index.js 3.57 kB +1 B
build/keyboard-shortcuts/index.js 2.83 kB +287 B (10%) ⚠️
build/keycodes/index.js 1.94 kB +1 B
build/list-reusable-blocks/index.js 3.1 kB -1 B
build/media-utils/index.js 5.32 kB -1 B
build/notices/index.js 1.82 kB +1 B
build/plugins/index.js 2.56 kB +2 B (0%)
build/primitives/index.js 1.43 kB -1 B
build/reusable-blocks/index.js 3.07 kB +1 B
build/rich-text/index.js 13.4 kB +3 B (0%)
build/shortcode/index.js 1.69 kB -1 B
build/warning/index.js 1.14 kB -2 B (0%)
ℹ️ View Unchanged
Filename Size Change
build/a11y/index.js 1.14 kB 0 B
build/api-fetch/index.js 3.42 kB 0 B
build/block-directory/style-rtl.css 943 B 0 B
build/block-directory/style.css 942 B 0 B
build/block-editor/style-rtl.css 11.3 kB 0 B
build/block-editor/style.css 11.3 kB 0 B
build/block-library/theme-rtl.css 792 B 0 B
build/block-library/theme.css 793 B 0 B
build/block-serialization-default-parser/index.js 1.87 kB 0 B
build/block-serialization-spec-parser/index.js 3.06 kB 0 B
build/components/style-rtl.css 15.3 kB 0 B
build/components/style.css 15.3 kB 0 B
build/core-data/index.js 14.8 kB 0 B
build/data-controls/index.js 827 B 0 B
build/dom-ready/index.js 571 B 0 B
build/edit-navigation/index.js 11.2 kB 0 B
build/edit-navigation/style-rtl.css 881 B 0 B
build/edit-navigation/style.css 885 B 0 B
build/edit-post/style-rtl.css 6.45 kB 0 B
build/edit-post/style.css 6.44 kB 0 B
build/edit-widgets/style-rtl.css 3.13 kB 0 B
build/edit-widgets/style.css 3.13 kB 0 B
build/editor/editor-styles-rtl.css 476 B 0 B
build/editor/editor-styles.css 478 B 0 B
build/editor/style-rtl.css 3.85 kB 0 B
build/editor/style.css 3.85 kB 0 B
build/escape-html/index.js 735 B 0 B
build/format-library/style-rtl.css 547 B 0 B
build/format-library/style.css 548 B 0 B
build/hooks/index.js 2.16 kB 0 B
build/html-entities/index.js 623 B 0 B
build/is-shallow-equal/index.js 698 B 0 B
build/list-reusable-blocks/style-rtl.css 476 B 0 B
build/list-reusable-blocks/style.css 476 B 0 B
build/nux/index.js 3.42 kB 0 B
build/nux/style-rtl.css 671 B 0 B
build/nux/style.css 668 B 0 B
build/priority-queue/index.js 790 B 0 B
build/redux-routine/index.js 2.84 kB 0 B
build/server-side-render/index.js 2.77 kB 0 B
build/token-list/index.js 1.27 kB 0 B
build/url/index.js 4.05 kB 0 B
build/viewport/index.js 1.86 kB 0 B
build/wordcount/index.js 1.22 kB 0 B

compressed-size-action

@mapk
Copy link
Contributor

mapk commented Nov 18, 2020

I absolutely love using this control to adjust the columns in this block! Really good work!

However, I notice that the Columns control is in the sidebar under a header that says, "Display." This is accurate, but now the display settings are being split between the sidebar and the block's toolbar.

I was relying on a logical separation of "Display settings" in the block's toolbar and other settings and filters in the sidebar. But I also don't think the Column RangeControl would work well in the block's toolbar dropdown, so I'm rethinking where to surface these various settings.

Rethinking how these are grouped shouldn't hold up this PR. It worked well 👍 from a design perspective.

@jasmussen
Copy link
Contributor

jasmussen commented Nov 19, 2020

Cool work, thank you for including a GIF! 🏅

I like the feature too. But I wonder if maybe it needs a simpler approach, for two reasons:

  1. CSS grid is non trivial to get right, and is very opinionated as far as grid gaps and theme integration goes.
  2. A separate grid definition is being explored in [Explore] Site Block #16998.

As I go on to elaborate, please let me first state that this is a really impressive PR! Beyond question. My feedback comes from zooming out a bit. And to expand on 1, here's an inspector screenshot:

Screenshot 2020-11-19 at 08 11 41

Right now those columns are fluid, and the grid gap is arbitrarily chosen. There's no trivial mechanism for a theme to customize this grid system, and no built in responsiveness. The end result is that this grid becomes very prescriptive of the end layout, in a way that I think goes against what #16998 tries to accomplish.

To get this properly configurable for a theme, it would need a great deal of code to handle what would probably need to be global styles integration for customizability, and lots of smarts to be responsive. This would add complexity just for this block.

To expand on 2, well, it doesn't exist yet, but whether it be CSS grid or flex or something else, I would imagine that be the exact provider of a grid for a block like this. Instead of adding software on a per-block basis, this "Site Block" or what we might call it, would be the grid provider, and any block inside would inherit from it.

In absence of that, and until such a thing could land, a simpler approach might be to just do what the Latest Posts block does:

latest posts

It's a boolean choice, grid or no grid. While it provides some basic structural CSS, it's really trivial and easy for a theme to customize. Those two — boolean and simple — means that if/when a grid provider like the site block lands, it would be easy to attach posts inside to the grid it provides. It also comes with some built in responsiveness.

What do you think?

@ntsekouras
Copy link
Contributor Author

Hey @mapk

I was relying on a logical separation of "Display settings" in the block's toolbar and other settings and filters in the sidebar.

This is something we can easily move around so we just have to reach a decision about this, at least good enough for first iteration. It could be something like @jasmussen proposes as well to follow the Latests Posts block with two icons in toolbar.

Hey @jasmussen

But I wonder if maybe it needs a simpler approach

Is using flex the simpler approach? Did I understand correctly with your grid comments? If yes, I started with flex and suggested by @aristath to change to grid here: #27067 (comment).
You can see there my initial css.

I think the minimum requirement would be this:

I believe there should be a way to have some margins or something to be able to apply border as well etc...

As I'm not the expert for the css approach, I'm open to suggestions.

I would imagine that be the exact provider of a grid for a block like this.

This is the goal for later as I have discussed this before with Riad

In this implementation a single property is needed columns and can be declared as a single top level property, but I have declared it as an object in an attempt to maybe be more flexible to be extracted later into an implementation of @youknowriad 's __experimentalLayout (check PR here: #26380). This can change..

Thanks both of you for taking a look here 👍

@jasmussen
Copy link
Contributor

jasmussen commented Nov 19, 2020

I guess I'm suggesting that we should be mindful of using explicit column sliders on a per-block basis, as it opens up a can of worms on responsiveness, and that can is perhaps opened when defined in a single place used by multiple blocks at once.

In the mean time, the latest posts block has a column slider and CSS to match it. If we re-use that 1:1 at least it will be consistent?

Also, I'll always defer to Riad. He's proven his wisdom enough times 😅

@youknowriad
Copy link
Contributor

Starting small is always appealing to me :)

So I also have a preference for flex + boolean (or string if we imagine more layouts than just these two later) attribute + being opinionated in the styles (set a decent with per column) + responsiveness.

Now Nik proposes to use the "columns" attribute as a way to switch layouts (one column means we're using the default layout, 2 or more grid), while that works, I think having an explicit attribute for the layout is good especially if we imagine introducing more of these with different configs. Maybe "columns" doesn't make sense in all of them.

--
About the layout prop for InnerBlocks.

I assume switching the layout here means adding a classname to the container, something like is-flex-container (or similar), and I believe we already have this exact behavior built in an ad-hoc way for: Buttons, Navigation, Columns blocks. As a follow-up here we could abstract that in a "flex" layout for InnerBlocks where we:

  • automatically add the class
  • automatically add the styles in the block styles
  • disable block alignments for the inner blocks
  • potentially consider offering customizations specific to that layout: for instance the "width" attribute for each children (like we have now for columns and I believe buttons)

@kjellr
Copy link
Contributor

kjellr commented Nov 19, 2020

In the mean time, the latest posts block has a column slider and CSS to match it. If we re-use that 1:1 at least it will be consistent?

So I also have a preference for flex + boolean (or string if we imagine more layouts than just these two later) attribute + being opinionated in the styles (set a decent with per column) + responsiveness.

+1. I think it makes sense to mirror what we already have in the latest posts block. We know that works well.

To @jasmussen's notes above, CSS grid works best when it's dealing with a known number of items. It doesn't scale super well with a dynamic number of elements inside of it. So flexbox is a simpler solution for this specific use case.

@ntsekouras
Copy link
Contributor Author

I think it makes sense to mirror what we already have in the latest posts block. We know that works well.

So I also have a preference for flex + boolean (or string if we imagine more layouts than just these two later) attribute + being opinionated in the styles (set a decent with per column) + responsiveness.

Now Nik proposes to use the "columns" attribute as a way to switch layouts (one column means we're using the default layout, 2 or more grid), while that works, I think having an explicit attribute for the layout is good especially if we imagine introducing more of these with different configs. Maybe "columns" doesn't make sense in all of them.

I think a combination of all these suggestions aligns best with the layout property as an object as I have now.
When layout.type === 'flex' I will look for columns and the width will be auto calculated to match the 100%. For example 2 columns -> 50%.

I'll revert back to using flex and show the icon in the Query's toolbar.

@mapk
Copy link
Contributor

mapk commented Nov 19, 2020

The changes to match the Latest Posts block work well for me. 👍

ntsekouras and others added 2 commits November 20, 2020 10:40
@ntsekouras ntsekouras force-pushed the add/query-loop-grid-view branch from e6be09a to 940e97e Compare November 20, 2020 09:46
@ntsekouras ntsekouras marked this pull request as ready for review November 20, 2020 10:06
@ntsekouras ntsekouras requested a review from aristath November 20, 2020 10:06
@ntsekouras
Copy link
Contributor Author

I think this is ready for review now :)

Copy link
Member

@aristath aristath left a comment

Choose a reason for hiding this comment

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

Code looks good.
Tested and it works.
My existing theme breaks with this change but that is to be expected, that is the nature of an experimental theme. We could add a deprecation function but I don't think it's necessary.

Everything works beautifully and though I would like this to use CSS-grid, flexbox also works.
Note that with css-grid we'd be able to have responsive without the breakpoints, so the resulting CSS would be significantly smaller:

ul {
  grid-template-columns: repeat(auto-fill, minmax(min(13em, 100%), 1fr));
  grid-gap: 1.25em;
}
li {
  width: 100%;
}

That being said, the current solution works fine and has greater compatibility with IE11 so IMO this is good to merge 👍

@ntsekouras ntsekouras merged commit 0fe880b into master Nov 20, 2020
@ntsekouras ntsekouras deleted the add/query-loop-grid-view branch November 20, 2020 14:28
@github-actions github-actions bot added this to the Gutenberg 9.5 milestone Nov 20, 2020
@paaljoachim
Copy link
Contributor

This is great! Thank you Nik @ntsekouras and everyone else!

I look forward to having a kind of grid layout of images that have the same height and width. As it would create a nice symmetry of images. An example. https://demo.gretathemes.com/estar/blog/

Perhaps also a card view = border and show drop shadow around each. Sounds like I am mentioning additional sidebar options....

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Query Loop Affects the Query Loop Block [Feature] Themes Questions or issues with incorporating or styling blocks in a theme. [Type] Feature New feature to highlight in changelogs.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants