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

Update the edit site save modal UI #20608

Merged
merged 4 commits into from Mar 5, 2020
Merged

Conversation

@youknowriad
Copy link
Contributor

youknowriad commented Mar 3, 2020

refs #20421

This PR addresses the first step of #20421 and tries to have more user-friendly labels. It is though very hard to achieve in a generic way and this PR had to also introduce some changes to existing APIs.

Capture d’écran 2020-03-03 à 1 47 34 PM

@@ -153,21 +153,6 @@ _Returns_

- `?Object`: Record.

<a name="getEntityRecordChangesByRecord" href="#getEntityRecordChangesByRecord">#</a> **getEntityRecordChangesByRecord**

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 3, 2020

Author Contributor

This selector was very hard to work with and I checked wpdirectory.net it's not something that is used by plugins and is unlikely to be used before FSE.

{ name: 'site', kind: 'root', baseURL: '/wp/v2/settings' },
{ name: 'postType', kind: 'root', key: 'slug', baseURL: '/wp/v2/types' },
{
label: __( 'Site' ),

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 3, 2020

Author Contributor

I had to introduce this "label" property and also a dependency towards i18n package.

transientEdits: {
blocks: true,
selectionStart: true,
selectionEnd: true,
},
mergedEdits: { meta: true },
getTitle( record ) {

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 3, 2020

Author Contributor

This is supposed to be a generic way to get a "title"/"caption"/"label" of any Entity Record. Notice that it still needs some specific behavior.

@youknowriad youknowriad requested a review from mtias Mar 3, 2020
@github-actions

This comment has been minimized.

Copy link

github-actions bot commented Mar 3, 2020

Size Change: -488 B (0%)

Total Size: 865 kB

Filename Size Change
build/annotations/index.js 3.43 kB +1 B
build/block-editor/index.js 105 kB +10 B (0%)
build/block-editor/style-rtl.css 10.5 kB +37 B (0%)
build/block-editor/style.css 10.5 kB +37 B (0%)
build/block-library/editor-rtl.css 7.36 kB -41 B (0%)
build/block-library/editor.css 7.36 kB -41 B (0%)
build/block-library/index.js 116 kB +61 B (0%)
build/block-library/style-rtl.css 7.5 kB -3 B (0%)
build/block-library/style.css 7.51 kB -3 B (0%)
build/blocks/index.js 57.6 kB -10 B (0%)
build/components/index.js 191 kB +6 B (0%)
build/components/style-rtl.css 15.6 kB -2 B (0%)
build/components/style.css 15.5 kB -1 B
build/core-data/index.js 10.6 kB +151 B (1%)
build/data/index.js 8.22 kB -3 B (0%)
build/edit-post/index.js 90.9 kB +7 B (0%)
build/edit-post/style-rtl.css 8.54 kB +13 B (0%)
build/edit-post/style.css 8.54 kB +12 B (0%)
build/edit-site/index.js 4.64 kB +9 B (0%)
build/edit-widgets/index.js 4.42 kB -2 B (0%)
build/editor/index.js 43.9 kB -732 B (1%)
build/element/index.js 4.45 kB +1 B
build/rich-text/index.js 14.3 kB +5 B (0%)
ℹ️ View Unchanged
Filename Size Change
build/a11y/index.js 1.01 kB 0 B
build/api-fetch/index.js 3.39 kB 0 B
build/autop/index.js 2.58 kB 0 B
build/blob/index.js 620 B 0 B
build/block-directory/index.js 6.02 kB 0 B
build/block-directory/style-rtl.css 760 B 0 B
build/block-directory/style.css 760 B 0 B
build/block-library/theme-rtl.css 669 B 0 B
build/block-library/theme.css 671 B 0 B
build/block-serialization-default-parser/index.js 1.65 kB 0 B
build/block-serialization-spec-parser/index.js 3.1 kB 0 B
build/compose/index.js 5.76 kB 0 B
build/data-controls/index.js 1.03 kB 0 B
build/date/index.js 5.37 kB 0 B
build/deprecated/index.js 772 B 0 B
build/dom-ready/index.js 568 B 0 B
build/dom/index.js 3.06 kB 0 B
build/edit-site/style-rtl.css 2.51 kB 0 B
build/edit-site/style.css 2.51 kB 0 B
build/edit-widgets/style-rtl.css 2.59 kB 0 B
build/edit-widgets/style.css 2.58 kB 0 B
build/editor/editor-styles-rtl.css 325 B 0 B
build/editor/editor-styles.css 327 B 0 B
build/editor/style-rtl.css 3.98 kB 0 B
build/editor/style.css 3.98 kB 0 B
build/escape-html/index.js 733 B 0 B
build/format-library/index.js 7.6 kB 0 B
build/format-library/style-rtl.css 502 B 0 B
build/format-library/style.css 502 B 0 B
build/hooks/index.js 1.92 kB 0 B
build/html-entities/index.js 622 B 0 B
build/i18n/index.js 3.48 kB 0 B
build/is-shallow-equal/index.js 710 B 0 B
build/keyboard-shortcuts/index.js 2.3 kB 0 B
build/keycodes/index.js 1.68 kB 0 B
build/list-reusable-blocks/index.js 2.99 kB 0 B
build/list-reusable-blocks/style-rtl.css 226 B 0 B
build/list-reusable-blocks/style.css 226 B 0 B
build/media-utils/index.js 4.85 kB 0 B
build/notices/index.js 1.57 kB 0 B
build/nux/index.js 3.02 kB 0 B
build/nux/style-rtl.css 616 B 0 B
build/nux/style.css 613 B 0 B
build/plugins/index.js 2.54 kB 0 B
build/primitives/index.js 1.49 kB 0 B
build/priority-queue/index.js 780 B 0 B
build/redux-routine/index.js 2.84 kB 0 B
build/server-side-render/index.js 2.54 kB 0 B
build/shortcode/index.js 1.7 kB 0 B
build/token-list/index.js 1.27 kB 0 B
build/url/index.js 4 kB 0 B
build/viewport/index.js 1.61 kB 0 B
build/warning/index.js 1.14 kB 0 B
build/wordcount/index.js 1.18 kB 0 B

compressed-size-action

).filter( ( pks ) =>
hasEditsForEntityRecord( state, kind, name, pks )
Comment on lines 212 to 213

This comment has been minimized.

Copy link
@epiqueras

epiqueras Mar 3, 2020

Contributor
Suggested change
).filter( ( pks ) =>
hasEditsForEntityRecord( state, kind, name, pks )
).filter( ( primaryKey ) =>
hasEditsForEntityRecord( state, kind, name, primaryKey )
primaryKey
);
dirtyRecords.push( {
// We avoid using primrayKey because it's transformed to a string

This comment has been minimized.

Copy link
@epiqueras

epiqueras Mar 3, 2020

Contributor
Suggested change
// We avoid using primrayKey because it's transformed to a string
// We avoid using primaryKey because it's transformed into a string
dirtyRecords.push( {
// We avoid using primrayKey because it's transformed to a string
// when it's used as an object key.
key: entityRecord[ entity.key || 'id' ],

This comment has been minimized.

Copy link
@epiqueras

epiqueras Mar 3, 2020

Contributor

Let's use the constant for the default entity key here.

);
}
);

entitiesToSave.forEach( ( { key, kind, name } ) => {

This comment has been minimized.

Copy link
@epiqueras

epiqueras Mar 3, 2020

Contributor
Suggested change
entitiesToSave.forEach( ( { key, kind, name } ) => {
entitiesToSave.forEach( ( { kind, name, key } ) => {

It'd be nicer to have all these in this order for consistency.

{ record.entity.label }
{ !! record.title && (
Comment on lines 75 to 76

This comment has been minimized.

Copy link
@epiqueras

epiqueras Mar 3, 2020

Contributor

Why is the title a top-level item, but the label is merged into the entity? I think both should be top-level as the label is not part of the entity as provided by the API.

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 3, 2020

Author Contributor

Ideally, "entity" is removed entirely from this object (it duplicates kind, name) and we should use getEntity selector. Laziness made me add it to the experimental selector.

This comment has been minimized.

Copy link
@epiqueras

epiqueras Mar 3, 2020

Contributor

Yes, let's do that.

import classnames from 'classnames';
import memoize from 'memize';
import EquivalentKeyMap from 'equivalent-key-map';

This comment has been minimized.

Copy link
@epiqueras

epiqueras Mar 3, 2020

Contributor

Maybe we can remove this dep now?

@shaunandrews

This comment has been minimized.

Copy link
Contributor

shaunandrews commented Mar 3, 2020

Could you help me understand what the "Site" item is in this confirmation?

@youknowriad

This comment has been minimized.

Copy link
Contributor Author

youknowriad commented Mar 3, 2020

@shaunandrews That's when a site setting changes (like Site title)

Copy link
Contributor

epiqueras left a comment

New changes look good 👍

@youknowriad youknowriad merged commit 03bcfad into master Mar 5, 2020
3 checks passed
3 checks passed
build
Details
pull-request-automation
Details
Travis CI - Pull Request Build Passed
Details
@youknowriad youknowriad deleted the update/design-publish-flow branch Mar 5, 2020
@github-actions github-actions bot added this to the Gutenberg 7.7 milestone Mar 5, 2020
@mtias

This comment has been minimized.

Copy link
Contributor

mtias commented Mar 7, 2020

That's when a site setting changes (like Site title)

@youknowriad could it be feasible to use the block name that originated the change perhaps (in this case it'd say "Site Title")?

@youknowriad

This comment has been minimized.

Copy link
Contributor Author

youknowriad commented Mar 9, 2020

could it be feasible to use the block name that originated the change perhaps (in this case it'd say "Site Title")?

Two potential issues here: A property can be bound/edited to multiple blocks. We don't have the information anywhere saying "this block modified this property".

I wonder if we can just use "Site Settings" as the entity label in this case.

@mtias

This comment has been minimized.

Copy link
Contributor

mtias commented Mar 9, 2020

What about "Name of Block (Settings)"? I think a block changing a lot of these is going to be the exception rather than the rule, and the block name would be a lot more clear to the user.

@youknowriad

This comment has been minimized.

Copy link
Contributor Author

youknowriad commented Mar 10, 2020

What about "Name of Block (Settings)"?

The main issue here is that this UI is built in a generic way at the moment. It shows any modified entity (including third-party ones). Name of Block (Settings) this doesn't look like something that can be made generic easily. It coul be something like this Entity Property (Entity Name) but this needs two things:

  • A label for each entity property (content, title,...)
  • It will become a bit verbose (say you modify multiple post properties at the same time)

An alternative here would be to rework that UI to be a specific UI. Say in the component that we only save site, templates and posts and have a specific UI for each entity.

@@ -22,5 +22,5 @@
}

.components-base-control + .components-base-control {
margin-bottom: $grid-unit-20;
margin-top: $grid-unit-20;

This comment has been minimized.

Copy link
@jasmussen

jasmussen Mar 11, 2020

Contributor

This caused the following regression:

Screenshot 2020-03-11 at 10 30 55

What effort did it solve to make the margin a top margin rather than a bottom margin? Because I'm looking at fixing this in a separate PR and would like to avoid re-introducing the same issue you solved in making this change.

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 11, 2020

Author Contributor

Well this rule is meant to style consecutive controls right to add space between them. and in general consecutive controls are one under the other (unless some flex positioning in the parent is involved) which means the margin should be top since the selector targets the second element.

This was causing weird margins between the multiple entities in the popover.

This comment has been minimized.

Copy link
@jasmussen

jasmussen Mar 11, 2020

Contributor

Well this rule is meant to style consecutive controls right to add space between them.

I don't think that was the intent of the rule, but if it was, then I agree the margin should be at the top. I'll look for a fix that doesn't style multiple consecutive base controls in this way.

This comment has been minimized.

Copy link
@youknowriad

youknowriad Mar 11, 2020

Author Contributor

I can't think of any other reason why this rule could exist, and also I wonder if it's me that introduce this rule from the first release of BaseControl :P .

This comment has been minimized.

Copy link
@jasmussen

jasmussen Mar 11, 2020

Contributor

In #20782 I removed it, an so far not seeing any issues.

As far as I can tell, the rule was introduced here: https://github.com/WordPress/gutenberg/pull/13181/files#diff-7f4a5101433bca0f9e460c45196b772fR24

From the conversation, it's not immediately clear why that particular rule was necessary. But given additional sidebar polish that is meant to happen soon, I would expect these spacing rules to be revisited regardless.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants
You can’t perform that action at this time.