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

Address "wide" alignment programatically #812

Merged
merged 15 commits into from
Jun 8, 2017
Merged

Address "wide" alignment programatically #812

merged 15 commits into from
Jun 8, 2017

Conversation

mtias
Copy link
Member

@mtias mtias commented May 16, 2017

This currently showcases the desired behaviour we want.

What I like is that it restricts side-effects that overflows and vw seem to have. What I dislike is that we need to dispatch when changes that affect content width happen (collapsing wp-admin sidebar manually).

@mtias mtias added [Feature] Blocks Overall functionality of blocks General Interface Parts of the UI which don't fall neatly under other labels. [Status] In Progress Tracking issues with work in progress labels May 16, 2017
Copy link
Member

@aduth aduth left a comment

Choose a reason for hiding this comment

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

A related need for editor bounds (top, right, left) has been raised at https://github.com/WordPress/gutenberg/pull/839/files#diff-77cea533850e86cf5a0031b0acc4c0b2R40

editor/state.js Outdated
@@ -303,6 +303,21 @@ export function isSidebarOpened( state = false, action ) {
return state;
}

export function editorWidth( state = null, action ) {
const layout = document.querySelector( '.editor-layout__content' );
Copy link
Member

Choose a reason for hiding this comment

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

These seem like arguments that should be passed in through action properties, not extracted by the reducer itself.

Given the same arguments, it should calculate the next state and return it. No surprises. No side effects. No API calls. No mutations. Just a calculation.

http://redux.js.org/docs/basics/Reducers.html#handling-actions

Copy link
Member

Choose a reason for hiding this comment

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

Also, every reducer is called for every action, so these query selectors are executed very often, and almost always needlessly so. At the very least we should check action.type before performing any queries.

Copy link
Member Author

@mtias mtias May 23, 2017

Choose a reason for hiding this comment

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

@aduth passing as action properties would mean we need to calculate wherever we dispatch the action, which doesn't seem great.

Copy link
Member

Choose a reason for hiding this comment

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

which doesn't seem great.

In what way? We're not really computing much. We could persist references to the DOM nodes. Apparently offsetWidth can force a reflow, but if it's tied to resize event, shouldn't be a concern (or, rather, we're going to have to call it anyways).

Copy link
Member Author

Choose a reason for hiding this comment

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

I mean more about cases where we may dispatch this from other places of the app, like the sidebar toggle. We shouldn't have to repeat the code there, I think.

Copy link
Member

Choose a reason for hiding this comment

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

Hmm, might be middleware territory in an ideal solution then.

@jasmussen jasmussen added this to the Beta milestone May 22, 2017
@jasmussen jasmussen added the [Priority] High Used to indicate top priority items that need quick attention label May 22, 2017
class Layout extends wp.element.Component {

componentDidMount() {
window.addEventListener( 'resize', this.props.setEditorWidth );
Copy link
Member

Choose a reason for hiding this comment

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

We might consider debouncing this very noisy event.

Copy link
Contributor

Choose a reason for hiding this comment

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

We might consider debouncing this very noisy event.

This ^

}

componentWillUnmount() {
window.removeEventListener( 'resize', this.props.setEditorWidth );
Copy link
Member

Choose a reason for hiding this comment

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

We should confirm that mapDispatchToProps is only called once for the lifetime of the component. Otherwise we run the risk of the reference here to setEditorWidth not being the same as the one assigned in componentDidMount, leaving zombie event listeners.

@@ -17,9 +17,14 @@
}

&[data-align="wide"] {
margin-left: -24%;
Copy link
Member

Choose a reason for hiding this comment

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

How well does this work on smaller viewports?

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm yes this, for some reason, doesn't actually scale to the viewport. Replacing it with 5vw is seems to behave as intended.

@jasmussen
Copy link
Contributor

@mtias I pushed a few responsive fixes to this branch, which will also benefit master. Do you think we can get this branch shipped to master this week? It'd be real nice to have.

@mtias
Copy link
Member Author

mtias commented Jun 5, 2017

Yes, we'll get something this week. Discussing with @aduth the tradeoffs of the implementation.

@jasmussen jasmussen modified the milestones: May 29 to Jun 2, Beta Jun 5, 2017
@aduth
Copy link
Member

aduth commented Jun 5, 2017

Somewhat related: #1023

@mtias mtias removed this from the Beta milestone Jun 6, 2017
@mtias mtias force-pushed the fix/full-width branch 2 times, most recently from 61bf132 to 79fe513 Compare June 7, 2017 15:44
jasmussen and others added 10 commits June 7, 2017 18:15
This also adds a few improvements from the now deleted branch, #799, notably:

- clearing for video blocks. The responsive trickery means we have to, or we will get odd behavior otherwise
- better collapsing margins fix for the toolbar.
Update when sidebar is toggled.
There were some issues with centering blocks, due to the fact that it has a block mover on the left.

This commit simplifies that math, so the block mover doesn't actually affect the padding of the block, but rather uses negative space, making the math simpler.

Additionally, it adds some responsive fixes for the full wide toolbar positioning.
@mtias mtias removed the [Status] In Progress Tracking issues with work in progress label Jun 7, 2017
Copy link
Member

@aduth aduth left a comment

Choose a reason for hiding this comment

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

Much happier to be solving this with CSS.

padding-left: 0;
padding-right: 0;
margin-right: -#{ $block-padding + $block-mover-margin }; /* Compensate for .editor-visual-editor centering padding */
box-sizing: border-box;
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

👍

margin-left: auto;
margin-right: auto;
}
max-width: $visual-editor-max-width - ( ( $block-padding + $block-padding + $block-mover-margin ) * 2 );;
Copy link
Member

Choose a reason for hiding this comment

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

Double semi-colon ending.

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 move following comments before the max-width line?

Copy link
Contributor

Choose a reason for hiding this comment

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

👍

I think the max-width was removed just now.

margin-right: $block-mover-padding-hidden + $block-padding;

@include break-small() {
width: 100%;
Copy link
Member

Choose a reason for hiding this comment

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

The position of the controls isn't quite right when at wide or full alignments. You can see it move left and right when toggling between an image "Align left" and "Align wide".

I think we need to assign width: $visual-editor-max-width; max-width: none;

Copy link
Contributor

Choose a reason for hiding this comment

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

👍

We are emulating floats using margins. This works well enough, but has some responsive implications. This commit addresses those, by creating a mix-in that simplifies the breakpoints.

I couldn't quite figure out where to best place this mixin, and we also probably want to extract both the mixin, the variables, and even the left/right alignment code so that other blocks that utilize these don't have to copy the whole bit of code. But I wanted to push this so we can test, and then discuss.
Clean up double semicolons, better center toolbars, remove border-box.
@jasmussen
Copy link
Contributor

Addressed the feedback items, and also made the floats work with responsive.

Take an extra look at a4d712e — I wrote a small mix-in to simplify the responsive stuff a bit. Thankfully it's enough with three rules.

Essentially we have to deal with responsive breakpoints that are unique to the editor, and unique to whether post settings is open or closed.

I could use advice on:

  1. how the mixin can be improved
  2. where it should live
  3. per item 2, where it should live so that we can re-use the same code for any block that lets you left or right float an item.

I'm antsy to get this branch in though, so perhaps it'd be good if we could separate feedback in two groups. 1 — improving the code so we can merge this, and 2 — feedback we can address in a later PR. Thanks.

@aduth
Copy link
Member

aduth commented Jun 7, 2017

where it should live

We could move it to apply to any .editor-visual-editor__block. Is sorta how we're already treating it anyways with getEditWrapperProps.

@jasmussen
Copy link
Contributor

Okay, took your advice and moved both the mixin and the alignments.

@mtias what do you think? Ready to go?

@jasmussen
Copy link
Contributor

This branch, when merged, fixes #784 and #546.

@mtias
Copy link
Member Author

mtias commented Jun 8, 2017

This is looking good. One side effect is we are losing the click-on-canvas-to-deselect.

This commit hides the movers on floated images. We can look at reintroducing them for floats and full width images in a separate PR.

It also fixes another responsive issue where the sidebar is stickied.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Blocks Overall functionality of blocks General Interface Parts of the UI which don't fall neatly under other labels. [Priority] High Used to indicate top priority items that need quick attention
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants