Parse html into known blocks #100

etoledom · 2018-08-10T00:07:21Z

Part of #99

This PR adds the ability of parsing the html string in the html view back into blocks.

For simplicity, the current implementation will just parse the known blocks, and anything that is outside of those blocks will be ignored.

An example on iOS:

On Android, this currently won't work, but this issue was taken care of by #95. I tested a fast merge and it works:

There are many details I wasn't sure about, I chose the simplest solutions for all of them, but I hope this PR is a good place to discuss them. The most important ones are:

The only way to modify blocks is with a redux action.

The current reducer seems to me that is meant for actions over a single block, but the parse action will regenerate the whole list of blocks.

I was tempted to create another reducer specifically for parser, but it immediately made this implementation (and PR) grow on complexity, so I opted to add an extra action to the current reducer.

HTML InputView content as part of the component state.

An interesting question I had was where to keep the state of the text that the user is editing.
My first test was to store it as part of the component state (as the example shows), but for each time the state changes, a new instance of the view is created. This makes the whole UX very bad when editing on a scrolled position.

I also though about the redux store, but I wasn't sure about it and it was more complex than the next option.

I opted to simply store the edited text in a variable.

…/parse-html-into-blocks

Mainly to fix `flow` errors. Flow also doesn't like curried annotation :[

gziolo · 2018-08-10T06:10:04Z

src/store/reducers/index.js

 		}
+		case ActionTypes.BLOCK.PARSE: {
+			const parsed = action.parse(action.payload)
+			return { blocks: parsed, refresh: state.refresh };


Why not import parse in this file instead of passing it down every time you want to use it?

The idea was to avoid a hard coded dependency.
But for simplicity I'd agree that it would be better to import it directly. 👍

gziolo · 2018-08-10T06:12:43Z

src/store/reducers/index.js

 		}
+		case ActionTypes.BLOCK.PARSE: {
+			const parsed = action.parse(action.payload)
+			return { blocks: parsed, refresh: state.refresh };


The whole idea of using Redux store is to take advantage of immutability. when you update reference to the blocks, you can treat it as an indicator if something has changed. This makes usage of refresh boolean flag obsolete as it tracks the state which can be derived from blocks.

So, we should remove refresh from the store, right?
In that case I'd prefer to do that on a separate PR.

@hypest or @mzorz might know why it was necessary to add it?

gziolo · 2018-08-10T06:13:54Z

src/store/actions/index.js

+
+export const parseBlocksAction: BlockActionType = (payload, parser) => ( {
+	type: ActionTypes.BLOCK.PARSE,
+	uid: '',


uid can be removed, it is never used. When parsing blocks from HTML you can get multiple blocks and as far as I see, it replaces all content.

If I remove uid, flow gets angry saying that 'uid' is missing in object literal, since BlockActionType expects a uid property.
That's one reason why I thought that a new reducer operating in the same store might be a good idea.

Instead, I'm inclined to define a ParseActionType to keep it simple, remove uid and keep flow happy.

gziolo · 2018-08-10T06:16:51Z

src/block-management/block-manager.js

-					style={ styles.htmlView }>
-					{ this.serializeToHtml() }
+					style={ styles.htmlView }
+					onChangeText={ ( html ) => this.props.html = html }>


You should never mutate props, you should track changes to html in state. In this case, you rather should pass down callback to this component which will update html outside.

My original idea was to keep track of the html updates in a simple property this.html, but I kept getting a flow warning about it not being part of the BlockManager type.

I tried to add it as part of the component state but on every update, the InputView is reloaded and it feels weird from a UX point of view (but it works).

What would be the advantage of lifting the html state up vs keeping it in the component's state?

I also tried what is described here (lifting state up), but the jumpiness remains.

gziolo · 2018-08-10T06:18:05Z

src/block-management/block-manager.js

 	}

+	componentDidMount() {
+		this.serializeToHtml();


This function returns string, so it should be assigned to a variable.

This was an experiment and I forgot to remove it 😞
Thanks for catching it!

gziolo · 2018-08-10T06:22:43Z

An interesting question I had was where to keep the state of the text that the user is editing.
My first test was to store it as part of the component state (as the example shows), but for each time the state changes, a new instance of the view is created. This makes the whole UX very bad when editing on a scrolled position.

This is because you mutate props.html - see my inline comment :)

The current reducer seems to me that is meant for actions over a single block, but the parse action will regenerate the whole list of blocks.

I had a similar concern. I wouldn't spend too much time doing it yourself using your own store. All those issues are already solved in web version of Gutenberg. Speaking myself, I would focus of integrating functionalities and we can improve the general architecture by integrating with the existing editor store and resetBlocks action:
https://github.com/WordPress/gutenberg/blob/master/packages/editor/src/store/actions.js#L105-L110

…/parse-html-into-blocks

mzorz

Nice work @etoledom :) I only left a couple of minor comments 👍

mzorz · 2018-08-11T12:02:12Z

src/store/reducers/test.js

 import * as actions from '../actions/';
+import { registerCoreBlocks } from '@gutenberg/core-blocks';
+
+registerCoreBlocks()


Small nit - should we register the blocks here or within the specific test, when there's only one test using them? deferring to @hypest here as a related comment is taking place in #88 (comment)

I was following the example from block-parser-code.test.js and the others, but if it makes more sense to put them in the test case itself, no problem!

What it feels weird to me is that we are testing parsing two times, one from the parse function directly and other from the redux action indirectly (just the more block for now). Maybe we can find a way to do it just once.

hi! - I just moved a similar case to beforeAll() as per https://github.com/wordpress-mobile/gutenberg-mobile/pull/88/files/e55637838c3f16fefc5ef8de028855ebeaac209f#r209576735 in commit a04c5e9 - wdyt?

Sounds good! I'll go for it. Thank you

mzorz · 2018-08-11T12:13:03Z

src/store/actions/index.js

+
+export const parseBlocksAction: ParseActionType = payload => ( {
+	type: ActionTypes.BLOCK.PARSE,
+	payload: payload,


Small nit - can we rename payload to html as an indication of what the payload is supposed to be about?

mzorz · 2018-08-11T12:29:16Z

Tests are failing but they're passing for me locally when running yarn test 🤔

hypest · 2018-08-11T13:03:48Z

Tests are failing but they're passing for me locally when running yarn test 🤔

FWIW, the tests fail for me locally with the same errors seen on Travis. cc @mzorz

etoledom · 2018-08-11T14:04:17Z

I got the same tests error locally when I updated the branch from master, it was solved when I run git submodule update.

etoledom · 2018-08-13T13:55:58Z

@mzorz I pushed a couple more commits. I hope those handle your comments :)

About the tests, I think I merged wrongly the reference to the gutenberg project and that's why the tests keep failing. I'm looking into it

…/parse-html-into-blocks

mzorz · 2018-08-14T18:40:50Z

Very nice @etoledom ! 🙇 been testing it quite a bit today

On Android, this currently won't work, but this issue was taken care of by #95. I tested a fast merge and it works:

Given #95 has been closed without merging, due to a better solution to our specific case having been found in #108, I think we still need to address this here. Knowing this might be a bit too much to ask for to do in this PR alone, I went ahead and tried something on my own in #116 (I just didn't feel suggesting something without making sure it would work first was good enough, and so I ended up with a PR 😄).

Hope that's alright! Please feel free to comment / indicate otherwise. Ccing @hypest

HTML parser - restart datasource after full parse of html

mzorz

With #116 merged, all is good here! :)

Use Bintray mirror of RN when building in Jitpack

etoledom added 6 commits August 9, 2018 16:30

Added action to parse html into blocks

c6b1b08

Merge branch 'feature/editable-html-view-feature-branch' into feature…

8e26b60

…/parse-html-into-blocks

Remove reducer dependency on parser

01be09f

Lint fixes

e7a7ff8

AppContainer: Removed unused parser property from mapStateToProps

885a47b

Minor code clean up

288178a

etoledom added the [Type] Enhancement Improves a current area of the editor label Aug 10, 2018

etoledom self-assigned this Aug 10, 2018

etoledom requested review from hypest and mzorz August 10, 2018 00:07

block-manager: added html property as a prop.

ce96e20

Mainly to fix `flow` errors. Flow also doesn't like curried annotation :[

etoledom mentioned this pull request Aug 10, 2018

Editable HTML view master issue. #99

Closed

2 tasks

lint --fix

a9647ea

gziolo reviewed Aug 10, 2018

View reviewed changes

etoledom added 8 commits August 10, 2018 12:35

block-manager: removed parser and html from props

79935ed

block-manager: remove unnecesary componentDidMount

419e4fa

Actions: remove uid from parseBlocksAction

770eeaa

block-manager: Adding html as part of the component state

eb2a720

BlockListType: remove parser from parseBlocksAction

18acd22

fix parseBlocksAction test

75dd4bf

Merge branch 'master' into feature/parse-html-into-blocks

4aed861

Merge branch 'feature/editable-html-view-feature-branch' into feature…

77b2c10

…/parse-html-into-blocks

mzorz reviewed Aug 11, 2018

View reviewed changes

etoledom added 2 commits August 13, 2018 07:15

parseBlocksAction: rename payload to html

55716fe

reducer tests: Moved registerCoreBlocks() to beforeAll()

91ffa52

etoledom added 2 commits August 13, 2018 08:01

merge submodule commit

cc6534a

Merge branch 'feature/editable-html-view-feature-branch' into feature…

1b79efb

…/parse-html-into-blocks

This was referenced Aug 14, 2018

Unknown block proof of concept #109

Closed

Fix jumpy html text input on iOS #115

Merged

restart datasource after full parse of html

586526b

mzorz mentioned this pull request Aug 14, 2018

HTML parser - restart datasource after full parse of html #116

Merged

Merge pull request #116 from wordpress-mobile/try/mario-full-parse

59db4ae

HTML parser - restart datasource after full parse of html

mzorz approved these changes Aug 15, 2018

View reviewed changes

etoledom merged commit 2265ab4 into feature/editable-html-view-feature-branch Aug 15, 2018

hypest added a commit that referenced this pull request Jan 3, 2019

Merge pull request #100 from wordpress-mobile/maven-mirror

ff70a7b

Use Bintray mirror of RN when building in Jitpack

SergioEstevao deleted the feature/parse-html-into-blocks branch February 7, 2019 13:28

Parse html into known blocks #100

Parse html into known blocks #100

Uh oh!

Conversation

etoledom commented Aug 10, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gziolo commented Aug 10, 2018

Uh oh!

mzorz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

etoledom Aug 11, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mzorz commented Aug 11, 2018

Uh oh!

hypest commented Aug 11, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

etoledom commented Aug 11, 2018

Uh oh!

etoledom commented Aug 13, 2018

Uh oh!

mzorz commented Aug 14, 2018

Uh oh!

mzorz left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

etoledom Aug 11, 2018 •

edited

Loading

hypest commented Aug 11, 2018 •

edited

Loading