-
Notifications
You must be signed in to change notification settings - Fork 56
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
Conversation
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) |
Fixed the duplicate object / focus problems by correctly implementing |
After reviewing this one but before merging it, please review and merge #89 first 👍 |
…block-gb Inserter - use GB createBlock to generate new blocks
…sed: false prop in new object
This PR has a problem keeping up with the |
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 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, |
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.
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.
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.
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)
src/store/actions/test.js
Outdated
@@ -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(); |
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.
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.
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.
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)
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'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?
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.
addressed in a04c5e9
src/store/actions/test.js
Outdated
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 ); | ||
} ); |
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.
Any particular reason for not testing the clientId
value too as in the rest if this test case?
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.
src/store/actions/test.js
Outdated
@@ -2,6 +2,9 @@ | |||
|
|||
import * as actions from './'; | |||
import ActionTypes from './ActionTypes'; | |||
// Gutenberg imports | |||
import { getBlockType, serialize, createBlock } from '@wordpress/blocks'; |
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.
getBlockType
and serialize
don't seem to be used anymore, can we remove them?
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.
nice catch! addressed in 54220f8
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.
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?
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.
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 👍
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.
Looks good to me @mzorz !
This PR has the minimum needed in order to make new blocks appear in the list.
+
iconFor 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 tomaster
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)