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

Made each taxonomy appear on its own panel. #5183

Merged

Conversation

jorgefilipecosta
Copy link
Member

This PR promotes each taxonomy to be a top-level panel (equal to the classic editor).

Closes: #4599

How Has This Been Tested?

Open post editor, verify now we don't have panel named "Categories & Tags" but a panel for categories and another one for tabs. Open and close the panels and verify things work as expected.
Change the categories & tags and check the functionality was not affected.
Add a custom taxonomy e.g: Type of Project, verify the taxonomy is rendered with the correct labels and works as expected.

Screenshots (jpeg or gifs if applicable):

screen shot 2018-02-21 at 18 48 34

@jorgefilipecosta jorgefilipecosta added [Type] Enhancement A suggestion for improvement. [Feature] Document Settings Document settings experience labels Feb 21, 2018
@jorgefilipecosta jorgefilipecosta self-assigned this Feb 21, 2018
@jorgefilipecosta jorgefilipecosta added the [Status] In Progress Tracking issues with work in progress label Feb 22, 2018
@jorgefilipecosta jorgefilipecosta force-pushed the update/made-each-taxonomy-appear-on-its-own-panel branch 2 times, most recently from 34d4832 to adb8217 Compare February 22, 2018 12:59
@jorgefilipecosta jorgefilipecosta removed the [Status] In Progress Tracking issues with work in progress label Feb 22, 2018
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.

Seeing key warning:

react.0406e355.js:336 Warning: Each child in an array or iterator should have a unique "key" prop.

Check the render method of PostTaxonomies. See https://fb.me/react-warning-keys for more information.

function TaxonomyPanel( { taxonomy, isOpened, onTogglePanel, panelName, children } ) {
const taxonomyMenuName = get( taxonomy, [ 'labels', 'menu_name' ] );
if ( ! taxonomyMenuName ) {
return;
Copy link
Member

Choose a reason for hiding this comment

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

A component cannot return undefined from its render. It should return null.

}
return (
<PanelBody
key={ panelName }
Copy link
Member

Choose a reason for hiding this comment

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

I don't think key is effective in this context?

return toggleGeneralSidebarEditorPanel( panelName );
},
},
( stateProps, dispatchProps, ownProps ) => {
Copy link
Member

Choose a reason for hiding this comment

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

See #5090 and #5098 (comment) for more on my distaste for the mergeProps function. Specifically that returning a function here will cause the component to always re-render. Via withDispatch of #5137, we can probably avoid this now.

};
},
{
onTogglePanel( panelName ) {
Copy link
Member

Choose a reason for hiding this comment

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

Minor: This could be simplified to:

{
	onTogglePanel: toggleGeneralSidebarEditorPanel,
},

@@ -171,7 +171,6 @@ class FlatTermSelector extends Component {

return (
<div className="editor-post-taxonomies__flat-terms-selector">
Copy link
Member

Choose a reason for hiding this comment

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

Do we need the wrapper anymore?

I see there's a lingering style for it, but I'm wondering if we need that either:

https://github.com/WordPress/gutenberg/blob/adb821746d9803ae304c57a750b824e08cdcacef/editor/components/post-taxonomies/style.scss#L1-L4

Why doesn't .components-panel__body-title add its own bottom margin rather than rely on children to add this themselves?

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 totally agree with your comment .components-panel__body-title should add its own margin. I wanted to avoid that because it would be a change that affected all the application. But I checked that in inspector controls there was a rule that added this margin. So I removed the rule from there and added it to the component. The changes should be unnoticeable but allowed to remove the wrappers as suggested 👍

);
} );

// Fragment is used because enzyme shallow does not seems to handle correctly components returning just arrays.
Copy link
Member

Choose a reason for hiding this comment

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

Are you sure it's not just that shallow won't traverse into the children ? Have you tried with mount instead?

Copy link
Member Author

@jorgefilipecosta jorgefilipecosta Feb 28, 2018

Choose a reason for hiding this comment

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

Not sure of the reason but all my tries to test the component returning an array failed and I observed that the debug method returned totally invalid data. At the time I found a recent PR on enzyme repository, related to this enzymejs/enzyme#1498, maybe these changes are not yet available in our version.

I also tried to use mount instead, but unfortunately, it was not possible because of errors related with our withAPIData HOC I think we would need to mock it to use mount here, which was something unnecessary for testing purposes of this component.

Copy link
Member

Choose a reason for hiding this comment

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

It's very unintuitive, but this seemed to work okay for me:

diff --git a/editor/components/post-taxonomies/index.js b/editor/components/post-taxonomies/index.js
index d7f28db94..200d61f06 100644
--- a/editor/components/post-taxonomies/index.js
+++ b/editor/components/post-taxonomies/index.js
@@ -8,7 +8,7 @@ import { filter, identity, includes } from 'lodash';
  * WordPress dependencies
  */
 import { withAPIData } from '@wordpress/components';
-import { compose, Fragment } from '@wordpress/element';
+import { compose } from '@wordpress/element';
 
 /**
  * Internal dependencies
@@ -20,7 +20,8 @@ import { getCurrentPostType } from '../../store/selectors';
 
 export function PostTaxonomies( { postType, taxonomies, taxonomyWrapper = identity } ) {
 	const availableTaxonomies = filter( taxonomies.data, ( taxonomy ) => includes( taxonomy.types, postType ) );
-	const taxonomyComponents = availableTaxonomies.map( ( taxonomy ) => {
+
+	return availableTaxonomies.map( ( taxonomy ) => {
 		const TaxonomyComponent = taxonomy.hierarchical ? HierarchicalTermSelector : FlatTermSelector;
 		return taxonomyWrapper(
 			<TaxonomyComponent
@@ -31,14 +32,6 @@ export function PostTaxonomies( { postType, taxonomies, taxonomyWrapper = identi
 			taxonomy
 		);
 	} );
-
-	// Fragment is used because enzyme shallow does not seems to handle correctly components returning just arrays.
-	// Using debug method it was possible to verify shallow always output <undefined /> when arrays are used.
-	return (
-		<Fragment>
-			{ taxonomyComponents }
-		</Fragment>
-	);
 }
 
 const applyConnect = connect(
diff --git a/editor/components/post-taxonomies/test/index.js b/editor/components/post-taxonomies/test/index.js
index 42cfed70f..1f21845a1 100644
--- a/editor/components/post-taxonomies/test/index.js
+++ b/editor/components/post-taxonomies/test/index.js
@@ -16,7 +16,7 @@ describe( 'PostTaxonomies', () => {
 			<PostTaxonomies postType="page" taxonomies={ taxonomies } />
 		);
 
-		expect( wrapper.children() ).toHaveLength( 0 );
+		expect( wrapper.at( 0 ) ).toHaveLength( 0 );
 	} );
 
 	it( 'should render taxonomy components for taxonomies assigned to post type', () => {
@@ -43,8 +43,8 @@ describe( 'PostTaxonomies', () => {
 			<PostTaxonomies postType="page" taxonomies={ taxonomies } />
 		);
 
-		expect( wrapper.children() ).toHaveLength( 1 );
-		expect( wrapper.childAt( 0 ).props() ).toEqual( {
+		expect( wrapper.at( 0 ) ).toHaveLength( 1 );
+		expect( wrapper.at( 0 ).at( 0 ).props() ).toEqual( {
 			slug: 'category',
 			restBase: 'categories',
 		} );

enzymejs/enzyme#1149 is the (open) parent issue for array-returning components in Enzyme.

@jorgefilipecosta jorgefilipecosta force-pushed the update/made-each-taxonomy-appear-on-its-own-panel branch 3 times, most recently from ecb5243 to db17ed3 Compare February 28, 2018 16:27
withDispatch( ( dispatch, ownProps ) => ( {
onTogglePanel: () => {
if ( ownProps.panelName ) {
return dispatch( 'core/edit-post' ).
Copy link
Member

Choose a reason for hiding this comment

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

This doesn't need to return a value.

onTogglePanel: () => {
if ( ownProps.panelName ) {
return dispatch( 'core/edit-post' ).
toggleGeneralSidebarEditorPanel( ownProps.panelName );
Copy link
Member

Choose a reason for hiding this comment

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

Minor: If we're concerned about line length, we could invert the condition to an early return to avoid the tab.

if ( ! ownProps.panelName ) {
	return;
}

dispatch( 'core/edit-post' ).toggleGeneralSidebarEditorPanel( ownProps.panelName );

} ),
withDispatch( ( dispatch, ownProps ) => ( {
onTogglePanel: () => {
if ( ownProps.panelName ) {
Copy link
Member

Choose a reason for hiding this comment

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

Under what real-world conditions will panelName be falsey? And in those cases, is it acceptable that toggling the panel then does nothing?

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 expected when loading, but on a second thought when loading the array is empty and we don't render taxonomy-panel at all, so this logic was not needed.

);
} );

// Fragment is used because enzyme shallow does not seems to handle correctly components returning just arrays.
Copy link
Member

Choose a reason for hiding this comment

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

It's very unintuitive, but this seemed to work okay for me:

diff --git a/editor/components/post-taxonomies/index.js b/editor/components/post-taxonomies/index.js
index d7f28db94..200d61f06 100644
--- a/editor/components/post-taxonomies/index.js
+++ b/editor/components/post-taxonomies/index.js
@@ -8,7 +8,7 @@ import { filter, identity, includes } from 'lodash';
  * WordPress dependencies
  */
 import { withAPIData } from '@wordpress/components';
-import { compose, Fragment } from '@wordpress/element';
+import { compose } from '@wordpress/element';
 
 /**
  * Internal dependencies
@@ -20,7 +20,8 @@ import { getCurrentPostType } from '../../store/selectors';
 
 export function PostTaxonomies( { postType, taxonomies, taxonomyWrapper = identity } ) {
 	const availableTaxonomies = filter( taxonomies.data, ( taxonomy ) => includes( taxonomy.types, postType ) );
-	const taxonomyComponents = availableTaxonomies.map( ( taxonomy ) => {
+
+	return availableTaxonomies.map( ( taxonomy ) => {
 		const TaxonomyComponent = taxonomy.hierarchical ? HierarchicalTermSelector : FlatTermSelector;
 		return taxonomyWrapper(
 			<TaxonomyComponent
@@ -31,14 +32,6 @@ export function PostTaxonomies( { postType, taxonomies, taxonomyWrapper = identi
 			taxonomy
 		);
 	} );
-
-	// Fragment is used because enzyme shallow does not seems to handle correctly components returning just arrays.
-	// Using debug method it was possible to verify shallow always output <undefined /> when arrays are used.
-	return (
-		<Fragment>
-			{ taxonomyComponents }
-		</Fragment>
-	);
 }
 
 const applyConnect = connect(
diff --git a/editor/components/post-taxonomies/test/index.js b/editor/components/post-taxonomies/test/index.js
index 42cfed70f..1f21845a1 100644
--- a/editor/components/post-taxonomies/test/index.js
+++ b/editor/components/post-taxonomies/test/index.js
@@ -16,7 +16,7 @@ describe( 'PostTaxonomies', () => {
 			<PostTaxonomies postType="page" taxonomies={ taxonomies } />
 		);
 
-		expect( wrapper.children() ).toHaveLength( 0 );
+		expect( wrapper.at( 0 ) ).toHaveLength( 0 );
 	} );
 
 	it( 'should render taxonomy components for taxonomies assigned to post type', () => {
@@ -43,8 +43,8 @@ describe( 'PostTaxonomies', () => {
 			<PostTaxonomies postType="page" taxonomies={ taxonomies } />
 		);
 
-		expect( wrapper.children() ).toHaveLength( 1 );
-		expect( wrapper.childAt( 0 ).props() ).toEqual( {
+		expect( wrapper.at( 0 ) ).toHaveLength( 1 );
+		expect( wrapper.at( 0 ).at( 0 ).props() ).toEqual( {
 			slug: 'category',
 			restBase: 'categories',
 		} );

enzymejs/enzyme#1149 is the (open) parent issue for array-returning components in Enzyme.

@jorgefilipecosta jorgefilipecosta force-pushed the update/made-each-taxonomy-appear-on-its-own-panel branch 3 times, most recently from 436b007 to 8e8e91d Compare March 1, 2018 11:05
@jorgefilipecosta
Copy link
Member Author

Hi @aduth thank you for providing a possible approach to handle enzyme array limitation 👍, all the feedback was applied.

@aduth
Copy link
Member

aduth commented Mar 1, 2018

I'd like for this to make it into the 2.3 release, but am also wary about the small design change here in that there's marginally more margin added to the bottom of sidebar panel titles. The removed styles applied only to block inspector panels, not those in the document inspector

Before (Focused) After (Focused)
Before Focused After Focused
Before (Unfocused) After (Unfocused)
Before Unfocused After Unfocused

cc @jasmussen

@aduth aduth added the Needs Design Feedback Needs general design feedback. label Mar 1, 2018
const TaxonomyComponent = taxonomy.hierarchical ? HierarchicalTermSelector : FlatTermSelector;
return taxonomyWrapper(
<TaxonomyComponent
key={ taxonomy.slug }
Copy link
Member

Choose a reason for hiding this comment

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

I think there's some redundancy in key application. Technically this prop is not needed (nor used), but I do think it should be the responsibility of this component, not the callback for taxonomyWrapper, to apply the key. This could be done in one of two ways:

  • Add a wrapper element to the return value of this map callback with the key
  • Use cloneElement to assign key as a prop into the return value of taxonomyWrapper

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, it makes sense to define the key here, I used a wrapper as it looks like the simplest approach.

...this.renderTerms( availableTermsTree ),
! loading && (
<button
key="term-add-btn"
Copy link
Member

Choose a reason for hiding this comment

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

Minor: Abbreviating seems to serve only to introduce some ambiguity here.

Copy link
Member Author

Choose a reason for hiding this comment

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

The abbreviation was removed.

required
/>
{ !! availableTerms.length &&
<TreeSelect
Copy link
Member

Choose a reason for hiding this comment

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

Should be indented one more (how it was previously)

Copy link
Member Author

Choose a reason for hiding this comment

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

Corrected.

@jasmussen
Copy link
Contributor

I'd like for this to make it into the 2.3 release, but am also wary about the small design change here in that there's marginally more margin added to the bottom of sidebar panel titles. The removed styles applied only to block inspector panels, not those in the document inspector

Took a look. Here's the whole panel:

screen shot 2018-03-01 at 18 22 38

Here's the extra margin the change makes:

screen shot 2018-03-01 at 18 23 59

I think this is fine. 👍 👍 for the change and shipping, we can always revisit later.


Now that you made me look, however, and this is unrelated to this PR, I did notice that there's too much padding in the Status and Comments panels:

screen shot 2018-03-01 at 18 24 04

screen shot 2018-03-01 at 18 25 45

This seems to be from the .components-panel__row top-margin not collapsing:

screen shot 2018-03-01 at 18 24 17

We can either convert that margin to a bottom margin instead, or do something like this:

.components-panel__row:first-of-type {
    margin-top: 0;
}

That would address it:

screen shot 2018-03-01 at 18 28 31

screen shot 2018-03-01 at 18 28 34

But this can be done separately.

@jorgefilipecosta jorgefilipecosta force-pushed the update/made-each-taxonomy-appear-on-its-own-panel branch from 8e8e91d to 7b357ab Compare March 2, 2018 11:43
@jorgefilipecosta
Copy link
Member Author

jorgefilipecosta commented Mar 2, 2018

Hi @aduth and @jasmussen thank you for your feedback. I end up adding the CSS rule referred by @jasmussen, I think it improves the design compared to what we had, thank you @jasmussen 👍 I think the rule may be fragile e.g: if panel title was a div it would not work, but right now it seems like our best bet and it solves the problem. Maybe the panel body should have title and content in separate dom containers and the :first-child selector could be used for rows, it is something to check and discuss after, but from the design point of view as things are right now the result would be the same.

The design now looks like this:
image

@jorgefilipecosta
Copy link
Member Author

jorgefilipecosta commented Mar 2, 2018

Test cases were updated, the addition of the wrapper to allow keys to be set in the right place made the props test case even less intuitive, that test case was removed and another test case that tests the rendering of multiple taxonomies was added. I think this made tests cases simpler to understand and still relevant.

@jorgefilipecosta
Copy link
Member Author

Hi @karmatosed, can you please have a final look regarding the user experience perspective?

@aduth aduth added this to the 2.3 milestone Mar 2, 2018
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.

Code-wise, looks good 👍

@@ -134,6 +134,10 @@
&:empty {
margin-top: 0;
}

&:first-of-type {
margin-top: 0px;
Copy link
Member

Choose a reason for hiding this comment

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

Minor: 0 doesn't need a unit. Further, this could be merged into the selector above:

&:empty,
&:first-of-type {
	margin-top: 0;
}

@jorgefilipecosta jorgefilipecosta force-pushed the update/made-each-taxonomy-appear-on-its-own-panel branch from 495fb69 to 53d2dd9 Compare March 2, 2018 17:33
Before all taxonomies appeared under "Categories & Tags" panel.
Copy link
Member

@karmatosed karmatosed left a 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, thanks for iterating on this.

@jorgefilipecosta jorgefilipecosta force-pushed the update/made-each-taxonomy-appear-on-its-own-panel branch from 53d2dd9 to 3e86770 Compare March 2, 2018 17:35
@jorgefilipecosta jorgefilipecosta merged commit e505e02 into master Mar 2, 2018
@jorgefilipecosta jorgefilipecosta deleted the update/made-each-taxonomy-appear-on-its-own-panel branch March 2, 2018 17:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Document Settings Document settings experience Needs Design Feedback Needs general design feedback. [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Title of panel Categories & Tags is wrong when only one taxonomy is used
4 participants