-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
DataViews: Update all templates
page
#55848
Conversation
Size Change: -884 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
Flaky tests detected in d9cb65d. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6799852261
|
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.
Nice PR. I'm curious? How was the experience using the data views to build this? Maybe there should be a way to disable pagination entirely for a view or maybe we should start with more than 10 templates per page.
Also, let's get some design feedback on this. @SaxonF @jameskoster @jasmussen
packages/edit-site/src/components/page-templates/dataviews-templates.js
Outdated
Show resolved
Hide resolved
packages/edit-site/src/components/page-templates/dataviews-templates.js
Outdated
Show resolved
Hide resolved
36e8fff
to
ecc788f
Compare
packages/edit-site/src/components/page-templates/dataviews-templates.js
Outdated
Show resolved
Hide resolved
packages/edit-site/src/components/page-templates/dataviews-templates.js
Outdated
Show resolved
Hide resolved
packages/edit-site/src/components/page-templates/dataviews-templates.js
Outdated
Show resolved
Hide resolved
packages/edit-site/src/components/page-templates/dataviews-templates.js
Outdated
Show resolved
Hide resolved
1fd196c
to
7b62907
Compare
7b62907
to
885cdea
Compare
@youknowriad pretty straightforward so far. The main difference for now is that the data are handled with a single REST request, so we have to handle the data changes locally. The list hasn't filters yet, so I'm not sure what we will face later - I'd expect no big surprises though. The other thing that was surfaced here and will probably need to handle better with more thought in follow ups, is that the component might need to support specific view types. @jameskoster I haven't addressed the following:
I think we have feature parity for now, and we could handle all these separately in follow ups, so work could be even split among more people. So what do you think is missing or needs to be addressed to land the first iteration of this? |
What do you mean by this? |
} ); | ||
} | ||
// Handle sorting. | ||
// TODO: Explore how this can be more dynamic.. |
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.
What do you mean by this comment?
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.
Not really sure yet 😄 . We'll know when we add more sortable fields soon. Might not need anything special.
I'm not sure how we will handle it in the future based on allowing third party devs to register their own view types etc.. I don't have something specific in my mind now, but we might need some different handling than the |
@@ -44,8 +44,17 @@ const availableViews = [ | |||
}, | |||
]; | |||
|
|||
function ViewTypeMenu( { view, onChangeView } ) { | |||
const activeView = availableViews.find( ( v ) => view.type === v.id ); | |||
function ViewTypeMenu( { view, onChangeView, supportedViewTypes } ) { |
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.
I only have naming suggestions:
- Using "layout" instead of "view type" everywhere:
- We expose it as "Layout" in the UI, so it's better to be coherent with that – it also communicates intent better than type, IMO.
- Some changes would be:
ViewTypeMenu
toLayoutMenu
,availableViews
toavailableLayouts
, etc. - I understand there's previous code, so unrelated changes could be done separately, not in this PR.
supportedViewTypes
prop tolayouts
. Introduced in this PR, so we can do it here already.
const activeView = availableViews.find( ( v ) => view.type === v.id ); | ||
function ViewTypeMenu( { view, onChangeView, supportedViewTypes } ) { | ||
let _availableViews = availableViews; | ||
if ( supportedViewTypes ) { |
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.
What do you think of reusing the same array as in?
if ( layouts ) {
avaliableLayouts = availableLayouts.filter( ... );
}
An alternative would be to do the following name changes:
availableViews
=>layouts
_availableViews
=>availableLayouts
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.
I actually like the alternative naming best (layouts/availableLayouts).
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.
Ah, but then it conflicts with the prop. Perhaps?
let availableLayouts = defaultLayouts;
if ( layouts ) {
availableLayouts = defaultLayouts.filter( ... );
}
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.
Naming 😅
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.
We do have view type in some places style, we might need to think that properly. I'm not entirely sure "layout" is the right word in the "code" at least. For user facing things it's fine. But I kind of like the "block" / "block type" and "view" / "view type" parallel.
Anyway, we need to make a decision and stick with it but it's probably one for a separate PR.
packages/edit-site/src/components/page-templates/template-actions.js
Outdated
Show resolved
Hide resolved
packages/edit-site/src/components/page-templates/template-actions.js
Outdated
Show resolved
Hide resolved
packages/edit-site/src/components/page-templates/dataviews-templates.js
Outdated
Show resolved
Hide resolved
Would appreciate a second review but this is looking good for v1 for me. |
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.
Let's get this in and iterate :)
* [Data views]: Update `all templates` page * feedback part 1 * simple remove action * Allow actions to use a Modal * support only list view for first iteration * remove leftovers since only supporting list view type * refactor item actions * fix action item on click callback
all templates
pageall templates
page
What?
Part of: #55083
This PR updates the templates list in site editor and is under new admin views experiment.
In order to implement the first version of this list, data views actions API had to be augmented to enable actions to render content in a Modal(ex. confirmation for deleting a template).
Testing Instructions
manage all templates
viewTasks
list
view type for first iterationScreenshots or screencast
Screen.Recording.2023-11-09.at.10.15.52.PM.mov