Size Change: +4.25 kB (+0.17%)

Total Size: 2.51 MB

_{compressed-size-action}

I haven't dug deeply into implementation but direction is good. Thanks for working on this, Mike!

Do we want this to be core layout or something you register from a core package or third-party package?

@oandregal My largest struggle with this right now is why we need to have things like eventField. If we're not providing special formatting for eventField (no date format), grouping is supported via provided values, and the date display per item is a provided value, we're not actually doing anything with it?

You can do everything date related in existing list view by providing any date field and a group, while ensuring your data is pre-sorted by date.

The only thing we're adding here essentially is a line down the left and icons. Thats why I'm struggling with direction. What do you think?

@mikejolley Does this mockup help to clarify direction?

The eventField is the only necessary field for this layout to work: it anchors each item's content. Media, title, and groupBy are all optional.

The only thing we're adding here essentially is a line down the left and icons. Thats why I'm struggling with direction. What do you think?

That's how we start, but I expect us to iterate and have all of this working:

• Icon for layout switcher (users can switch, easily recognizable, etc.).
• View config: disable sorting for the timeline layout.
• View API: a mechanism to set what field anchors the item. In most use cases it'd be a date(time) type, but it could also be a different one (title, etc.).
• Styles, structure, and interaction:
  • The list layout is designed to work with a preview, which has a mark in its styles, for example. What we want for the list layout is a big selection (the whole item), like in email, because we want the previewed item to be obvious. Timeline would need different styles, because it's not about "selection".
  • Keyboard navigation. We've built the list layout for selecting an item quickly: tab gets you into the list, up/down arrow key navigate up/down items, left/right arrow keys navigate clickable elements. Navigation for timeline could work differently — specially if interactive elements are positioned one above the other, like the primary action and the title are in the example, it feels weird to use right/left to navigate when visually they are stacked vertically.
  • Click on title: list doesn't have this, but the timeline feels like it could use it.
  • Primary actions: positioned differently than in the list layout.

By having a separate timeline layout, we can easily customize all those details without impacting the list layout. Without that separation, the code will be hard to maintain. Of course, we don't have to have all of this working in the first PR, we should start small and iterate on them bit by bit.

Does this help?

Do we want this to be core layout or something you register from a core package or third-party package?

@youknowriad There are example in core that would benefit from this (global styles revisions, etc.).

@youknowriad There are example in core that would benefit from this (global styles revisions, etc.)

Yeah, I think that's a good argument for making it in Core but I do wonder if it should be bundled in dataviews or a separate package (to also allow us to explore the custom layouts API). I don't think it's necessarily in this initial PR or if we should do it at all. But it feels like a good opportunity.

One advantage is that if you consume dataviews as a module, you might not increase the bundle size of all the routes that use dataviews, only the ones that need this particular layout.

Flaky tests detected in 778306f.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/19464380570
📝 Reported issues:

• [Flaky Test] can be replaced by dragging-and-dropping images from the inserter #50325 in /test/e2e/specs/editor/blocks/image.spec.js

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: mikejolley <[email protected]>
Co-authored-by: oandregal <[email protected]>
Co-authored-by: ntsekouras <[email protected]>
Co-authored-by: youknowriad <[email protected]>
Co-authored-by: jameskoster <[email protected]>
Co-authored-by: tellthemachines <[email protected]>
Co-authored-by: keoshi <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

It'd be good to rebase and resolve conflicts for easier reviews (more accurate changeset).

I'm having a hard time understanding the value of eventField. What role does it play and what would be the field for the most common use case. Can you share an example?

I'm having a hard time understanding the value of eventField. What role does it play and what would be the field for the most common use case. Can you share an example?

There is an example in storybook. The idea was that eventField could control sorting (we didn't implement this), and be rendered below each item as the date/time for the item. We could go further with event field and actually implement sorting and date formatting, but I've left the implementation vague for this iteration.

It could be removed but then you'd need to ensure every consumer adds the date to the item themselves and internally we wouldn't know what field is responsible for the date/time of the event.

@keoshi Thanks, I've made those changes in eff5aa1

Renamed the PR from: DataViews: Introduce Activity (previously Timeline) Layout to DataViews: introduce activity layout because the PR's title is used when preparing the Gutenberg release notes and thought "previously timeline" would be confusing for a newly introduced layout :)

@mikejolley thanks for iterating on this one until the details were right! 👏 ❤️

Thanks for the reviews and direction @oandregal, and everyone else who provided feedback. Merging now 😎