Fixes the nested blocks contextual toolbar preference #6082

youknowriad · 2018-04-09T11:56:56Z

On nested blocks, when we switch the "Fixed toolbar" preference, the UI was not being updated because the InnerBlocks component is cached and doesn't change on prop change.

So solve this issue, this does two things:

Move the hasFixedToolbar preference to the editor settings object to avoid having to pass it down as a prop to all the needed components and rely on context instead.
Since this preference can change over time, the old implementation of React context is not possible, so I'm also updating the editorSettings to rely on the new React context API.

This PR surfaces several things:

1 - The blocks module needs to know about the editorSettings (editor module). Previously, it was implicit because we we're just grabbing a context value, with the next React API, it's explicit (better IMO) because we need to import the Consumer component. In this first implementation, I implemented the EditorSettings context in the blocks module to avoid circular dependencies. But This is just one other thing proving that the distinction we have right now between blocks and editor is not correct and should be rethought separately.

2 - The new Editor Settings Object can change over time (it used to be immutable). This is already handled properly everywhere using the Context API. Aside one place, the setupEditor action is being triggered using the settings object. I think this is used to check the post against its template (which is available in the settings). I think it's fine for now because the template config can't be changed yet, but we could imagine rechecking again if the settings change. (retrigger a setupEditor action).

3 - Also this raises the question on the difference between the data module and the new React context API. And the response is simple, there's no difference conceptually :). So why I didn't use the data module instead of the React context API here? Because I didn't want to introduce a blocks store yet while the distinction between editor and blocks is not clear yet (see point 1). We should probably be using the editor store to hold these settings instead of a newly created blocks store. Bur for this to happen we need to merge these two modules first. So the tradeoff here is to use the React API and we'd be able to replace it easily with the data module once the point 1 is fixed.

Testing instructionos

Add a columns block
Switch the "Fixed toolbar preference"
The toolbar should show up at the right place depending on the value of the preference.

aduth

A casual observer will have a difficult time distinguishing between EditorProvider and EditorSettings.Provider.

Will we have similar issues with renderBlockMenu ?

aduth · 2018-04-09T17:45:53Z

edit-post/components/visual-editor/index.js

-						showContextualToolbar={ ! isLargeViewport || ! hasFixedToolbar }
-						renderBlockMenu={ VisualEditorBlockMenu }
-					/>
+					<BlockList renderBlockMenu={ VisualEditorBlockMenu } />
 				</ObserveTyping>
 			</WritingFlow>
 		</BlockSelectionClearer>
 	);
 }

 export default compose( [


We don't need compose anymore?

aduth · 2018-04-09T17:51:06Z

editor/components/block-preview/index.js

@@ -30,7 +30,7 @@ class BlockPreview extends Component {
 		// we inject this function via context.
 		return {
 			createInnerBlockList: ( uid ) => {
-				return createInnerBlockList( uid, noop, noop );
+				return createInnerBlockList( uid, noop );


Aside: Maybe these ought to be default values assigned from createInnerBlockList.

aduth · 2018-04-09T17:53:37Z

editor/components/provider/index.js

-			console.error( 'The Editor Provider Props are immutable.' );
+			this.store.dispatch(
+				setupEditor( props.post, {
+					...EditorSettings.defaultSettings,


Something about this feels off to me. Partly because we're duplicating the initialization of these settings between here and below. I think also it's odd that we don't need to observe changes in settings here; why does this only need to occur at setup time, and never thereafter? Should this be a proper EditorSettings.Consumer so we can just leverage the value from EditorSettings.Provider directly?

Noted in the description :) (Second point)

Ah, I did read it, apparently not closely enough.

aduth · 2018-04-09T17:56:20Z

blocks/editor-settings/index.js

+
+/**
+ * The default editor settings
+ * You can override any default settings when calling initializeEditor


This DocBlock feels outdated, particularly in its reference to initializeEditor of another module, and that we document only one of the many settings available (alignWide).

aduth · 2018-04-09T17:57:13Z

blocks/editor-settings/index.js

+ *
+ *  alignWide   boolean   Enable/Disable Wide/Full Alignments
+ *
+ * @var {Object} DEFAULT_SETTINGS


I don't know that @var is correct here, and I'm not sure why its value is repeated DEFAULT_SETTINGS.

youknowriad · 2018-04-10T08:48:38Z

Conceptually renderBlockMenu suffers from the same issues but since it's immutable we don't have any bug. I'm on the fence on whether to add it to the editorSettings specially since it's not scalar. What do you think?

youknowriad · 2018-04-12T09:52:48Z

Ok this should be ready, any concern?

youknowriad · 2018-04-13T08:16:49Z

Granted that it's not perfect. (The initialization and renderBlockMenu). I'm getting this in as it's an improvement, it fixes an issue. And once we revisit the editor/blocks separation I'll revisit it.

aduth · 2018-04-16T14:53:17Z

editor/components/block-list/insertion-point.js

@@ -37,7 +37,7 @@ class BlockInsertionPoint extends Component {
 	}
 }
 export default compose(
-	withContext( 'editor' )( ( { templateLock } ) => ( { templateLock } ) ),
+	withEditorSettings( ( { templateLock } ) => ( { templateLock } ) ),
 	ifCondition( ( { templateLock } ) => ! templateLock ),


Aside: Should we collapse these into a single higher-order component?

ifEditable = compose( withEditorSettings, ifCondition );

youknowriad self-assigned this Apr 9, 2018

youknowriad requested review from mcsf, gziolo and aduth April 9, 2018 11:56

youknowriad added the [Type] Bug An existing feature does not function as intended label Apr 9, 2018

youknowriad added this to the 2.7 milestone Apr 9, 2018

aduth reviewed Apr 9, 2018

View reviewed changes

youknowriad force-pushed the fix/fixed-toolbar-settings branch from 2c59d84 to 77e1c06 Compare April 10, 2018 08:27

youknowriad force-pushed the fix/fixed-toolbar-settings branch from 25f356e to 5e16bfb Compare April 12, 2018 09:52

youknowriad added 6 commits April 13, 2018 08:57

Editor Settings: Use the new React Context API

5989698

Move the FixedToolbar preference to the editor settings

1781458

Remove useless compose

9592a17

Clarify JSDoc for the default settings

ce2cd3e

Use default values for createInnerBlockList

d6431d6

Fix unit tests

35037f5

youknowriad force-pushed the fix/fixed-toolbar-settings branch from 5e16bfb to 35037f5 Compare April 13, 2018 07:58

Use createHigherOrderComponent

44203d0

youknowriad force-pushed the fix/fixed-toolbar-settings branch from 287cd00 to 44203d0 Compare April 13, 2018 08:05

youknowriad merged commit 10cf461 into master Apr 13, 2018

youknowriad deleted the fix/fixed-toolbar-settings branch April 13, 2018 08:17

aduth reviewed Apr 16, 2018

View reviewed changes

This was referenced Apr 27, 2018

[ Try ] Add button in the block toolbar to move selection to the parent. #6471

Closed

Toolbar controls of block persist after selecting different one #6213

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fixes the nested blocks contextual toolbar preference #6082

Fixes the nested blocks contextual toolbar preference #6082

youknowriad commented Apr 9, 2018

aduth left a comment

aduth Apr 9, 2018

aduth Apr 9, 2018

aduth Apr 9, 2018

youknowriad Apr 9, 2018

aduth Apr 9, 2018

aduth Apr 9, 2018

aduth Apr 9, 2018

youknowriad commented Apr 10, 2018

youknowriad commented Apr 12, 2018

youknowriad commented Apr 13, 2018

aduth Apr 16, 2018 •

edited

Loading

Fixes the nested blocks contextual toolbar preference #6082

Fixes the nested blocks contextual toolbar preference #6082

Conversation

youknowriad commented Apr 9, 2018

aduth left a comment

Choose a reason for hiding this comment

aduth Apr 9, 2018

Choose a reason for hiding this comment

aduth Apr 9, 2018

Choose a reason for hiding this comment

aduth Apr 9, 2018

Choose a reason for hiding this comment

youknowriad Apr 9, 2018

Choose a reason for hiding this comment

aduth Apr 9, 2018

Choose a reason for hiding this comment

aduth Apr 9, 2018

Choose a reason for hiding this comment

aduth Apr 9, 2018

Choose a reason for hiding this comment

youknowriad commented Apr 10, 2018

youknowriad commented Apr 12, 2018

youknowriad commented Apr 13, 2018

aduth Apr 16, 2018 • edited Loading

Choose a reason for hiding this comment

aduth Apr 16, 2018 •

edited

Loading