-
Notifications
You must be signed in to change notification settings - Fork 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
Editor: Update parent terms and pages selectors look and feel #23496
Conversation
<span> | ||
{ translate( 'Top level', { context: 'Terms: New term being created is top level' } ) } | ||
{ translate( 'Top level %(term)s', { |
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.
ℹ️ This context is really long. Are you sure you don't want to use a translator comment instead?
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.
Indeed, please convert context
to a comment
, thanks!
Aside: I'm ok with this change, but for the future: the setting on the Pages list specifically shouldn't be there imho. Pages is a hierarchy with a root: the site front page / home page is the top level. As such, the "Top Level" shouldn't be a setting outside the list, but simply an option INSIDE the hierarchy in the list — that is: "being a children of the Home Page". It's very odd for the top level page to be a setting outside the page hierarchy. The current UI reflects instead the database structure. Categories is instead different because category hierarchies don't have a "root". /cc @drw158 @shaunandrews |
This behaves a little oddly for me. I can set a new parent category, but then my current page ("Testy" in the screenshots) shows up as a new optional top page: I can then click on it and update to make it my current page's top page to itself (in perception, at least): What I would expect is to never see the current page, so that making it a top-level page or not can only be done by toggling "top level" on or off. |
@Copons what are next steps here? |
c777449
to
69b3494
Compare
@gwwar 😨 Why, rebase and address folks' concerns!
@kwight Addressed in 254a776
@shaunandrews Addressed in 69b3494
@shaunandrews Yup, mentioned it in the (rather messy) PR description.
Do you have a suggestion how to update the label? 🤔
@shaunandrews Oh I think I get it now: it's a toggle, so "unchecked" it's incorrect. |
69b3494
to
225e5d1
Compare
225e5d1
to
5822b64
Compare
{ isTopLevel && ( | ||
<span className="term-form-dialog__top-level-description"> | ||
{ translate( 'Disable to select a %(parentTerm)s', { | ||
args: { parentTerm: labels.parent_item }, |
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.
Could you add a comment
with examples of what the variable parentTerm
could be? i.e. examples for "term". Please add it also to the other translatable strings where applicable. Thanks!
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.
Comments added in c1203ec
I'm still seeing the error immediately after disabling the toggle.
Hmmm. There's nothing super easy to do it. You could add another element around the term labels and use
Disabled was going to be my suggestion. Why do you think is feels wrong here?
I see this, too. |
@shaunandrews I'm pretty sure this should have been fixed in 5822b64, and I don't see any errors when disabling (tried this branch on Calypso.live right now). 🤔
That's the normal |
I don't see any errors when toggling the switch, and there's no jank now due to an update somewhere – unless @shaunandrews has serious concerns, I'm a 👍 |
@kwight I'm pretty sure the jank is still there, but you don't notice it because it's at the bottom of the In other words, you only actually see the placeholder flashing if there are less pages than the post selector height (like in your previous example). |
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 no longer see errors!
Fix #8513
Make the parent term selector in the post editor and the parent page selector in the page editor as close as possible by replacing the top level checkbox with a toggle and by updating how its unchecked state is handled.
Parent Term Selector
Notes
Apparently, terms labels are returned by the backend and stored in state; for this reason they are capitalized (e.g. "Choose a Parent Category").
I'm not exactly sure what is the best way to work around this, though.
To be fair, I think that changing how the backend creates those string is a bit overkill (from a dev standpoint), as it would require checking every single place they are used.
Probably it makes more sense to find labels that work better with capitalized words.
Parent Page Selector
Notes
As you may notice by inspecting the changes, I had to pretty much rewrite this component.
The reason is that previously, the
editPost
action was dispatched every time the toggle changed and an item was selected from the tree, which was possible because you couldn't actually uncheck the top level toggle by clicking on the toggle, but only by selecting a parent page.Now, it's possible to uncheck the top level toggle via the toggle itself, without selecting a parent page. Though, if we dispatched
editPost
now, we'd have no actual value for the parent page.The new logic consists in the fact that unchecking the toggle doesn't dispatch
editPost
anymore, but simply make the parent page selector show up.Only checking the toggle or selecting a parent page dispatches
editPost
.Testing instructions
For parent terms:
For parent pages: