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: Trying v1 for the block inserter #307

Merged
merged 2 commits into from
Mar 24, 2017
Merged

Conversation

youknowriad
Copy link
Contributor

@youknowriad youknowriad commented Mar 23, 2017

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 export Component as well in wp.element?

In the first iteration of this PR, I avoided explicitly Component and simulated setState on the Editor 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?

@youknowriad youknowriad added the Framework Issues related to broader framework topics, especially as it relates to javascript label Mar 23, 2017
@youknowriad youknowriad self-assigned this Mar 23, 2017
@youknowriad youknowriad requested review from mtias and aduth March 23, 2017 10:21
padding: 0;
margin-top: 20px;

a {
Copy link
Member

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.

Copy link
Member

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 😉 )

bottom: 40px;
background: #fff;

.inserter__arrow {
Copy link
Member

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.

@@ -0,0 +1,22 @@
const h = wp.element.createElement;
Copy link
Member

Choose a reason for hiding this comment

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

Why h?

Copy link
Contributor Author

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

Copy link
Member

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?

Copy link
Contributor Author

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?

Copy link
Member

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 ;)

Copy link
Member

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.

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',
Copy link
Member

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.

@mtias
Copy link
Member

mtias commented Mar 23, 2017

I'm ok with avoiding JSX for now.

@mtias mtias added the [Type] Task Issues or PRs that have been broken down into an individual action to take label Mar 23, 2017
@mtias mtias changed the title Plugin: Trying adding a v1 for the block inserter Inserter: Trying v1 for the block inserter Mar 23, 2017
@aduth
Copy link
Member

aduth commented Mar 23, 2017

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.

@@ -0,0 +1,22 @@
const h = wp.element.createElement;
Copy link
Member

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.

padding: 0;
margin-top: 20px;

a {
Copy link
Member

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 😉 )

@@ -1,8 +1,45 @@
import InserterButton from './inserter/button';
Copy link
Member

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?


const h = wp.element.createElement;

const EditorComponent = ( { content, state: { inserter }, toggleInserter } ) => {
Copy link
Member

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 😬

Copy link
Member

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.

const h = wp.element.createElement;

const EditorComponent = ( { content, state: { inserter }, toggleInserter } ) => {
return h( 'div', {},
Copy link
Member

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.

const InserterButton = ( { opened, onClick } ) => {
return h( 'div', { className: 'inserter__button' },
h( 'a', { onClick },
h( 'span', { className: 'dashicons dashicons-plus' } )
Copy link
Member

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?

Copy link
Member

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.

@aduth
Copy link
Member

aduth commented Mar 24, 2017

I'm seeing the following error when running npm run dev or npm run build:

ERROR in Entry module not found: Error: Can't resolve './modules/modules/index.js' in '/Users/andrew/Documents/Code/vvv/www/editor/htdocs/wp-content/plugins/gutenberg'

@aduth
Copy link
Member

aduth commented Mar 24, 2017

The above issue looks to have been caused by lingering files in the modules directory. In this case there was an extra modules folder including only build files, hence why it wasn't apparent in git diff (ignored). Removing it fixed the issue, though I've also seen this in the past with .DS_Store hidden macOS files. I'm guessing our Webpack modules folder globbing is being a little too permissive. We might need to think of a better long-term plan, maybe directly picking modules.

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;
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Member

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
@youknowriad youknowriad force-pushed the try/adding-inserter branch from a085665 to f24298b Compare March 24, 2017 09:26
@youknowriad youknowriad merged commit 03ec179 into master Mar 24, 2017
@youknowriad youknowriad deleted the try/adding-inserter branch March 24, 2017 09:32
@mtias mtias mentioned this pull request Mar 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Framework Issues related to broader framework topics, especially as it relates to javascript [Type] Task Issues or PRs that have been broken down into an individual action to take
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants