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

Add documentation for every state selector #989

Merged
merged 3 commits into from
Jun 2, 2017
Merged

Conversation

aduth
Copy link
Member

@aduth aduth commented Jun 1, 2017

This pull request seeks to add documentation for every state selector which exists. Some are a best guess at intent of the selector, so review from original authors would be appreciated.

Testing instructions:

There is no impact on editor experience from these changes.

Ensure that new unit tests pass:

npm run test-unit

@aduth aduth added the [Type] Developer Documentation Documentation for developers label Jun 1, 2017
Copy link
Member

@nylen nylen left a comment

Choose a reason for hiding this comment

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

Thanks for doing this. I learned a few things about our state structure already from reviewing it.

@@ -839,4 +890,57 @@ describe( 'selectors', () => {
expect( isSavingNewPost( state ) ).to.be.false();
} );
} );

describe( 'getSuggestedPostFormat', () => {
it( 'returns null if cannot be determined', () => {
Copy link
Member

Choose a reason for hiding this comment

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

Wording of these test names? Most of our other tests use should, and it seems good to be consistent...

it( 'should be painted yellow', ...

Copy link
Member Author

Choose a reason for hiding this comment

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

Wording of these test names?

We just talked about this at #946 (comment) 😛 I'd argue this is one case where I wish we weren't so consistent, because bending over backwards to prefix with "should" isn't always appropriate and at worst is unnecessary filler.

editor: {
blockOrder: [ 5, 4, 3, 2, 1 ],
},
multiSelectedBlocks: { start: 2, end: 4 },
Copy link
Member

@nylen nylen Jun 2, 2017

Choose a reason for hiding this comment

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

Here and below, it seems strange to have end before start in the block order. Is this possible in actual usage?

Copy link
Member

Choose a reason for hiding this comment

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

Yes, start has the index where the selection started, end where it ended. See also getSelectedBlocks.

Copy link
Member

Choose a reason for hiding this comment

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

(You can select blocks from bottom to top.)

export function isEditorSidebarOpened( state ) {
return state.isSidebarOpened;
}

/**
* Returns true if the past editor history snapshots exist, or false otherwise.
Copy link
Member

Choose a reason for hiding this comment

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

s/the/any/ - it reads better to me this way

export function hasEditorUndo( state ) {
return state.editor.history.past.length > 0;
}

/**
* Returns true if the future editor history snapshots exist, or false
Copy link
Member

Choose a reason for hiding this comment

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

s/the/any/ - it reads better to me this way

export function isEditedPostDirty( state ) {
return state.editor.dirty;
}

/**
* Returns the post currently being edited.
Copy link
Member

Choose a reason for hiding this comment

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

Probably worth noting that this does not include any edits made to the post. "Returns our representation of the post in its last known state state on the server" maybe?

Copy link
Member Author

Choose a reason for hiding this comment

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

Probably worth noting that this does not include any edits made to the post. "Returns our representation of the post in its last known state state on the server" maybe?

Raises an interesting point about what we'd expect the return value to be for a new post. Based on the currentPost default I'd guess an empty object? Seems like it might be more appropriate as null, though I suspect this could cause breakage where we expect to access properties unguarded on the post object.

Nice thing about adding these documentation is that it helps surface real-world expectations 😄

Copy link
Member

Choose a reason for hiding this comment

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

Not necessarily an empty object - I imagine a new post would contain status: 'draft' and any other default values. Previous discussion: #848 (comment)

Currently these default values are stored in post-content.js (#, #).

So perhaps we could improve the wording here as follows:

Returns our representation of the saved post object. For an existing post, this is the last known state of the post on the server; for a new post, this is an object containing any relevant default values.

export function getCurrentPost( state ) {
return state.currentPost;
}

/**
* Returns the post values which have yet to be saved.
Copy link
Member

Choose a reason for hiding this comment

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

"Returns any post values that have been changed in the editor and not yet saved"?

export function getPostEdits( state ) {
return state.editor.edits;
}

/**
* Returns a single attribute of the post being edited.
Copy link
Member

Choose a reason for hiding this comment

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

"..., pulling from either the last known representation of the post or its edited value, if any."

* @param {Object} state Global application state
* @param {String} uid Block unique ID
* @return {Number} Index at which block exists in order
*/
export function getBlockOrder( state, uid ) {
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps separately, I think this selector should be renamed. As-is, I'd expect it to simply​ return the block order array. getBlockIndex maybe?

/**
* Returns focus state of the block corresponding to the specified unique ID,
* or null if the block is not selected. Focus state defaults to an empty
* object.
Copy link
Member

Choose a reason for hiding this comment

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

What other object shapes might be returned by the focus state?

Copy link
Member Author

Choose a reason for hiding this comment

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

What other object shapes might be returned by the focus state?

As far as I recall the original intention, it's up to the block to manage the focus object how they see fit. For example differentiating between Editables of the same block:

https://github.com/WordPress/gutenberg/blob/1e46489/blocks/library/quote/index.js#L115

This is one thing I'd like to see refactored, ideally with less block implementer intervention. Relates to #878

cc @youknowriad

Copy link
Member

Choose a reason for hiding this comment

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

Agree this could be improved, for now I would add something like "The specific content of the object is left up to the implementation of each block."

@@ -194,6 +430,14 @@ export function isTypingInBlock( state, uid ) {
return state.selectedBlock.typing;
}

/**
* Returns the unique ID of the block at which a new block insertion would be
Copy link
Member

Choose a reason for hiding this comment

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

s/at which/after which/ ?

*
* @param {Object} state Global application state
* @return {String} Post status
*/
export function getEditedPostStatus( state ) {
Copy link
Contributor

Choose a reason for hiding this comment

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

This has been written before the getEditedPostAttribute, I wonder if we should just drop it now.

}

/**
* Returns an array containing all unique IDs of the post being edited, in the
Copy link
Contributor

Choose a reason for hiding this comment

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

all the unique block IDS

@aduth
Copy link
Member Author

aduth commented Jun 2, 2017

Revisions made per reviews. Thanks for looking 👍

Copy link
Contributor

@youknowriad youknowriad left a comment

Choose a reason for hiding this comment

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

Thanks for doing this

@aduth
Copy link
Member Author

aduth commented Jun 2, 2017

Updated per feedback at #989 (comment) and #989 (comment), squashed the two revisory rewording commits. Will merge when CI passes.

@aduth aduth merged commit 49ad784 into master Jun 2, 2017
@aduth aduth deleted the add/selectors-docs branch June 2, 2017 18:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Developer Documentation Documentation for developers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants