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

Move BlockList and related components to Gutenberg repository #789

Closed
wants to merge 28 commits into from

Conversation

Tug
Copy link
Contributor

@Tug Tug commented Mar 27, 2019

Gutenberg PR: WordPress/gutenberg#14662

This PR intends to move src/block-management and its dependencies to gutenberg. It reorganizes the code, refactors components as well as convert Flow syntax to default ES6/JSX syntax.
Context: this is necessary for InnerBlock support

List of changes:

  • src/block-management/block-manager.jsgutenberg/packages/block-editor/src/components/block-list/index.native.js along with its styles. SafeArea has been moved to src/app/AppContainer and src/app/VisualEditor as we needed a way to extract the post title from the BlockList component. For this we introduce a new prop header which is passed to FlatList as ListHeaderComponent.
  • src/block-management/block-holder.jsgutenberg/packages/block-editor/src/components/block-list/block.native.js along with its styles
  • src/block-management/block-picker.jsgutenberg/packages/block-editor/src/components/inserter/index.native.js along with its styles. I also switched to using a selector to get the list of available blocks instead of a global function
  • src/block-management/block-toolbar.jsgutenberg/packages/block-editor/src/components/block-toolbar/index.native.js along with its styles
  • src/block-management/inline-toolbar/index.jsgutenberg/packages/block-editor/src/components/block-inspector/index.native.js along with its styles
  • src/components/keyboard-avoiding-view.*.jsgutenberg/packages/components/src/mobile/keyboard-avoiding-view.*.js
  • src/components/keyboard-aware-flat-list.*.jsgutenberg/packages/components/src/mobile/keyboard-aware-flat-list.*.js
  • src/components/readable-content-view.jsgutenberg/packages/components/src/mobile/readable-content-view.native.js
  • gutenberg/packages/editor/src/components/mobile/bottom-sheetgutenberg/packages/components/src/mobile/bottom-sheet
  • gutenberg/packages/editor/src/components/mobile/pickergutenberg/packages/components/src/mobile/picker
  • gutenberg/packages/editor/src/components/mobile/unsupported-blockgutenberg/packages/block-library/src/mobile/unsupported-block

Each file was converted from a Flow syntax to standard ES6+JSX format. To visualize the diff you can use the following commands:

git show origin/develop:src/block-management/block-manager.js | git diff --no-index -- - gutenberg/packages/block-editor/src/components/block-list/index.native.js

git show origin/develop:src/block-management/block-holder.js | git diff --no-index -- - gutenberg/packages/block-editor/src/components/block-list/block.native.js

git show origin/develop:src/block-management/block-picker.js | git diff --no-index -- - gutenberg/packages/block-editor/src/components/inserter/index.native.js

git show origin/develop:src/block-management/block-toolbar.js | git diff --no-index -- - gutenberg/packages/block-editor/src/components/block-toolbar/index.native.js

git show origin/develop:src/block-management/inline-toolbar/index.js | git diff --no-index -- - gutenberg/packages/block-editor/src/components/block-inspector/index.native.js

git show origin/develop:src/components/keyboard-avoiding-view.android.js | git diff --no-index -- - gutenberg/packages/components/src/mobile/keyboard-avoiding-view.android.js

git show origin/develop:src/components/keyboard-avoiding-view.ios.js | git diff --no-index -- - gutenberg/packages/components/src/mobile/keyboard-avoiding-view.ios.js

git show origin/develop:src/components/keyboard-aware-flat-list.android.js | git diff --no-index -- - gutenberg/packages/components/src/mobile/keyboard-aware-flat-list.android.js

git show origin/develop:src/components/keyboard-aware-flat-list.ios.js | git diff --no-index -- - gutenberg/packages/components/src/mobile/keyboard-aware-flat-list.ios.js

git show origin/develop:src/components/readable-content-view.js | git diff --no-index -- - gutenberg/packages/components/src/mobile/readable-content-view.native.js

Then check the modifications inside gutenberg only:

git diff --diff-filter=M origin/master...HEAD

Known issues

@Tug Tug force-pushed the update/move-block-list-to-gutenberg branch from 3b6bdd2 to 1854229 Compare March 28, 2019 12:58
@Tug Tug mentioned this pull request Apr 4, 2019
@daniloercoli
Copy link
Contributor

Hey @hypest, I checked this PR (mostly run smoke tests) and it seems to work without any issues.
The changes introduced here will break any other open PRs, any idea how we should proceed? Merge it?

@peril-wordpress-mobile
Copy link

Warnings
⚠️ PR is missing at least one label.
⚠️ PR is not assigned to a milestone.
⚠️ PR has more than 500 lines of code changing. Consider splitting into smaller PRs if possible.

Generated by 🚫 dangerJS

@hypest
Copy link
Contributor

hypest commented Apr 5, 2019

The changes introduced here will break any other open PRs, any idea how we should proceed? Merge it?

👋 @daniloercoli . Thanks for the ping. I think that we should at least try to dive into the code side review a bit and if OK we can merge, but not today (today Apr 5th is a release cut day and too late to bring it into the release).

rootViewHeight: number,
safeAreaBottomInset: number,
isFullyBordered: boolean,
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Feels like the AppContainer has picked up lots of implementation details (wrangling the height of a view for example, wrangling the post title, rendering the visual or html mode) while still having the responsibility to setup the editor and other things.

I wonder if that's too much for a component and it'd make sense to introduce a child component at this stage. Maybe re-introduce a MainScreen component like we had in the past. WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure we could.
I think I took the easiest path for this PR because the layout part is intermixed with the RN bridge subscriptions, a bit of refactoring would help here and I thought it was outside the scope of the PR.

Copy link
Contributor

Choose a reason for hiding this comment

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

Reason I think it's in scope here is because this PR (in its current form) removes the component separation we already had in place (between the AppContainer and BlockManager) and puts more stuff in the AppContainer. I think it would be best if we could keep AppContainer as "clean" as it was before. Trusted, it wasn't super clean anyway but, no reason to add more to it.

In essence, to introduce the component that will replace our older BlockManager.

Copy link
Contributor Author

@Tug Tug Apr 10, 2019

Choose a reason for hiding this comment

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

Ok, I'll update it ;)

background-color: #fff;
}

.blockHolderSemiBordered {
Copy link
Contributor

Choose a reason for hiding this comment

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

With the BlockHolder now migrated to the Gutenberg side (by utilizing the BlockEdit component), it's weird that there's a style in the mobile repo about it. Can we move it somehow to the Gutenberg side?

I know that this style is used for the post title component too but, this might be the opportunity to reconcile the two?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll see if I can reconcile those 👍
Again I went the easy way first for this PR, basically just moving modules around and porting the syntax whenever necessary. I agree there is room for improvement/refactoring but I wonder if we should address those beforehand in this PR or merge rapidly to avoid conflicts and refactor after?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it's OK to tackle this one in a separate PR 👍.

Let's add it to a "Known issues" type of section in this PR description so we can help us keep track of it, wdyt?

@hypest
Copy link
Contributor

hypest commented Apr 9, 2019

EDIT 2: False alarm. It seems to be an issue with Vysor. When typing directly from the virtual keyboard there is no char duplication. Will try with an external (BT) keyboard as well.
EDIT: the following also happens on develop (at least on hash 061e052) 😢
I think I've noticed an issue with the post title:

  1. Run the demo app on Android
  2. Clear up the title
  3. Type one character
  4. Notice that the char is repeated and ends up being inserted twice

@Tug
Copy link
Contributor Author

Tug commented Apr 12, 2019

@hypest I've updated the PR, and tried to split AppContainer in 2. Could you have another look when you have time?

@Tug Tug force-pushed the update/move-block-list-to-gutenberg branch from 0b4de7b to 763a396 Compare April 16, 2019 08:52
@@ -100,7 +100,7 @@ describe( 'HTMLInputView', () => {

const wrapper = shallow(
<HTMLInputView
setTitleAction={ setTitleAction }
editTitle={ setTitleAction }
Copy link
Contributor

Choose a reason for hiding this comment

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

Will this prop set override the editTitle provided inside the HTMLInputView itself via withDispatch?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes because we're not importing the default HTMLInputView component here but the original class exported here

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, I see. Gosh, that pattern is super confusing :(. I wish we could make it better.

@@ -28,6 +28,7 @@ type PropsType = {
setTitleAction: string => void,
Copy link
Contributor

Choose a reason for hiding this comment

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

The setTitleAction doesn't seem to be used anymore, can we remove it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Indeed 👍
(weird that flow didn't report it)


const hasChanges = title !== this.lastTitle || html !== this.lastHtml;
const hasChanges = title !== this.post.title.raw || html !== this.post.content.raw;
Copy link
Contributor

@hypest hypest Apr 18, 2019

Choose a reason for hiding this comment

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

I wonder, is the serialization/parsing pair symmetric nowadays? I remember we needed the this.lastHtml = serialize( parse( props.initialHtml || '' ) ) dance because the pair wasn't symmetric. Have you perhaps tried backing out of the block editor in WPAndroid and the post is not marked as changes if no user edits occurred?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I haven't tried but I can have a look with our sample post (initial-html.js)

@koke
Copy link
Member

koke commented May 3, 2019

I started testing from WPiOS and got this error:

  1. Create a new post
  2. Type a title and press enter
  3. Type some paragraph text and press enter
  4. Tap on the inserter button
ExceptionsManager.js:74 Invariant Violation: [715,"RCTView",{"paddingBottom":"<<NaN>>"}] is not usable as a native method argument

This error is located at:
    in RCTView (at View.js:45)
    in View (at KeyboardAvoidingView.js:207)
    in KeyboardAvoidingView (at keyboard-avoiding-view.ios.js:12)
    in KeyboardAvoidingView (at bottom-sheet/index.native.js:138)
    in RCTView (at View.js:45)
    in View (at createAnimatedComponent.js:151)
    in AnimatedComponent (at createAnimatableComponent.js:571)
    in withAnimatable(View) (at src/index.js:437)
    in RCTView (at View.js:45)
    in View (at AppContainer.js:98)
    in RCTView (at View.js:45)
    in View (at AppContainer.js:115)
    in AppContainer (at Modal.js:244)
    in RCTView (at View.js:45)
    in View (at Modal.js:264)
    in RCTModalHostView (at Modal.js:252)
    in Modal (at src/index.js:450)
    in ReactNativeModal (at bottom-sheet/index.native.js:121)
    in BottomSheet (at inserter/index.native.js:26)
    in Inserter (at with-select/index.js:187)
    in ComponentWithSelect (at with-select/index.js:196)
    in WithSelect(Inserter) (at block-list/index.native.js:191)
    in BlockList (at with-dispatch/index.js:122)
    in ComponentWithDispatch (at with-dispatch/index.js:129)
    in WithDispatch(BlockList) (at with-select/index.js:187)
    in ComponentWithSelect (at with-select/index.js:196)
    in WithSelect(WithDispatch(BlockList)) (at VisualEditor.js:83)
    in SlotFillProvider (at provider/index.native.js:130)
    in BlockEditorProvider (at provider/index.native.js:21)
    in WithRegistry(BlockEditorProvider) (at with-dispatch/index.js:122)
    in ComponentWithDispatch (at with-dispatch/index.js:129)
    in WithDispatch(WithRegistry(BlockEditorProvider)) (at VisualEditor.js:77)
    in VisualEditor (at with-dispatch/index.js:122)
    in ComponentWithDispatch (at with-dispatch/index.js:129)
    in WithDispatch(VisualEditor) (at with-select/index.js:187)
    in ComponentWithSelect (at with-select/index.js:196)
    in WithSelect(WithDispatch(VisualEditor)) (at MainScreen.js:115)
    in RCTSafeAreaView (at SafeAreaView.js:45)
    in SafeAreaView (at MainScreen.js:130)
    in MainScreen (at with-select/index.js:187)
    in ComponentWithSelect (at with-select/index.js:196)
    in WithSelect(MainScreen) (at AppContainer.js:190)
    in AppContainer (at with-dispatch/index.js:122)
    in ComponentWithDispatch (at with-dispatch/index.js:129)
    in WithDispatch(AppContainer) (at with-select/index.js:187)
    in ComponentWithSelect (at with-select/index.js:196)
    in WithSelect(WithDispatch(AppContainer)) (at App.js:33)
    in AppProvider (at src/index.js:69)
    in RootComponent (at renderApplication.js:35)
    in RCTView (at View.js:45)
    in View (at AppContainer.js:98)
    in RCTView (at View.js:45)
    in View (at AppContainer.js:115)
    in AppContainer (at renderApplication.js:34)

@koke
Copy link
Member

koke commented May 3, 2019

I don't understand why InlineToolbar has moved to BlockInspector, since those are two different things. The only reason I can think of is that InspectorControls.Slot was previously inside the inline toolbar, which also doesn't make much sense to me.

@koke
Copy link
Member

koke commented May 3, 2019

Beyond the two previous comments, I think this PR is just too big to review. It's good as a proof of concept to know how to do this, but instead of trying to keep up with constant changes while trying to review, I'd break this down in several steps. The most important idea is to avoid moving a file to a different repo and editing it at the same time, since it makes it really hard to evaluate the changes.

The end result of this would be that pretty much all code, except the initialization and app container, would be inside Gutenberg. Since we'll have to remove the flow types for any code we move, I think we should start by removing Flow completely within gutenberg-mobile before we move code (cc @hypest).

I imagine these PRs:

  1. Remove flow from the project and edit any files necessary to remove flow annotations. If we can disable flow per-file, I'd be fine with that, but it doesn't make sense to me to keep flow at this stage. After this PR, we should be able to freely move any file to the Gutenberg repo without changes.
  2. Move every component that was moved in this PR to packages/mobile as is, with no changes, except whatever necessary to make the code work (but no API changes).
  3. Port BlockPicker to Inserter
  4. Port BlockToolbar
  5. Port BlockHolder / InlineToolbar
  6. Port BlockManager to BlockList
  7. (Bonus) Move VisualEditor to Gutenberg. Maybe we want to use initializeEditor as the container like the web, but that's beyond the scope for the block list.

I'd also suggest that any of the mobile-only components should have it's own folder with a README.md.

@hypest
Copy link
Contributor

hypest commented May 3, 2019

we should start by removing Flow completely within gutenberg-mobile before we move code (cc @hypest).

👋 @koke , can you expand on why that'd be a necessary step? Is it perhaps so to be super easy to compare if a file moved in an as pristine form as possible? If that's the reason, I think that with small PRs it won't be hard to review the changes, including the removal of flow markup of the files in each PR.

Basically, I'd prefer if we do not remove flow from the gutenberg-mobile repo, at least not until the only things left in this repo are super trivial. Happy to revise that opinion if removing flow is an actual necessary first step.

By the way, it would be nice if we had some adjustment in processes or tooling (editors/IDEs) to make up for the loss of flowtypes in the Gutenberg repo.

@koke
Copy link
Member

koke commented May 3, 2019

I've been learning a bit more about Flow after that comment, and I don't think we need to remove it, as dropping the @flow declaration from each individual file would be enough.

The goal is to avoid as much as possible having changes to files as they move to another repo. So we would drop the @flow from a file, remove the type annotations, get that merged, then do a PR that just moves the files.

It looks like actually removing flow completely from the project is quite a bit of trouble since that's somewhat coupled to the react native defaults, so I'm fine leaving it, even if we don't use it much.

@Tug
Copy link
Contributor Author

Tug commented Jun 6, 2019

Closing this PR. Progress of this is now being monitored on #958

@Tug Tug closed this Jun 6, 2019
@Tug Tug deleted the update/move-block-list-to-gutenberg branch June 6, 2019 20:12
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