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

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

Merged
merged 3 commits into from
Dec 10, 2024
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
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
45 changes: 28 additions & 17 deletions packages/edit-site/src/components/page-templates/index.js
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,22 @@ export default function PageTemplates() {
};
}, [ layout, activeView ] );
const [ view, setView ] = useState( defaultView );

// Sync the layout from the URL to the view state.
const onChangeUrlLayout = useEvent( () => {
setView( ( currentView ) => ( {
...currentView,
type: layout ?? DEFAULT_VIEW.type,
} ) );
} );
youknowriad marked this conversation as resolved.
Show resolved Hide resolved
useEffect( () => {
const usedType = layout ?? DEFAULT_VIEW.type;
onChangeUrlLayout();
ntsekouras marked this conversation as resolved.
Show resolved Hide resolved
}, [ onChangeUrlLayout, layout ] );

// Sync the active view from the URL to the view state.
const onChangeActiveView = useEvent( () => {
youknowriad marked this conversation as resolved.
Show resolved Hide resolved
setView( ( currentView ) => ( {
...currentView,
type: usedType,
filters:
activeView !== 'all'
? [
Expand All @@ -108,7 +120,10 @@ export default function PageTemplates() {
]
: [],
} ) );
}, [ activeView, layout ] );
} );
useEffect( () => {
onChangeActiveView();
}, [ onChangeActiveView, activeView ] );

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

const onChangeView = useCallback(
Copy link
Member

@Mamaduka Mamaduka Dec 9, 2024

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
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