-
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
Site Settings: Update the general tab to use toggles instead of checkboxes #10209
Conversation
Looks good to me. |
I'll expand on that a bit—we're rightful in using toggles in situations where the choice is on/off binary (as it is in all of these cases). Let's just be sure to avoid swapping any 'multiple choice' checkboxes for toggles. Carry on! |
This looks spot on. Nice work! |
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.
Works great! Just left a few comments :)
this.setState( { [ currentTargetName ]: currentTargetValue } ); | ||
}, | ||
|
||
handleToggle( name ) { |
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 wonder if we should move these functions into form-base
, if we're going to have the same functions across a few tabs. Perhaps another PR after this & the discussion tab is merged.
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'd also consider renaming this to getToggleHandler
.
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.
@ryelle I was thinking the same thing! We should definitely do that, but let's do it in another PR after we have both these merged.
@omarjackman I'm fine both ways, but just so you know I've reused the same code that was implemented by @ryelle in #10167. Once we move these into form-base
, we can consider renaming them.
</FormLabel> | ||
</li> | ||
</ul> | ||
<legend>{ translate( 'Holiday Snow' ) }</legend> |
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.
You could also use FormLegend
, which adds the form-legend
class.
</FormLabel> | ||
|
||
<Timezone | ||
valueLink={ this.linkState( 'timezone_string' ) } | ||
selectedZone={ this.linkState( 'timezone_string' ).value } | ||
value={ this.state.timezone_string } |
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.
Is value
used in this component? It looks like only selectedZone
is used. I think even the valueLink
that was here was ignored.
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.
You're right! 👍
disabled={ this.state.fetchingSettings } | ||
onClick={ this.onRecordEvent( 'Clicked Site Visibility Radio Button' ) } /> | ||
<span>{ this.translate( 'Public' ) }</span> | ||
<span>{ translate( 'Public' ) }</span> | ||
<FormSettingExplanation isIndented> |
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.
Should this be indented? @MichaelArestad the grey text under each option
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.
You raise a good question. My vote would be for indentation. I'll let @MichaelArestad chime in as well though.
It made me wonder how we might be able to ensure that radio buttons, checboxes, and small toggles (when left-aligned) might take up the same amount of space so that their respective labels would all share the same left alignment if the various form elements were mixed together in a list. Can we ensure that all three types of inputs fix within 24px and that text labels are always exactly 24px (or whatever it is) from the left justification?
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.
If we strive to be consistent, I'd rather keep it non-indented because of how it is already in the Discussion tab in #10167 - see how the "These settings may be overriden..." text appears, and it's not indented. Anyway, let's also see what @MichaelArestad has to say about it. For now, I leave it indented.
Can we ensure that all three types of inputs fix within 24px and that text labels are always exactly 24px (or whatever it is) from the left justification?
Sure, but I think that for Radio buttons it would create a huge white gap. Mini toggles are 24px wide, and have 21px of space to the right, which totals 45px. Radio buttons (together with white space) are equal to 21px. If we add another 24px to the right, the white gap would be too big IMO.
margin-left: 12px; | ||
} | ||
|
||
p.form-setting-explanation.is-indented { |
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.
Regardless of whether FormSettingExplanation
should be indented, this CSS should be removed. If you do end up needing to remove the indent, remove the isIndented
property from the component.
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.
Also, we probably shouldn't target the p
tag directly
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.
@ryelle of course, I've removed it now.
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 looks awesome @tyxla. I left a few comments to take a look at.
if ( dirtyFields.indexOf( key ) === -1 ) { | ||
newState.dirtyFields = [ ...dirtyFields, key ]; | ||
} | ||
this.setState( newState ); |
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.
Updating state here with no changes will still trigger a render. If the intention isn't specifically to do that then I think we should just return early
const dirtyFields = this.state.dirtyFields || [];
if ( dirtyFields.indexOf( key ) >= 0 ) {
return;
}
this.setState( { dirtyFields: [ ...dirtyFields, key ] } );
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.
Also just noticed that instead of doing const dirtyFields = this.state.dirtyFields || [];
we could just initialize the state with an empty array in getInitialState
and then change this to
const { dirtyFields } = this.state;
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.
|
||
handleToggle( name ) { | ||
return () => { | ||
this.recordEvent.bind( this, `Toggled ${ name }` ); |
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 line doesn't look like its doing anything. Did we just want to call it?
this.recordEvent( `Toggled ${ name }` );
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.setState( { [ currentTargetName ]: currentTargetValue } ); | ||
}, | ||
|
||
handleToggle( name ) { |
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'd also consider renaming this to getToggleHandler
.
margin-left: 12px; | ||
} | ||
|
||
p.form-setting-explanation.is-indented { |
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.
Also, we probably shouldn't target the p
tag directly
flex: 1 0 auto; | ||
} | ||
|
||
.form-toggle__switch + span { |
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.
We should give this span
a class and target it that way if at all possible.
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.
@omarjackman @ryelle @rickybanister @MichaelArestad I've done some updates regarding the comments. This is ready for a new code and design review. |
A lot of the work (+ much more) has been addressed in #9085 which as already been merged. It'll be a pain to merge all of these together, so I'll start a new PR for the toggle changes. |
Description
This PR:
dirtyLinkedState
mixin dependency.<Timezone />
when no value is specified.i18n-calypso.localize
for translated strings.Inspired by @ryelle's awesome work in #10167.
Screenshots
Jetpack Site
WordPress.com site
To test
Also, test on WordPress.com sites (it contains Language and Site Timezone options, as well as a Private option for the Privacy setting):
/cc
@ryelle @oskosk @roccotripaldi @johnHackworth for code review
@rickybanister @MichaelArestad for design review