Components: Expose the Editor's reusable components

[youknowriad]

refs #2761

This PR groups the reusable components of the Editor module under the components directory. And export them as External API for the module.

All these components should be documented with a README for each one of them. I'd appreciate a team effort to add these READMEs.

Next Steps

There are still some components that need to be moved to this directory and are not exposed yet:

• BlockList: This includes the BlockToolbar, the BlockSettingsMenu, and the BlockInspector. This needs a bit of reorganisation to make them really reusable. We need to clarify the external API and remove any "PostEditor" releated styles. A PR specific to these components should address this.

• PostTitle and PostPermalink: The only changes left for these is to move out the PostEditor specific Styles

• TextEditor: Same needs a bit of refactoring to drop the PostEditor's styles.

Once done, we could reorganize the remaining components under a "post-editor" directory or similar.

Note

I'd appreciate a quick review as this may create a lot of conflicts.

[codecov]

Codecov Report

Merging #3389 into master will increase coverage by 1.17%.
The diff coverage is 10.52%.

@@            Coverage Diff             @@
##           master    #3389      +/-   ##
==========================================
+ Coverage   31.98%   33.15%   +1.17%     
==========================================
  Files         249      249              
  Lines        6901     6711     -190     
  Branches     1254     1206      -48     
==========================================
+ Hits         2207     2225      +18     
+ Misses       3945     3786     -159     
+ Partials      749      700      -49

Impacted Files	Coverage Δ
editor/components/unsaved-changes-warning/index.js	0% <ø> (ø)
editor/sidebar/page-attributes/index.js	0% <ø> (ø)	⬆️
editor/components/post-visibility/label.js	0% <ø> (ø)
editor/components/page-attributes/index.js	77.77% <ø> (ø)
editor/components/post-trash/index.js	0% <ø> (ø)
editor/components/post-publish-button/label.js	83.33% <ø> (ø)
editor/components/post-schedule/index.js	0% <ø> (ø)
editor/components/post-schedule/clock.js	0% <ø> (ø)
editor/sidebar/post-pending-status/index.js	0% <ø> (ø)	⬆️
editor/components/word-count/index.js	0% <ø> (ø)
... and 83 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7377a92...8ebe579. Read the comment docs.

[gziolo]

I noticed that we don't prefix document-outline class name with editor- like in all other places. We can fix it in another PR if it isn't designed this way on purpose.

[aduth]

Good catch, it should be prefixed. This is documented in coding guidelines, but I'm now noticing they were written prior to other folders containing components:

https://github.com/WordPress/gutenberg/blob/master/docs/coding-guidelines.md#css

Any default export of a folder's index.js must be prefixed with editor- followed by the directory name in which it resides:

.editor-[ directory name ]

The intended convention is:

• [ root module name ]-[ current directory name ]
  • Example: editor-foo
• [ root module name ]-[ current directory name ]__[ descendant description ]
  • Example: editor-foo__child
• [ root module name ]-[ current directory name ]__[ descendant description ].is-[ modifier description ]
  • Example: editor-foo__child.is-green

[gziolo]

Code changes look good. I need to give it a spin locally and make sure everything works as before. I like how we expose all those components and provide unified naming and structure. Awesome work 👍

All these components should be documented with a README for each one of them. I'd appreciate a team effort to add these READMEs.

Let's open a follow-up issue with the list of all components and label this issue as a Good First Issue. Then all contributors will be able to jump in and help :)

[gziolo]

It seems like some components that depend on the post state could have Post prefix, too. PageAttributes makes it harder to come up with a good pattern here :)

[youknowriad]

Agreed, did this change for one or two components but gave up, we could do it separately one by one.

[gziolo]

I feel your pain, it can be combined with README task. We would have to leave an additional note when applicable.

[gziolo]

I tested locally, I didn't find any issues. Let's merge it as it is and continue refinements in the follow-up PRs.

[aduth]

A couple initial concerns looking through this:

• The naming "components"; could cause some confusion with the top-level components module, but also even within editor itself we still have other components that aren't in this folder. Is it obvious why? I understand only in the context of this pull request that they are intended to be part of the public API of components.
• Maybe a more general concern of how do we decide which components do and don't belong in this directory

[youknowriad]

@aduth Fair point

This comment #2761 (comment) clarifies the intentation here (and the next steps better).

The idea is to end up with an editor module with the following structure:

- editor/components
- editor/post-editor/ (header, sidebar, layout ...)
- editor/store
- editor/utils

This would address the concern about the components because we'd have only two folders containing components. The exposed components in editor/components and the layout components in editor/post-editor.

We could also argue that the post-editor can be extracted at that moment to a child module making the editor module generic. While I think it would be a good idea to do so, I think the reorganization of the folders will be success regardless of this because right now, you can create any component in any place and do what you want including updating state, layout styling, calling api...) while this new organisation brings a lot of clarity and flexibility.

Maybe a more general concern of how do we decide which components do and don't belong in this directory

Good question and we should make this clear in the README of this folder I think.

A component in this folder is any component you can reuse to build your own editor's layout. It shouldn't include any "layout styling" and the only requirement to use this component is to to be included as a children of EditorProvider in the React's element hierarchy.

[aduth]

Okay, I agree some amount of organization will be necessary and this could help distinguish between pieces of a post editor and the plain editor itself. It's yet to be seen how exactly this would play out (post editor in a separate top-level folder? post editor needing its own state that could be confused with editor common state? alternative names to a "components" directory?) but as long as the public API remains relatively stable, it should be okay to make revisions to this later.