-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Refactor BlockToolbar out of BlockList #16677
Conversation
…ditorProvider to Editor. Plus support InsertionPoint and BlockListAppender
Question: is it already out of the BlockList on the web codepaths? In other words, are we aligning the mobile to the web or are we refactoring both codepaths? |
@hypest Yes, we're aligning with the web with this change :) |
Probably a naive question but, how's this related to the |
This is because I brought some logic from the web in |
To be honest, I wanted us to start using I like narrow-er scope PRs 😄🤷♂️ , both because they are easier to review, and because of the smaller test surface they require. |
👍 I already started doing that ;) |
Hey @Tug , on first look, the approach here (to move even more things/componets to match the structure in the web codepath) feels solid to me and I'd like to see this PR go through! Can you open sibling PRs on gutenberg-mobile and WPAndroid so we can be sure nothing obvious gets broken? For example, |
Rebasing/merging this with |
Should be almost ready for review now, I just need to do a full check up on it since the last merge might have introduced regressions in the ADD BLOCK HERE feature. I also need to test on iOS since I have not and fix the hard coded value (40px here and there) I added for styling. Other than that, should be good for a first pass on the code :) |
Nice work @Tug! I'm not seeing any crashes or other major issues. I do see a few regressions with respect to block insertion though:
|
@mchowning thanks for testing and reporting! I thought I actually fixed that but it seems I did not push 😱. Sorry for the time wasted there. I still need to look at 3. as I don't think this is addressed with my last commit |
No worries. I retested, and you're right, 1 and 2 are now resolved. Unfortunately, I did notice one more edge case that appears to have regressed, so the two outstanding issues that I see are:
FWIW, these both seem like relatively minor regressions to me, and if they're not easy fixes I wouldn't be opposed to merging with the regressions after 1.10 is branched off and just fixing the regressions in separate PRs (could even divide that work up). This is a big PR and the sooner we can get it merged the better imo. |
…new text based block
This reverts commit 59f0431.
|
||
this.onKeyboardHide = this.onKeyboardHide.bind( this ); | ||
export const BlockToolbar = ( { blockClientIds, isValid, mode } ) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a big deal at all, but what would you think about combining the render-nothing cases instead of having two different ones (the first returning null
and the second returning <></>
? To my eyes, something like this is easier to follow:
export const BlockToolbar = ( { blockClientIds, isValid, mode } ) => {
const showToolbar = blockClientIds.length !== 0 && mode === 'visual' && isValid;
return showToolbar ? (
<>
<BlockControls.Slot />
<BlockFormatControls.Slot />
</>
) : null;
};
I don't feel strongly about this, so feel free to leave it as-is if you prefer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed it's a bit better 👍
I think we can keep the current syntax though as it's closer to the web version and we don't delay this PR much longer as well. Let's revisit later if necessary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested on both platforms and everything appears to be working. Great work @Tug! 🎉 🎉
I did leave one minor code style comment, but it is only a suggestion.
@mchowning Thanks a lot for the review 🙇 |
innerToolbarHeight={ blockMobileToolbarHeight } | ||
safeAreaBottomInset={ this.props.safeAreaBottomInset } | ||
parentHeight={ this.props.rootViewHeight } | ||
extraScrollHeight={ innerToolbarHeight + 10 } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what does "+10" refer to?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I entered 3 comments that need to be addressed before we go to production
@@ -169,10 +101,7 @@ export class BlockList extends Component { | |||
{ ...( Platform.OS === 'android' ? { removeClippedSubviews: false } : {} ) } // Disable clipping on Android to fix focus losing. See https://github.com/wordpress-mobile/gutenberg-mobile/pull/741#issuecomment-472746541 | |||
accessibilityLabel="block-list" | |||
innerRef={ this.scrollViewInnerRef } | |||
blockToolbarHeight={ toolbarHeight } | |||
innerToolbarHeight={ blockMobileToolbarHeight } | |||
safeAreaBottomInset={ this.props.safeAreaBottomInset } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need this to be able to scroll properly in iPhone X variety devices
@@ -169,10 +101,7 @@ export class BlockList extends Component { | |||
{ ...( Platform.OS === 'android' ? { removeClippedSubviews: false } : {} ) } // Disable clipping on Android to fix focus losing. See https://github.com/wordpress-mobile/gutenberg-mobile/pull/741#issuecomment-472746541 | |||
accessibilityLabel="block-list" | |||
innerRef={ this.scrollViewInnerRef } | |||
blockToolbarHeight={ toolbarHeight } | |||
innerToolbarHeight={ blockMobileToolbarHeight } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need this to be able to show the block toolbar when we are focused on the last line of the text
Hey @Tug ! I did a first check of automatic scrolling on iOS and it looks good overall. I did find a couple of small regressions but I don't think they are blockers for a release. It would be good to check them out anyway. I'll continue testing more in depth and create an issue with the details. I did find a regression that I believe is a blocker and we should fix it before going to production: The toolbar lost its bottom safe are. This is reproducible on the iPhone X family devices Please let me know if I can help in any way! |
Oh indeed, I did that on purpose because I thought that's what we had but looking at the production app I see it's not the case. That should be easily to fix 👍 |
* Move BlockToolbar from BlockList to Layout * Remove BlockEditorProvider from BlockList and add native version of EditorProvider to Editor. Plus support InsertionPoint and BlockListAppender * Revert BlockListAppender and InsertionPoint additions * Fix dismissing block picker * Add missing function in BlockList * Disable add block in HTML mode and show hide keyboard button only when keyboard is shown * Fix bringing back finishInsertingOrReplacingBlock * Fix inserting block in first position when post title is selected * Show insertion point before block if its replaceable * Fix missing shouldPreventAutomaticScroll props for iOS * Fix native tests * Add back bottom View to push block list up * Improve defining toolbar height * Make html view a flexbax * Quickly hide the modal to let the keyboard show up after inserting a new text based block * Let's unmount the modal instead to make sure we don't have timing errors * revert to defining the toolbar height in the component itsef * Revert "Make html view a flexbax" This reverts commit 59f0431. * Simplify layout * Fix dismiss keyboard on iOS
* Move BlockToolbar from BlockList to Layout * Remove BlockEditorProvider from BlockList and add native version of EditorProvider to Editor. Plus support InsertionPoint and BlockListAppender * Revert BlockListAppender and InsertionPoint additions * Fix dismissing block picker * Add missing function in BlockList * Disable add block in HTML mode and show hide keyboard button only when keyboard is shown * Fix bringing back finishInsertingOrReplacingBlock * Fix inserting block in first position when post title is selected * Show insertion point before block if its replaceable * Fix missing shouldPreventAutomaticScroll props for iOS * Fix native tests * Add back bottom View to push block list up * Improve defining toolbar height * Make html view a flexbax * Quickly hide the modal to let the keyboard show up after inserting a new text based block * Let's unmount the modal instead to make sure we don't have timing errors * revert to defining the toolbar height in the component itsef * Revert "Make html view a flexbax" This reverts commit 59f0431. * Simplify layout * Fix dismiss keyboard on iOS
Description
With
InnerBlocks
coming up in #16305 we needed to moveBlockToolbar
out ofBlockList
to avoid having it created for each BlockList instance. This ended up being a large refactor as a lot of things are related toBlockToolbar
.First we need to revisit a few conventions:
BlockToolbar
should correspond to the controls that we display when a block is selected (BlockControls
andBlockFormatControls
at the moment for native), not the whole bottom toolbar.PREFERENCES_DEFAULTS
in theedit-post
store and set thefixedToolbar
setting totrue
.HeaderToolbar
on the web, even though it's at the bottom on native mobile, we'll keep the name since it really matches the component features.Thus we can see that refactoring
BlockToolbar
actually means refactoring the whole toolbar, meaning the block picker should be moved out ofBlockList
as well. Same for the hide keyboard control.Moving the block picker out of
BlockList
means we need to move the "ADD BLOCK HERE" component out as well, since it depends on the state of the block picker (open or closed). And since gutenberg already supports all those features on the web we should be able to achieve this by keeping the same structure and making native version of those components.Here is the list of changes and their reason, sorted by alpabetical order of components (following as the order in the Files changed tab):
(reverted to reduce changes)BlockListAppender
is a simple wrapper ofDefaultBlockAppender
that is designed to display a new component at the end of a list to keep the writing flow.(reverted to reduce changes)Block
: Add aBlockInsertionPoint
that displays "ADD BLOCK HERE" at the right position when the block picker is openBlockList
ListEmptyComponent
fromKeyboardAwareFlatList
as it can be achieved usingListFooterComponent
only since they use the same componentBlockListAppender
to create a new block, only the placeholder changes ("Start writing…"
when the list is empty, otherwise leave blank)Remove(reverted to reduce changes)renderAddBlockSeparator
fromrenderItem
as it's added inBlock
as theBlockInsertionPoint
BlockToolbar
renderHTML
which is already unused(reverted to reduce changes)BlockInsertionPoint
, now contains the "ADD BLOCK HERE" component and is connected to the store to find out if it should render or not.BlockToolbar
reduced functionalities from the whole editor toolbar to just the block controls and format controlsDefaultBlockAppender
update to allow empty placeholder to be given and reuse the web logic to determine if it should be visible or not (visible only if the last block is not a paragraph for instance)Inserter
groups the block inserter button with the block type picker modal and reusesDropdown
for its own state (modal shown or hidden)~~ (reverted to reduce changes)InserterMenu
contains the whole block type picker modal and is responsible for updating the insertion point index in the store (so theBlockInsertionPoint
can be rendered)Dropdown
a simple native version of the webDropdown
component which is responsible for showing and hidding the modal when we click on the toggle buttonHeaderToolbar
is now our global toolbar which contains the inserter, the block toolbar and the hide keyboard buttonHeader
wrapsHeaderToolbar
Layout
is now responsible for displaying the rootBlockList
along with theHeader
VisualEditor
we removeBlockEditorProvider
from it since we now useEditorProvider
inEditor
which does the same thing and moreEditor
we move all the gutenberg bridge listeners toEditorProvider
that we now call in our render function along with SlotFillProviderEditorProvider
this native version handles setting the gutenberg native bridge listeners and switching mode, it also calls the web version ofEditorProvider
which callssetupEditor
and instantiatesBlockEditorProvider
. For this to work we needed to mockReusableBlocksButtons
andConvertToGroupButtons
.How has this been tested?
Screenshots
Types of changes
Checklist: