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.

Sign up for GitHub

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: Preserve filters when switching layouts in templates dataviews #67744

Merged
merged 3 commits into from
Dec 10, 2024
+45 −17
Merged

DataViews: Preserve filters when switching layouts in templates dataviews #67744

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
f0acf4b
DataViews: Preserve filters when switching layouts in templates datav…
youknowriad Dec 9, 2024
a4dfbec
Add e2e test
youknowriad Dec 9, 2024
001f362
Remove useless useEvent calls
youknowriad Dec 9, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 22 additions & 17 deletions packages/edit-site/src/components/page-templates/index.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,7 @@ import {
import { unlock } from '../../lock-unlock';
import { useEditPostAction } from '../dataviews-actions';
import { authorField, descriptionField, previewField } from './fields';
import { useEvent } from '@wordpress/compose';

const { usePostActions } = unlock( editorPrivateApis );
const { useHistory, useLocation } = unlock( routerPrivateApis );
Expand Down Expand Up @@ -92,11 +93,19 @@ export default function PageTemplates() {
};
}, [ layout, activeView ] );
const [ view, setView ] = useState( defaultView );

// Sync the layout from the URL to the view state.
useEffect( () => {
setView( ( currentView ) => ( {
...currentView,
type: layout ?? DEFAULT_VIEW.type,
} ) );
}, [ setView, layout ] );

// Sync the active view from the URL to the view state.
useEffect( () => {
const usedType = layout ?? DEFAULT_VIEW.type;
setView( ( currentView ) => ( {
...currentView,
type: usedType,
filters:
activeView !== 'all'
? [
Expand All @@ -108,7 +117,7 @@ export default function PageTemplates() {
]
: [],
} ) );
}, [ activeView, layout ] );
}, [ setView, activeView ] );

const { records, isResolving: isLoadingData } =
useEntityRecordsWithPermissions( 'postType', TEMPLATE_POST_TYPE, {
Expand Down Expand Up @@ -170,20 +179,16 @@ export default function PageTemplates() {
[ postTypeActions, editAction ]
);

const onChangeView = useCallback(
Copy link
Member

@Mamaduka Mamaduka Dec 9, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

Why swap useCallback with useEvent?

Update: Should we always memoize this callback? If that's the case, maybe we should use useEvent internally to make it easier for consumers.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There's no need to generate a new callback instance if "view.type" changes or if "layout" changes or if "history" changes... We only want a stable reference that has access to all the latest props of the component.

useEvent is great because it allows us to separate the "dependencies" of an effect from the actual code that needs to trigger as a result of that effect. We can control these two things separately leading to more clarity.

Copy link
Member

Choose a reason for hiding this comment

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

Is it documented somewhere that this is how consumers should pass onChangeView - with stable reference?

If DataView cares about the onChangeView reference, maybe it's better if we handle it there. Just a random thought I had when viewing the code. We can discuss and handle it separately.

const onChangeView = useEvent( onChangeViewProp );

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see a number of components in DataViews using memo and using onChangeView, so memoization is needed. Now, it's true that we can do it internally but useCallback existed before this PR.

( newView ) => {
if ( newView.type !== view.type ) {
history.navigate(
addQueryArgs( path, {
layout: newView.type,
} )
);
}

setView( newView );
},
[ view.type, setView, history, path ]
);
const onChangeView = useEvent( ( newView ) => {
setView( newView );
if ( newView.type !== layout ) {
history.navigate(
addQueryArgs( path, {
layout: newView.type,
} )
);
}
} );

return (
<Page
Expand Down
23 changes: 23 additions & 0 deletions test/e2e/specs/site-editor/templates.spec.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,4 +40,27 @@ test.describe( 'Templates', () => {
)
).toBeVisible();
} );

test( 'Persists filter/search when switching layout', async ( {
page,
admin,
} ) => {
await admin.visitSiteEditor();
await page.getByRole( 'button', { name: 'Templates' } ).click();

// Search templates
await page.getByRole( 'searchbox', { name: 'Search' } ).fill( 'Index' );

// Switch layout
await page.getByRole( 'button', { name: 'Layout' } ).click();
await page.getByRole( 'menuitemradio', { name: 'Table' } ).click();

// Confirm the table is visible
await expect( page.getByRole( 'table' ) ).toContainText( 'Index' );

// The search should still contain the search term
await expect(
page.getByRole( 'searchbox', { name: 'Search' } )
).toHaveValue( 'Index' );
} );
} );
Loading