Editor: Extract BlockList as reusable component #3546

aduth · 2017-11-18T02:54:51Z

This pull request seeks to extract block list components from VisualEditor, for purpose of reusability, particularly for managing nested block listing.

Testing instructions:

Verify that there are no remaining lingering references to visual editor for what had previously targeted block list components (unfortunately there are many implicit dependencies, which should be minimized in future refactoring).

Verify that there is no regressions in block listing behavior.

ephox-mogran · 2017-11-20T03:28:59Z

blocks/editable/index.js

@@ -361,7 +361,7 @@ export default class Editable extends Component {
 		// Find the parent "relative" positioned container
 		const container = this.props.inlineToolbar ?
 			this.editor.getBody().closest( '.blocks-editable' ) :
-			this.editor.getBody().closest( '.editor-visual-editor__block' );
+			this.editor.getBody().closest( '.editor-block-list__block' );


Is this a good opportunity to stop using a hard-coded selector for this? What are some other options?

We could also use context and some HOCs to specify the component to use for anchoring directly as well (rather than relying on DOM hierarchy and selectors).

Is this a good opportunity to stop using a hard-coded selector for this? What are some other options?
We could also use context and some HOCs to specify the component to use for anchoring directly as well (rather than relying on DOM hierarchy and selectors).

I definitely agree with the desire here, and hope to discourage these hard-coded selectors from being introduced in the first place (this pull request serving as evidence of the maintenance pain they cause). But I'd rather address these separate from the intent of this pull request.

Although given some of the immediate concerns of moving this as raised in #3546 (comment), maybe it is a prime time 😕

youknowriad · 2017-11-20T08:39:52Z

editor/components/block-list/style.scss

+	margin-left: auto;
+	margin-right: auto;
+	margin-bottom: $block-spacing;
+	max-width: $visual-editor-max-width + ( 2 * $block-mover-padding-visible );


I think all these styles containing margin: auto and max-width and more globally all the styles positionning the components inside the PostEditor constraints should be kept outside of the editor/components directory.

That way, A layout inserting the BlockList component shouldn't have to think about resetting those to style itself. (Think P2 including BlockList).

At least, that's whay I did for all the other components extracted to this folder.

Accounted for the margins and maximum widths in the rebased 87e417f.

youknowriad · 2017-11-20T08:46:16Z

editor/components/block-list/block.js

@@ -56,7 +56,7 @@ import {

 const { BACKSPACE, ESCAPE, DELETE, ENTER, UP, RIGHT, DOWN, LEFT } = keycodes;

-class VisualEditorBlock extends Component {


Making this reusable means we need to use a prop or something to get a selector for the parent scrollable. https://github.com/WordPress/gutenberg/pull/3546/files#diff-bc66d5701a2fea1111bb8f1bf0150910R96

It's not guaranteed to be the same in all layouts.

In d8be96b I reimplemented the behavior to a generic "find closest scrollable container".

youknowriad

Just noticed that alongside WritingFlow this is the last component that needs to be moved to the editor/components folder. Hey we're getting there 🎉

youknowriad · 2017-11-20T13:05:56Z

related #2761

youknowriad · 2017-11-20T14:12:30Z

Not specific to this one because other components do so aswell, but we should avoid using all "preferences" in these components. I'm thinking of the "toolbar fixed or not" pref and "the most used blocks" pref. I'm thinking the "preferences" are layout specific. We could extract them in a separate PR.

codecov · 2017-11-20T15:00:26Z

Codecov Report

Merging #3546 into master will increase coverage by 0.64%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #3546      +/-   ##
==========================================
+ Coverage   35.15%   35.79%   +0.64%     
==========================================
  Files         267      267              
  Lines        6724     6612     -112     
  Branches     1218     1198      -20     
==========================================
+ Hits         2364     2367       +3     
+ Misses       3683     3588      -95     
+ Partials      677      657      -20

Impacted Files	Coverage Δ
.../components/block-list/block-contextual-toolbar.js	`0% <ø> (ø)`
editor/components/block-list/multi-controls.js	`0% <ø> (ø)`
editor/components/block-list/block-drop-zone.js	`0% <ø> (ø)`
...tor/components/block-list/invalid-block-warning.js	`0% <ø> (ø)`
...ditor/components/block-list/block-crash-warning.js	`50% <ø> (ø)`
editor/components/block-list/block-html.js	`0% <ø> (ø)`
blocks/editable/index.js	`10.23% <ø> (ø)`	⬆️
...itor/components/block-list/block-crash-boundary.js	`0% <ø> (ø)`
editor/components/block-list/index.js	`0% <ø> (ø)`
editor/components/block-list/block.js	`0.75% <0%> (ø)`
... and 16 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 2d50d76...d8be96b. Read the comment docs.

codecov · 2017-11-20T15:00:26Z

Codecov Report

Merging #3546 into master will increase coverage by 0.64%.
The diff coverage is 0%.

@@            Coverage Diff            @@
##           master   #3546      +/-   ##
=========================================
+ Coverage   35.75%   36.4%   +0.64%     
=========================================
  Files         267     267              
  Lines        6745    6634     -111     
  Branches     1221    1202      -19     
=========================================
+ Hits         2412    2415       +3     
+ Misses       3658    3563      -95     
+ Partials      675     656      -19

Impacted Files	Coverage Δ
editor/components/block-list/block-drop-zone.js	`0% <ø> (ø)`
.../components/block-list/block-contextual-toolbar.js	`0% <ø> (ø)`
editor/components/block-list/multi-controls.js	`0% <ø> (ø)`
...itor/components/block-list/block-crash-boundary.js	`0% <ø> (ø)`
editor/components/block-list/index.js	`0% <ø> (ø)`
...ditor/components/block-list/block-crash-warning.js	`50% <ø> (ø)`
blocks/editable/index.js	`10.23% <ø> (ø)`	⬆️
editor/components/block-list/block-html.js	`0% <ø> (ø)`
...tor/components/block-list/invalid-block-warning.js	`0% <ø> (ø)`
editor/components/writing-flow/index.js	`1.47% <0%> (ø)`	⬆️
... and 16 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 359f11f...ca43cb9. Read the comment docs.

aduth · 2017-11-20T15:49:26Z

If I understand properly, this could change over time, which means we can't call the function in the constructor only. Say the block list is small and then it becomes long enought at some point?

This is a good point. In the rebased d6fb66d I call to retrieve the scroll container after the block has been moved.

youknowriad · 2017-11-21T08:59:26Z

editor/components/block-list/block.js

@@ -108,8 +129,9 @@ class VisualEditorBlock extends Component {

 	componentDidUpdate( prevProps ) {
 		// Preserve scroll prosition when block rearranged
-		if ( this.previousOffset ) {
-			this.editorLayout.scrollTop = this.editorLayout.scrollTop +
+		const scrollContainer = getScrollContainer( this.node );


I have a small concern about this getting called in each block update. Let's try and see if we notice perf issues.

I have a small concern about this getting called in each block update. Let's try and see if we notice perf issues.

This is very good to be concerned about, it shouldn't have been so generic, especially since window.getComputedStyle is a non-trivial operation. We can limit it to only the cases where a block has been moved by first checking this.previousOffset.

youknowriad · 2017-11-21T10:25:13Z

closes #2959

aduth · 2017-11-21T16:19:59Z

Noting that this could break some styles with custom blocks which relied on the .editor-block-list__block[data-type] convention for applying styles. Ideally we wouldn't be encouraging this dependency on block list classes anyways, and assume that the block's own applied classes are unique enough for styling.

aduth · 2017-11-21T16:32:57Z

Looks like between-inserter style regressed a bit from the changes here. Currently investigating.

Edit: See #3597

aduth added the Framework Issues related to broader framework topics, especially as it relates to javascript label Nov 18, 2017

aduth requested a review from youknowriad November 18, 2017 02:54

ephox-mogran reviewed Nov 20, 2017

View reviewed changes

youknowriad reviewed Nov 20, 2017

View reviewed changes

aduth force-pushed the move/block-list branch from afed16d to d8be96b Compare November 20, 2017 14:50

aduth force-pushed the move/block-list branch from d8be96b to d6fb66d Compare November 20, 2017 15:48

youknowriad reviewed Nov 21, 2017

View reviewed changes

youknowriad approved these changes Nov 21, 2017

View reviewed changes

aduth added 2 commits November 21, 2017 11:10

Editor: Extract BlockList as reusable component

27ec15c

Block: Reimplement scroll preservation as finding scroll container

ca43cb9

aduth force-pushed the move/block-list branch from d6fb66d to ca43cb9 Compare November 21, 2017 16:11

aduth merged commit c52e0b4 into master Nov 21, 2017

aduth deleted the move/block-list branch November 21, 2017 16:18

aduth mentioned this pull request Nov 21, 2017

Framework: Find a better way to provide the scrollable container #2959

Closed

aduth mentioned this pull request Nov 21, 2017

Blocks: Improve block mover scroll position preserve #3595

Closed

This was referenced Nov 21, 2017

Inserter: Target end-of-content styles to specific inserter #3597

Merged

#2504 Fix for aligned embed videos #3636

Merged

aduth mentioned this pull request Nov 28, 2017

Inserter: Remove duplicated and simplify sibling inserter styles #3705

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Editor: Extract BlockList as reusable component #3546

Editor: Extract BlockList as reusable component #3546

aduth commented Nov 18, 2017

ephox-mogran Nov 20, 2017

ephox-mogran Nov 20, 2017 •

edited

Loading

aduth Nov 20, 2017

aduth Nov 20, 2017

youknowriad Nov 20, 2017

aduth Nov 20, 2017

youknowriad Nov 20, 2017

aduth Nov 20, 2017

youknowriad left a comment

youknowriad commented Nov 20, 2017

youknowriad commented Nov 20, 2017

codecov bot commented Nov 20, 2017

codecov bot commented Nov 20, 2017 •

edited

Loading

aduth commented Nov 20, 2017

youknowriad Nov 21, 2017

aduth Nov 21, 2017

youknowriad commented Nov 21, 2017

aduth commented Nov 21, 2017

aduth commented Nov 21, 2017 •

edited

Loading

		@@ -56,7 +56,7 @@ import {

		const { BACKSPACE, ESCAPE, DELETE, ENTER, UP, RIGHT, DOWN, LEFT } = keycodes;

		class VisualEditorBlock extends Component {

Editor: Extract BlockList as reusable component #3546

Editor: Extract BlockList as reusable component #3546

Conversation

aduth commented Nov 18, 2017

Choose a reason for hiding this comment

ephox-mogran Nov 20, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

youknowriad left a comment

Choose a reason for hiding this comment

youknowriad commented Nov 20, 2017

youknowriad commented Nov 20, 2017

codecov bot commented Nov 20, 2017

Codecov Report

codecov bot commented Nov 20, 2017 • edited Loading

Codecov Report

aduth commented Nov 20, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

youknowriad commented Nov 21, 2017

aduth commented Nov 21, 2017

aduth commented Nov 21, 2017 • edited Loading

ephox-mogran Nov 20, 2017 •

edited

Loading

codecov bot commented Nov 20, 2017 •

edited

Loading

aduth commented Nov 21, 2017 •

edited

Loading