-
Notifications
You must be signed in to change notification settings - Fork 58
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
Conversation
3b6bdd2
to
1854229
Compare
…list-to-gutenberg
…list-to-gutenberg
Hey @hypest, I checked this PR (mostly run smoke tests) and it seems to work without any issues. |
Generated by 🚫 dangerJS |
👋 @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). |
src/app/AppContainer.js
Outdated
rootViewHeight: number, | ||
safeAreaBottomInset: number, | ||
isFullyBordered: boolean, | ||
} |
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.
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?
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.
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.
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.
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.
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.
Ok, I'll update it ;)
background-color: #fff; | ||
} | ||
|
||
.blockHolderSemiBordered { |
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.
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?
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'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?
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 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?
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.
|
…list-to-gutenberg
…list-to-gutenberg
…list-to-gutenberg
@hypest I've updated the PR, and tried to split AppContainer in 2. Could you have another look when you have time? |
0b4de7b
to
763a396
Compare
@@ -100,7 +100,7 @@ describe( 'HTMLInputView', () => { | |||
|
|||
const wrapper = shallow( | |||
<HTMLInputView | |||
setTitleAction={ setTitleAction } | |||
editTitle={ setTitleAction } |
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.
Will this prop set override the editTitle
provided inside the HTMLInputView
itself via withDispatch
?
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.
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.
Ah, I see. Gosh, that pattern is super confusing :(. I wish we could make it better.
src/components/html-text-input.js
Outdated
@@ -28,6 +28,7 @@ type PropsType = { | |||
setTitleAction: string => void, |
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.
The setTitleAction
doesn't seem to be used anymore, can we remove it?
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 👍
(weird that flow didn't report it)
This reverts commit ed9a548.
|
||
const hasChanges = title !== this.lastTitle || html !== this.lastHtml; | ||
const hasChanges = title !== this.post.title.raw || html !== this.post.content.raw; |
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 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?
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 haven't tried but I can have a look with our sample post (initial-html.js
)
I started testing from WPiOS and got this error:
|
I don't understand why |
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:
I'd also suggest that any of the mobile-only components should have it's own folder with a |
👋 @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. |
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 The goal is to avoid as much as possible having changes to files as they move to another repo. So we would drop the 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. |
Closing this PR. Progress of this is now being monitored on #958 |
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.js
→gutenberg/packages/block-editor/src/components/block-list/index.native.js
along with its styles.SafeArea
has been moved tosrc/app/AppContainer
andsrc/app/VisualEditor
as we needed a way to extract the post title from the BlockList component. For this we introduce a new propheader
which is passed to FlatList asListHeaderComponent
.src/block-management/block-holder.js
→gutenberg/packages/block-editor/src/components/block-list/block.native.js
along with its stylessrc/block-management/block-picker.js
→gutenberg/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 functionsrc/block-management/block-toolbar.js
→gutenberg/packages/block-editor/src/components/block-toolbar/index.native.js
along with its stylessrc/block-management/inline-toolbar/index.js
→gutenberg/packages/block-editor/src/components/block-inspector/index.native.js
along with its stylessrc/components/keyboard-avoiding-view.*.js
→gutenberg/packages/components/src/mobile/keyboard-avoiding-view.*.js
src/components/keyboard-aware-flat-list.*.js
→gutenberg/packages/components/src/mobile/keyboard-aware-flat-list.*.js
src/components/readable-content-view.js
→gutenberg/packages/components/src/mobile/readable-content-view.native.js
gutenberg/packages/editor/src/components/mobile/bottom-sheet
→gutenberg/packages/components/src/mobile/bottom-sheet
gutenberg/packages/editor/src/components/mobile/picker
→gutenberg/packages/components/src/mobile/picker
gutenberg/packages/editor/src/components/mobile/unsupported-block
→gutenberg/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:
Then check the modifications inside gutenberg only:
Known issues