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

Framework: Extract "edit-post" to its own module #4661

Merged
merged 8 commits into from
Jan 25, 2018

Conversation

youknowriad
Copy link
Contributor

This PR extracts the edit-post module to its own module. This step is helpful to be able to experiment with an "edit-template" later.

  • The new module has its own store handling layout state.
  • Extract some more reusable components in editor for use in edit-post (BlockSelectionClearer, InserterWithShortcuts...)
  • The "Show block inspector" button proved to be a challenge, because it's layout related. this is fixed by providing a way to extend the Block's menu from outside the editor module using a prop.
  • Renamed classNames for the components moved to the new module.

Testing instructions

  • This may introduce some unnoticed regressions, heavily testing this PR is necessary.

@youknowriad youknowriad force-pushed the update/extract-edit-post-v2 branch from b2572b6 to 1c97fe8 Compare January 24, 2018 17:36
@youknowriad youknowriad force-pushed the update/extract-edit-post-v2 branch from e59a0cd to a5302b0 Compare January 25, 2018 11:57
Copy link
Member

@aduth aduth left a comment

Choose a reason for hiding this comment

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

I agree with general direction that this helps us toward consolidating editor and blocks directory as also noted in #2761. There's a few open questions remaining on state responsible for editor vs. edit-post (e.g. currentPost remains in editor state) that we could consider refactoring further in subsequent pull requests.

The addition of storeKey to each connected component is quite verbose. I think we should consider either a connect custom to each top-level module which serves as a wrapper to React-Redux's connect passing the storeKey automatically. Alternatively, we could seek to enhance our own query HoC to support all of the same functionality as connect and then it would be not necessary.

Generally difficult to review some of the more granular changes, as while some files are moved verbatim, others include revisions.

onMouseDown={ this.onClick }
onTouchStart={ this.onClick }
ref={ this.bindContainer }
{ ...omit( props, 'clearSelectedBlock' ) }
Copy link
Member

Choose a reason for hiding this comment

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

FWIW you wouldn't need to explicitly pick children to render, since it's already a part of this.props that would be passed.

@@ -54,7 +53,7 @@ function BlockSettingsMenu( { uids, onSelect, focus } ) {
renderContent={ ( { onClose } ) => (
// Should this just use a DropdownMenu instead of a DropDown ?
<NavigableMenu className="editor-block-settings-menu__content">
<BlockInspectorButton onClick={ onClose } />
{ renderBlockMenu( { onClose } ) }
Copy link
Member

Choose a reason for hiding this comment

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

The prop name renderBlockMenu implies that it replaces the entirety of the menu rendering, not adding new options to the top. Would we ever need to replace all rendering? Append to the end? Is this somewhere we want to leverage hooks instead?

*/
import { getCurrentPostType } from '../../store/selectors';

export function PostScheduleCheck( { user, children } ) {
Copy link
Member

Choose a reason for hiding this comment

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

To prior comments made at #4662, I could imagine an HoC:

ifUserCan( 'publish_posts' )

wp_register_script(
'wp-edit-post',
gutenberg_url( 'edit-post/build/index.js' ),
array( 'wp-element', 'wp-components', 'wp-editor', 'wp-i18n', 'wp-date', 'wp-utils' ),
Copy link
Member

Choose a reason for hiding this comment

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

edit-post/index.js has a reference to jQuery and heartbeat, so this should be made an explicit dependency.

Heartbeat is no longer used as a dependency in wp-editor.

@@ -53,6 +53,7 @@ const entryPointNames = [
'i18n',
'utils',
'data',
'edit-post',
Copy link
Member

Choose a reason for hiding this comment

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

To be able to export this as wp.editPost we should consider mapping packages using Lodash's _.camelCase.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Might not be possible to configure webpack to do so https://webpack.js.org/configuration/output/#output-library

@@ -104,15 +104,15 @@
},
"jest": {
"collectCoverageFrom": [
"(blocks|components|date|editor|element|i18n|data|utils)/**/*.js"
Copy link
Member

Choose a reason for hiding this comment

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

We also include a custom ESLint rule for each top-level directory in .eslintrc.json:

gutenberg/.eslintrc.json

Lines 95 to 125 in e694f6a

"selector": "ImportDeclaration[source.value=/^blocks$/]",
"message": "Use @wordpress/blocks as import path instead."
},
{
"selector": "ImportDeclaration[source.value=/^components$/]",
"message": "Use @wordpress/components as import path instead."
},
{
"selector": "ImportDeclaration[source.value=/^date$/]",
"message": "Use @wordpress/date as import path instead."
},
{
"selector": "ImportDeclaration[source.value=/^editor$/]",
"message": "Use @wordpress/editor as import path instead."
},
{
"selector": "ImportDeclaration[source.value=/^element$/]",
"message": "Use @wordpress/element as import path instead."
},
{
"selector": "ImportDeclaration[source.value=/^i18n$/]",
"message": "Use @wordpress/i18n as import path instead."
},
{
"selector": "ImportDeclaration[source.value=/^data$/]",
"message": "Use @wordpress/data as import path instead."
},
{
"selector": "ImportDeclaration[source.value=/^utils$/]",
"message": "Use @wordpress/utils as import path instead."
},

@youknowriad
Copy link
Contributor Author

Alternatively, we could seek to enhance our own query HoC to support all of the same functionality as connect and then it would be not necessary.

If we're fine exposing all selectors to third-party modules, we can get rid of the connect usage.

--

I addressed most of the feedback. Thanks @aduth

@youknowriad youknowriad merged commit 8c5678c into master Jan 25, 2018
@youknowriad youknowriad deleted the update/extract-edit-post-v2 branch January 25, 2018 18:30
@@ -433,7 +433,7 @@ export class BlockListBlock extends Component {
>
<BlockDropZone index={ order } />
{ ( showUI || isHovered ) && <BlockMover uids={ [ block.uid ] } /> }
{ ( showUI || isHovered ) && <BlockSettingsMenu uids={ [ block.uid ] } /> }
{ ( showUI || isHovered ) && <BlockSettingsMenu uids={ [ block.uid ] } renderBlockMenu={ renderBlockMenu } /> }
Copy link
Member

Choose a reason for hiding this comment

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

This change with renderBlockMenu broke the multi-select controls dropdown:

  1. Create a multi-selection range
  2. Open "More Options" menu

multi-select missing

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, we should cherry-pick the fix from the templates branch to its own PR

@aduth
Copy link
Member

aduth commented Jan 29, 2018

Nitpick: To the naming of this module, it stands out to me as inconsistent with our general naming, not only because it's intended as a superset of functionality for the base editor (but naming does not imply this), but also that other modules generally tend to be nouns (editor, blocks, components), whereas edit-post is more an action/verb.

My suggested alternative would be post-editor. What do you think?

@aduth
Copy link
Member

aduth commented Jan 29, 2018

Also, we should plan to fix the assignment of the global to avoid wp[ 'edit-post' ] and instead as wp.editPost. I agree it wasn't a blocker for this pull request, but I don't think we should settle on the non-camelCased global property.

@youknowriad
Copy link
Contributor Author

cc @mtias for the name of the module.

About the global, this might mean we need to find another way to assign these variables (instead of relying on the library config of webpack)


return (
<div>
<BlockSelectionClearer>
Copy link
Member

Choose a reason for hiding this comment

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

Why was this changed from a div to BlockSelectionClearer ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because this was handled in the parent component by using a ref to this div there. I just made this component generic and used it in both the VisualEditor component and the inner component BlockList

@jasmussen
Copy link
Contributor

I think this PR regressed the color scheme styling of the tabs in the sidebar:

screen shot 2018-01-31 at 10 20 42

As you can see from the Publish button, it's supposed to be red, like other tab buttons:

screen shot 2018-01-31 at 10 22 17

It should be a fairly easy fix, renaming some CSS classes in edit-post/assets/stylesheets/_admin-schemes.scss.

Do you want to do it, @youknowriad, or would you like me to do it? I have time if you're busy.

aduth added a commit that referenced this pull request Jan 31, 2018
oandregal added a commit that referenced this pull request Sep 14, 2018
These data has been moved to edit-post store as per
#4661
oandregal added a commit that referenced this pull request Sep 17, 2018
These data has been moved to edit-post store as per
#4661
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