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

Effects: Move trash post URL change to the BrowserUrl component #7228

Merged
merged 5 commits into from
Jun 20, 2018
Merged

Effects: Move trash post URL change to the BrowserUrl component #7228

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
3337f28
Effects: Move trash post URL change to the BrowserUrl component
youknowriad Jun 8, 2018
4bde03b
Use the correct "trash" status
youknowriad Jun 11, 2018
bcdb811
unit test the trashed post URL
youknowriad Jun 11, 2018
c9829bc
Refactor componentDidUpdate to accomodate separate flows
youknowriad Jun 11, 2018
549e7a0
Remove TRASH_POST_SUCCESS action and add a note about updatePost
youknowriad Jun 20, 2018
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
26 changes: 24 additions & 2 deletions edit-post/components/browser-url/index.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,22 @@ export function getPostEditURL( postId ) {
return addQueryArgs( 'post.php', { post: postId, action: 'edit' } );
}

/**
* Returns the Post's Trashedd URL.
*
* @param {number} postId Post ID.
* @param {string} postType Post Type.
*
* @return {string} Post trashed URL.
*/
export function getPostTrashedURL( postId, postType ) {
Copy link
Member

Choose a reason for hiding this comment

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

Why do we export? For tests? 😉

return addQueryArgs( 'edit.php', {
trashed: 1,
post_type: postType,
ids: postId,
} );
}

export class BrowserURL extends Component {
constructor() {
super( ...arguments );
Expand All @@ -26,8 +42,13 @@ export class BrowserURL extends Component {
}

componentDidUpdate( prevProps ) {
const { postId, postStatus } = this.props;
const { postId, postStatus, postType } = this.props;
const { historyId } = this.state;

if ( postStatus === 'trashed' ) {
Copy link
Member

Choose a reason for hiding this comment

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

The logic flow for this lifecycle function is a bit confusing, since it handles 2 cases (with 3 conditions including a return) for which one but not the other is delegated to a separate function (setBrowserURL).

Should we consolidate to two conditions (one per case), and use separate functions consistently?

componentDidUpdate( prevProps ) {
	const { postId, postStatus, postType } = this.props;

	if ( postStatus === 'trashed' ) {
		this.setTrashURL( postId, postType );
	}

	const { historyId } = this.state;
	if ( ( postId !== prevProps.postId || postId !== historyId ) && postStatus !== 'auto-draft' ) {
		this.setBrowserURL( postId );
	}
}

Or maybe some other pattern for handling multiple types of lifecycle changes, e.g. componentDidUpdate assigned by _.over or _.cond.

Similar to:

gutenberg/editor/components/navigable-toolbar/index.js

Lines 33 to 35 in 5d7bc40

this.switchOnKeyDown = cond( [
[ matchesProperty( [ 'keyCode' ], ESCAPE ), this.focusSelection ],
] );

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'm using the less smart option :P. I think it's a little bit easier to understand.

window.location.href = getPostTrashedURL( postId, postType );
}

if ( postId === prevProps.postId && postId === historyId ) {
return;
}
Expand Down Expand Up @@ -65,10 +86,11 @@ export class BrowserURL extends Component {

export default withSelect( ( select ) => {
const { getCurrentPost } = select( 'core/editor' );
const { id, status } = getCurrentPost();
const { id, status, type } = getCurrentPost();

return {
postId: id,
postStatus: status,
postType: type,
};
} )( BrowserURL );
12 changes: 2 additions & 10 deletions editor/store/effects.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,6 @@ import apiRequest from '@wordpress/api-request';
/**
* Internal dependencies
*/
import { getWPAdminURL } from '../utils/url';
import {
setupEditorState,
resetAutosave,
Expand Down Expand Up @@ -254,6 +253,8 @@ export default {
dispatch( removeNotice( TRASH_POST_NOTICE_ID ) );
apiRequest( { path: `/wp/v2/${ basePath }/${ postId }`, method: 'DELETE' } ).then(
() => {
const post = getCurrentPost( getState() );
dispatch( resetPost( { ...post, status: 'trashed' } ) );
Copy link
Member

Choose a reason for hiding this comment

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

The correct status is 'trash'.

https://codex.wordpress.org/Function_Reference/get_post_status#Return_Values

Copy link
Member

Choose a reason for hiding this comment

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

This seems like what updatePost is meant to handle (updating subsets of post properties). Unfortunately we have it tangled with change detection so that it considers dirtiness as reset. This might not be a problem if we expect a redirect to occur anyways (in fact maybe a good thing to avoid any possibility of a prompt).

Related: #7130 (comment)

Copy link
Member

Choose a reason for hiding this comment

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

This seems like what updatePost is meant to handle [...]

What do you think about this? Should we try to use updatePost? If it's at least the desirable end-solution, should we add a "TODO" comment or task to follow-up on this?

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 think it should be a todo for now because at some point I want to move the currentPost out of the editor's state into core-data, in which case we'd have a updateEntityRecord action

dispatch( {
...action,
type: 'TRASH_POST_SUCCESS',
Copy link
Member

Choose a reason for hiding this comment

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

This action type is never referenced elsewhere. Should we remove it? My only hesitation might be is that it's complementing the failing type, which is in-fact referenced. The counter-point may be that the existence of this action type may be misinterpreted as a hint that it has resulting handling. I'd lean toward removal.

Aside: I'd also like to refactor the notices behavior, which would include consolidating the TRASH_POST_FAILURE action type.

Expand All @@ -271,15 +272,6 @@ export default {
}
);
},
TRASH_POST_SUCCESS( action ) {
const { postId, postType } = action;

window.location.href = getWPAdminURL( 'edit.php', {
trashed: 1,
post_type: postType,
ids: postId,
} );
},
TRASH_POST_FAILURE( action, store ) {
const message = action.error.message && action.error.code !== 'unknown_error' ? action.error.message : __( 'Trashing failed' );
store.dispatch( createErrorNotice( message, { id: TRASH_POST_NOTICE_ID } ) );
Expand Down