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

Inserter - basic support for block addition #88

Merged
merged 34 commits into from
Aug 13, 2018

Conversation

mzorz
Copy link
Contributor

@mzorz mzorz commented Aug 1, 2018

This PR has the minimum needed in order to make new blocks appear in the list.

  1. tap on a non-editable bock to gain focus and make the item toolbar appear
  2. tap on the + icon
  3. scroll down the list and observe a new block has been added.
  4. repeat as many times as you wish, and observe you can also delete blocks.

For now, we're producing only one type of block paragraph (even when the function is parameterized) and only appending to the list (I have plans to make direct insertion). Also, we make use of the current item toolbar, as I plan to make small steps / PRs as we go to make small additions (like a standalone + that checks the currently focused item and appends a new block right below, and so on).

The list of steps is available here which I'll use as a master issue and link this and upcoming PRs there as well.

I plan to make all PRs against the feature/inserter, and merge that one to master once all done.

Note (and question at the same time) for the reviewers: in order to make this work, I'm creating an empty block object in two places: one for the list as in the UI element, and another one in the reducer as in the Redux model. It bugs me that I'm creating 2 different objects, so I'm most probably not doing something right. While I'm exploring it, please don't hesitate to provide any insights as to whether this should be fine or not, and if not, feel free to provide any alternatives you can think of to make this cleaner.

Known issue: the item toolbar does not appear when the new items are focused (tapped on). Working on that for a bit, but I don't think is something I should spend much time on, as the toolbar will be handled differently anyway.

Known issue: #88 (comment)

@mzorz mzorz mentioned this pull request Aug 1, 2018
4 tasks
@mzorz
Copy link
Contributor Author

mzorz commented Aug 1, 2018

Known issue: the item toolbar does not appear when the new items are focused (tapped on). Working on that for a bit, but I don't think is something I should spend much time on, as the toolbar will be handled differently anyway.

Actually looking closer I think this is quite tight related to the other observation (having 2 different objects is no good). Idea: I think we should rather create in one place (the redux store) and then request a re-render as the list has changed, but not change the in-memory list (it should change itself by following the cycle)

@mzorz
Copy link
Contributor Author

mzorz commented Aug 1, 2018

Fixed the duplicate object / focus problems by correctly implementing createBlock in 2beaebd

@mzorz
Copy link
Contributor Author

mzorz commented Aug 2, 2018

After reviewing this one but before merging it, please review and merge #89 first 👍

@mzorz
Copy link
Contributor Author

mzorz commented Aug 8, 2018

This PR has a problem keeping up with the focused state on newly created blocks, which is addressed in #95 (targeting this branch). That PR should be merged first 👍

Copy link
Contributor

@hypest hypest left a comment

Choose a reason for hiding this comment

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

I left a couple of comments @mzorz , please have a look.

All in all though, happy to see this first PR for the Inserter! Also, thanks for updating some tests in here!


export type BlockListType = {
onChange: ( clientId: string, attributes: mixed ) => void,
focusBlockAction: string => mixed,
moveBlockUpAction: string => mixed,
moveBlockDownAction: string => mixed,
deleteBlockAction: string => mixed,
createBlockAction: ( string, BlockType ) => mixed,
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, apparently we're passing an already instantiated block to the action so, I wonder if the naming ("createBlock...") is a bit off here. I'd kinda expect to pass some identifier and/or params in order for the reducer to instantiate the block. Not sure which way is the web side of Gutenberg's doing this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Rightly spotted @hypest - as discussed on Slack, this is something I had plans for in a later PR, to take care of bringing this closer to GB 👍
Trackerd in my item list here #58 (comment)

@@ -32,5 +35,13 @@ describe( 'Store', () => {
expect( action.type ).toEqual( ActionTypes.BLOCK.DELETE );
expect( action.clientId ).toEqual( '1' );
} );

it( 'should create an action to create a block', () => {
registerCoreBlocks();
Copy link
Contributor

Choose a reason for hiding this comment

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

This feels like a big thing to do while in a section of an otherwise simple test where we just test the fields of a newly created action object.

Can we perhaps mock the block to pass it to the action creation function?

On the other hand, judging from the convo we had over Slack, this will probably change when the block creation itself might move into the reducer so, perhaps we can leave this PR as is.

Copy link
Contributor Author

@mzorz mzorz Aug 10, 2018

Choose a reason for hiding this comment

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

That's a good observation - also this test for now tests for creation action type only but I think should check for each of the registered blocks if that makes sense (once the function actually creates a block instead of just carrying a block to be added/inserted).

Added to my item list #58 (comment)

Copy link
Contributor

@hypest hypest Aug 13, 2018

Choose a reason for hiding this comment

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

I'm still not comfortable with registerCoreBlocks being inside the testcase since it's not the subject of the test itself. Let's move it to the beforeAll section so it's clear that it's part of the setup, not the test. 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.

👍

Copy link
Contributor Author

Choose a reason for hiding this comment

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

addressed in a04c5e9

const newBlock = createBlock( 'core/code', { content: 'new test text for a core/code block' } );
const action = actions.createBlockAction( '1', newBlock );
expect( action.type ).toEqual( ActionTypes.BLOCK.CREATE );
} );
Copy link
Contributor

Choose a reason for hiding this comment

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

Any particular reason for not testing the clientId value too as in the rest if this test case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

addressed in 6ad3813 - and for completeness added check for the block in e556378

@@ -2,6 +2,9 @@

import * as actions from './';
import ActionTypes from './ActionTypes';
// Gutenberg imports
import { getBlockType, serialize, createBlock } from '@wordpress/blocks';
Copy link
Contributor

Choose a reason for hiding this comment

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

getBlockType and serialize don't seem to be used anymore, can we remove them?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

nice catch! addressed in 54220f8

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for the change @mzorz ! Apparently, the eslint configuration is actually faulty at the moment since this one should be caught during yarn lint (which is already part of the Travis tests).

I will produce a separate PR with the eslint fix (and also fix there a few other violations) so to not pollute this PR, cool?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for explaining and describing where things are / need to be and follow up actions🙇 thank you! Also think the decision to make a separate PR for eslint fixes is in the right direction 👍

Copy link
Contributor

@hypest hypest left a comment

Choose a reason for hiding this comment

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

Looks good to me @mzorz !

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.

3 participants