-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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: Trying v1 for the block inserter #307
Conversation
modules/editor/inserter/style.scss
Outdated
padding: 0; | ||
margin-top: 20px; | ||
|
||
a { |
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.
Would be good to start using classes for these.
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.
Would be good to start using classes for these.
And if we do add one, move styles out of nesting. ( Edit: Saw @mtias left a similar comment below, but I'll not remove this so as to reinforce similar reaction 😉 )
modules/editor/inserter/style.scss
Outdated
bottom: 40px; | ||
background: #fff; | ||
|
||
.inserter__arrow { |
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.
Also let's avoid nesting as much as possible when we have a class to keep specificity at the minimum.
modules/editor/inserter/index.js
Outdated
@@ -0,0 +1,22 @@ | |||
const h = wp.element.createElement; |
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.
Why h
?
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.
h because this syntax is inspired by 'hyperscript' https://github.com/hyperhype/hyperscript
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.
Right, but I don't think it makes a lot of sense in our context—why not element
or node
?
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 don't know, I feel it should be as short as possible, could we use e
?
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 have a personal distaste for single letter vars. Though I could compromise on el
;)
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'd prefer something like el
as well, but worth noting that h
was turned into something of a convention with it also being adopted by preact
.
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.
e
is typically used for events.
@@ -1,4 +1,6 @@ | |||
wp.blocks.registerBlock( 'wp/text', { | |||
title: 'Text', |
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.
We'll need to start considering i18n in a separate issue.
I'm ok with avoiding JSX for now. |
Probably fine for now, but I don't think we ought to go out of our way to avoid it. It will be very easy to integrate and will improve readability. |
modules/editor/inserter/index.js
Outdated
@@ -0,0 +1,22 @@ | |||
const h = wp.element.createElement; |
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'd prefer something like el
as well, but worth noting that h
was turned into something of a convention with it also being adopted by preact
.
modules/editor/inserter/style.scss
Outdated
padding: 0; | ||
margin-top: 20px; | ||
|
||
a { |
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.
Would be good to start using classes for these.
And if we do add one, move styles out of nesting. ( Edit: Saw @mtias left a similar comment below, but I'll not remove this so as to reinforce similar reaction 😉 )
modules/editor/editor.js
Outdated
@@ -1,8 +1,45 @@ | |||
import InserterButton from './inserter/button'; |
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.
Should we keep with External
, Internal
docblocks?
modules/editor/editor.js
Outdated
|
||
const h = wp.element.createElement; | ||
|
||
const EditorComponent = ( { content, state: { inserter }, toggleInserter } ) => { |
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.
Something bothers me about components not being in their own standalone file. Maybe I'm overthinking it. Alternative might be editor/index.js
(raw class) and editor/editor.js
(component) but then the path becomes editor/editor/editor.js
😬
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.
Also destructuring any more than one level deep quickly becomes unreadable. I think this one isn't so bad but we should be cautious of it.
modules/editor/editor.js
Outdated
const h = wp.element.createElement; | ||
|
||
const EditorComponent = ( { content, state: { inserter }, toggleInserter } ) => { | ||
return h( 'div', {}, |
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 might be a minuscule performance benefit to passing null
instead of {}
because it can be skipped more easily by a simple truthy test.
modules/editor/inserter/button.js
Outdated
const InserterButton = ( { opened, onClick } ) => { | ||
return h( 'div', { className: 'inserter__button' }, | ||
h( 'a', { onClick }, | ||
h( 'span', { className: 'dashicons dashicons-plus' } ) |
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.
Do you think we ought to create a component for Dashicons, assuming this will be a very common pattern? Or is it obvious enough to apply the classes? Where would said component live if we were to introduce 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.
There's been a few comments about icons that I'll defer to @jasmussen as to how to proceed.
I'm seeing the following error when running
|
The above issue looks to have been caused by lingering files in the In any case, this needs a rebase, but nothing else stands out to me needing changes. 👍 |
.gutenberg { | ||
background: #fff; | ||
margin: -20px 0 0 -20px; | ||
padding: 60px; | ||
|
||
* { | ||
box-sizing: border-box; |
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.
In our prototype @intronic and me have been using CSS modules which allows for a better style encapsulation and maintainability. I think it's a step above BEM and it would be worth trying. A first step towards this direction would be to start migrating some sections such this one.
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 agree CSS modules is really nice. Maybe, we could consider it once we settle the other moving parts.
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 not too keen on CSS modules (nor it's evolution in styled-components), I think they erode semantics, and complicate things in which CSS is good at (passing props to style things couples the whole node tree with the intentions of a grand-parent that may want to modify a grand-children style props).
In our case I think it makes even less sense because blocks will be restyled by themes, so we do need the strong semantics and ability to externally modify styles. The pseudo BEM here is not strictly BEM either (we don't rely on the same kind of modifier) and is something we've been using in Calypso to reflect the component structure in place.
- Rename h to el - Extract the editor component to its own file
a085665
to
f24298b
Compare
In this PR, I'm trying to add the block inserter to the plugin. This is the first UI element we make, thus, it raises a lot of questions we need to answer before merging this.
Block API:
In this PR, I'm adding a title and an icon as strings to the block API, we probably need a
category
as well (I left it for another PR)React Component
We're relying on
createElement
which is an abstraction of React to compose our UI. But we'll probably need more than that. Think refs, state ..... Should we exportComponent
as well inwp.element
?In the first iteration of this PR, I avoided explicitly
Component
and simulatedsetState
on theEditor
class.React Dependencies: react-tooltip, react-clickoutside, ...
Another thing to consider while building the UI is the need of some ready to use React Components (external dependencies like
react-tooltip
or anything else). I think, even if using these external components would work like a charm, "logically", we can not use them in our UI because we're hiding React, this means we don't know if they're compatible with our abstraction.JSX
I avoided explicitly JSX here, IMO this is not a big "loss" but this point should be raised I think.
Icons
I'm using the regular WordPress Dashicons (using classnames) in this PR, but I know these are not perfect and we may prefer using SVG. Maybe this could be changed later.
Class properties
I've used
.bind
(this makes me think I should have moved the call to the constructor) while using https://babeljs.io/docs/plugins/transform-class-properties/ is nicer. Thoughts on adding this babel plugin?