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

Use getEditedPostAttribute() in more selectors #6894

Closed
wants to merge 1 commit into from

Conversation

danielbachhuber
Copy link
Member

@danielbachhuber
Copy link
Member Author

@gziolo Notably, four tests fail with these changes. The problem is that getEditedPostAttribute( state, 'id' ) is not the same as getCurrentPost( state ).id || null. I'm not sure if the behavior for getEditedPostAttribute() is deliberate or an anachronism. Can you clarify?

@@ -353,7 +354,7 @@ export function getEditedPostExcerpt( state ) {
* @return {string} Preview URL.
*/
export function getEditedPostPreviewLink( state ) {
return getCurrentPost( state ).preview_link || null;
return getEditedPostAttribute( state, 'preview_link' );
Copy link
Member

Choose a reason for hiding this comment

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

I think you can use getEditedPostAttribute directly to avoid exposing another selector.

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh. I get what you're saying. getEditedPostPreviewLink() already existed in #6882 though. What's our policy on removing selectors?

@gziolo gziolo added this to the 3.0 milestone May 22, 2018
@gziolo
Copy link
Member

gziolo commented May 22, 2018

Thanks for opening this PR, it would be nice to get it reviewed by @youknowriad or @aduth to make sure we introduce proper changes. I was mostly concerned about introducing another selector getEditedPostPreviewLink where it can be called as getEditedPostAttribute( 'preview_link' ) inside withSelect.

@gziolo gziolo requested a review from aduth May 22, 2018 12:21
@danielbachhuber
Copy link
Member Author

Just so it's stated, I'm not necessarily sure that the changes in this PR are a good thing. I wanted to open it up for illustration purpose.

@@ -76,7 +76,7 @@ export function hasEditorRedo( state ) {
* @return {boolean} Whether the post is new.
*/
export function isEditedPostNew( state ) {
return getCurrentPost( state ).status === 'auto-draft';
return getEditedPostAttribute( state, 'status' ) === 'auto-draft';
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not certain about this change. Because getEditedPostAttribute checks the edited values as well. So if someone sets the status to "draft" or something else and diidn't save yet. There will be a difference. The post won't be considered new while it's still new.

@@ -227,7 +227,7 @@ export function getEditedPostVisibility( state ) {
* @return {boolean} Whether current post is pending review.
*/
export function isCurrentPostPending( state ) {
return getCurrentPost( state ).status === 'pending';
return getEditedPostAttribute( state, 'pending' ) === 'pending';
Copy link
Contributor

Choose a reason for hiding this comment

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

Same as above

@@ -238,10 +238,11 @@ export function isCurrentPostPending( state ) {
* @return {boolean} Whether the post has been published.
*/
export function isCurrentPostPublished( state ) {
const post = getCurrentPost( state );
const status = getEditedPostAttribute( state, 'status' );
Copy link
Contributor

Choose a reason for hiding this comment

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

II also believe we wanted to get the current post's status and date here and not the potentially updated ones.

@youknowriad
Copy link
Contributor

So basically, I think we shouldn't change the selectors here because there's a difference between the "current post" (which means the last saved version) and the "editted attributes" which are potentially different.

I think the idea of using this getEditedPostAttribute selector more is to do so in the components and not in the selectors. And even in the components we should think carefully before making the switch because there's a difference in the meaning. one is extended using local changes, the other not.

@danielbachhuber danielbachhuber removed this from the 3.0 milestone May 22, 2018
@danielbachhuber
Copy link
Member Author

Ok, closing for now.

@danielbachhuber danielbachhuber deleted the 6882-use-edited-post-attribute branch May 22, 2018 12:33
@aduth
Copy link
Member

aduth commented May 23, 2018

Already stated, the difference is when we want to operate on the canonical saved value vs. an unsaved edit, which is intentional in some selectors ("is post new" based on the saved post status), usually reflected in the name of the selector (isCurrentPostX vs. isEditedPostX). Two things to add:

  • We should consider auditing whether the choice is sensible in all existing selectors
  • Given name getEditedPostPreviewLink, I'd expect selector to use getEditedPostAttribute (as one of the proposed changes), not getCurrentPost

What's our policy on removing selectors?

There's some precedent on leaving selectors (or at least arguments behavior) and using deprecated utility (from @wordpress/utils) to flag a deleted selector / selector arguments for removal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants