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

Documentation: Generate Docs for the data module #7264

Merged
merged 3 commits into from
Jun 19, 2018
Merged
Show file tree
Hide file tree
Changes from all 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
82 changes: 82 additions & 0 deletions docs/data/core-blocks.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,82 @@
# **core/blocks**: Block Types Data

## Selectors

### getBlockType

Returns a block type by name.
Copy link
Member

Choose a reason for hiding this comment

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

"type by name" is a bit awkward, especially because "name" isn't really a type that I'd expect to provide clarification.

This might be better stated as "Return a block type as a string (eg. by name)." An example would be even better.


*Parameters*

* state: Data state.
* name: Block type name.

### getCategories

Returns all the available categories.

*Parameters*

* state: Data state.
Copy link
Member

Choose a reason for hiding this comment

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

Is there any way we can make this an include in Markdown? It's repeated a lot. "redux state" might also be a bit better to use as a descriptor as well, for what it's worth.


*Returns*

Categories list.

### getDefaultBlockName

Returns the name of the default block name.
Copy link
Member

Choose a reason for hiding this comment

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

The default block name in what context? I'm guessing it's for the editor context (and this is probably <p> by default), but that isn't clear from just reading the docs.


*Parameters*

* state: Data state.

*Returns*

Default block name.

### getFallbackBlockName

Returns the name of the fallback block name.
Copy link
Member

Choose a reason for hiding this comment

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

A lot of these functions are somewhat clear based on their function names, so an explanation like this one doesn't really help, I think.

But the docs could really shine if this explained (not in detail, but even just in passing), what a fallback block was. Why you'd use this and what it's for would really help contextualise a lot of these selector functions.


*Parameters*

* state: Data state.

*Returns*

Fallback block name.

## Actions

### addBlockTypes

Returns an action object used in signalling that block types have been added.
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 the basic redux half-explainations here (an action function returns an action object used by dispatch()) aren't helpful and might even be confusing. Instead I'd structure this section like:

## Actions

These functions all return [action objects](DOC ON REDUX ACTION OBJECT.html) that are passed to a store's `dispatch()` function to dispatch a redux action.

### addBlockTypes

Signal that a block type, or types, have been added.

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's important to see these docs as a reference API. IMO, These docs shouldn't explain the concepts (actions, redux...) but serve as a reference while the README of the data module (which is already in a good shape) should explain the concepts and link to the reference.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

But I agree that we can reword the descriptions of the action creators.

Copy link
Member

Choose a reason for hiding this comment

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

But the aim of these functions is to be passed to the store's dispatch(); they serve no other purpose (in actual use… maybe you'd use them outside the store for testing or for creating an object to get the action type from, but that's it).

Describing them as just functions that return objects rather than the action in the app they're solely designed to handle leaves out very useful context for docs.

Copy link
Member

Choose a reason for hiding this comment

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

But it's also misleading to say they signal something. On their own, the functions do not signal anything, and in fact it is accurate to say they merely return an object.

Copy link
Member

@tofumatt tofumatt Jun 12, 2018

Choose a reason for hiding this comment

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

Sure. Saying that once above though, and then saying these functions all signal something assuming they're passed to dispatch() (which is their only purpose anyway) is better to me, and makes the intent of all of these functions clearer.

But it sounds like both you and @youknowriad think they should serve as more of a clear-cut functional reference, so in that case I am out-voted! 🗳


*Parameters*

* blockTypes: Block types received.
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't this be Block type(s) to add to the store? This is an action that adds new blocks to the editor, right?


### removeBlockTypes

Returns an action object used to remove a registered block type.

*Parameters*

* names: Block name.

### setDefaultBlockName

Returns an action object used to set the default block name.

*Parameters*

* name: Block name.

Copy link
Member

Choose a reason for hiding this comment

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

There are a lot of double newlines here and I'm not sure why.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch I'll take a look

### setFallbackBlockName

Returns an action object used to set the fallback block name.

*Parameters*

* name: Block name.
245 changes: 245 additions & 0 deletions docs/data/core-edit-post.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,245 @@
# **core/edit-post**: The Editor's UI Data

## Selectors

### getEditorMode

Returns the current editing mode.

*Parameters*

* state: Global application state.
Copy link
Member

Choose a reason for hiding this comment

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

This is a different description to the previous one used for all the states. Is that because the other one was the core/data state but this isn't? I'm confused. It might help to link to the state it expects for each function.


### isEditorSidebarOpened

Returns true if the editor sidebar is opened.

*Parameters*

* state: Global application state

*Returns*

Whether the editor sidebar is opened.
Copy link
Member

Choose a reason for hiding this comment

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

That is what it does, but what it returns is `true` if sidebar is open; `false` if sidebar is not open.

Copy link
Member

Choose a reason for hiding this comment

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

That is what it does, but what it returns is `true` if sidebar is open; `false` if sidebar is not open.

Aside: Typically the primary description would include a "true if ..., otherwise false". Also there is type information available in the JSDoc {boolean} we are not including here.


### isPluginSidebarOpened

Returns true if the plugin sidebar is opened.

*Parameters*

* state: Global application state

*Returns*

Whether the plugin sidebar is opened.
Copy link
Member

Choose a reason for hiding this comment

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

A lot of these have explanations that should be the return value and return values that better explain the function. Maybe it's worth switching them?


### getActiveGeneralSidebarName

Returns the current active general sidebar name.

*Parameters*

* state: Global application state.

*Returns*

Active general sidebar name.

### getPreferences

Returns the preferences (these preferences are persisted locally).

*Parameters*

* state: Global application state.

*Returns*

Preferences Object.
Copy link
Member

Choose a reason for hiding this comment

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

Could we link to this? Otherwise this isn't a helpful explainer.


### getPreference

*Parameters*

* state: Global application state.
* preferenceKey: Preference Key.
* defaultValue: Default Value.

*Returns*

Preference Value.

### isPublishSidebarOpened

Returns true if the publish sidebar is opened.

*Parameters*

* state: Global application state

*Returns*

Whether the publish sidebar is open.

### isEditorSidebarPanelOpened

Returns true if the editor sidebar panel is open, or false otherwise.

*Parameters*

* state: Global application state.
* panel: Sidebar panel name.

*Returns*

Whether the sidebar panel is open.

### isFeatureActive

Returns whether the given feature is enabled or not.

*Parameters*

* state: Global application state.
* feature: Feature slug.

*Returns*

Is active.

### isPluginItemPinned

Returns true if the the plugin item is pinned to the header.
When the value is not set it defaults to true.

*Parameters*

* state: Global application state.
* pluginName: Plugin item name.

*Returns*

Whether the plugin item is pinned.

### getMetaBoxes

Returns the state of legacy meta boxes.

*Parameters*

* state: Global application state.

*Returns*

State of meta boxes.

### getMetaBox

Returns the state of legacy meta boxes.

*Parameters*

* state: Global application state.
* location: Location of the meta box.

*Returns*

State of meta box at specified location.

### isSavingMetaBoxes

Returns true if the the Meta Boxes are being saved.

*Parameters*

* state: Global application state.

*Returns*

Whether the metaboxes are being saved.

## Actions

### openGeneralSidebar

Returns an action object used in signalling that the user opened an editor sidebar.

*Parameters*

* name: Sidebar name to be opened.

### closeGeneralSidebar

Returns an action object signalling that the user closed the sidebar.

### openPublishSidebar

Returns an action object used in signalling that the user opened the publish
sidebar.

### closePublishSidebar

Returns an action object used in signalling that the user closed the
publish sidebar.

### togglePublishSidebar

Returns an action object used in signalling that the user toggles the publish sidebar.

### toggleGeneralSidebarEditorPanel

Returns an action object used in signalling that use toggled a panel in the editor.

*Parameters*

* panel: The panel to toggle.

### toggleFeature

Returns an action object used to toggle a feature flag.

*Parameters*

* feature: Feature name.

### togglePinnedPluginItem

Returns an action object used to toggle a plugin name flag.

*Parameters*

* pluginName: Plugin name.

### initializeMetaBoxState

Returns an action object used to check the state of meta boxes at a location.

This should only be fired once to initialize meta box state. If a meta box
area is empty, this will set the store state to indicate that React should
not render the meta box area.

Example: metaBoxes = { side: true, normal: false }.

This indicates that the sidebar has a meta box but the normal area does not.

*Parameters*

* metaBoxes: Whether meta box locations are active.

### requestMetaBoxUpdates

Returns an action object used to request meta box update.

### metaBoxUpdatesSuccess

Returns an action object used signal a successfull meta box update.

### setMetaBoxSavedData

Returns an action object used to set the saved meta boxes data.
This is used to check if the meta boxes have been touched when leaving the editor.

*Parameters*

* dataPerLocation: Meta Boxes Data per location.
Loading