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

Site Settings: Update the general tab to use toggles instead of checkboxes #10209

Closed
wants to merge 8 commits into from

Conversation

tyxla
Copy link
Member

@tyxla tyxla commented Dec 21, 2016

Description

This PR:

  • Refactors the existing general settings to use toggles instead of checkboxes (see Implement Jetpack Module Settings #9171).
  • Removes the dirtyLinkedState mixin dependency.
  • Fixes a notice in <Timezone /> when no value is specified.
  • Implements i18n-calypso.localize for translated strings.

Inspired by @ryelle's awesome work in #10167.

Screenshots

Jetpack Site

WordPress.com site

To test

  • Get this branch going locally or on calypso.live.
  • Visit the General settings at /settings/general/$site for a Jetpack site.
  • Make any changes.
  • Verify that all changes have been saved and applied to your Jetpack site.

Also, test on WordPress.com sites (it contains Language and Site Timezone options, as well as a Private option for the Privacy setting):

  • Get this branch going locally or on calypso.live.
  • Visit the General settings at /settings/general/$site for a WordPress.com site.
  • Make any changes.
  • Verify that all changes have been saved and applied to your WordPress.com site (you can also check the production settings page).

/cc
@ryelle @oskosk @roccotripaldi @johnHackworth for code review
@rickybanister @MichaelArestad for design review

@tyxla tyxla added [Feature] Site Settings All other general site settings. [Status] Needs Design Review Add this when you'd like to get a review / feedback from the Design team on your PR [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. labels Dec 21, 2016
@tyxla tyxla added this to the Jetpack Module Settings in Calypso milestone Dec 21, 2016
@tyxla tyxla self-assigned this Dec 21, 2016
@matticbot
Copy link
Contributor

@oskosk oskosk mentioned this pull request Dec 21, 2016
55 tasks
@rickybanister
Copy link

Looks good to me.

@rickybanister
Copy link

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!

@MichaelArestad
Copy link
Contributor

This looks spot on. Nice work!

Copy link
Member

@ryelle ryelle left a 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 ) {
Copy link
Member

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.

Copy link
Contributor

@omarjackman omarjackman Dec 22, 2016

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.

Copy link
Member Author

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>
Copy link
Member

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 }
Copy link
Member

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.

Copy link
Member Author

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>
Copy link
Member

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

screen shot 2016-12-21 at 11 30 14 am

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?

Copy link
Member Author

@tyxla tyxla Dec 22, 2016

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 {
Copy link
Member

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.

Copy link
Contributor

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

Copy link
Member Author

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.

Copy link
Contributor

@omarjackman omarjackman left a 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 );
Copy link
Contributor

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 ] } );

Copy link
Contributor

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;

Copy link
Member Author

Choose a reason for hiding this comment

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

You're bringing some good points here. Let's see what @ryelle's opinion about that (as I've borrowed this from her code in #10167), and I can later address them in this PR as well.


handleToggle( name ) {
return () => {
this.recordEvent.bind( this, `Toggled ${ name }` );
Copy link
Contributor

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 }` );

Copy link
Member Author

Choose a reason for hiding this comment

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

Again, this has been borrowed from #10167, but it makes sense. I've removed it from this PR, but @ryelle might want to apply it to #10167 too.

this.setState( { [ currentTargetName ]: currentTargetValue } );
},

handleToggle( name ) {
Copy link
Contributor

@omarjackman omarjackman Dec 22, 2016

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 {
Copy link
Contributor

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 {
Copy link
Contributor

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point, I've added a class and styled it by that class. @ryelle you might want to apply this to #10167 as well.

@tyxla
Copy link
Member Author

tyxla commented Dec 22, 2016

@omarjackman @ryelle @rickybanister @MichaelArestad I've done some updates regarding the comments. This is ready for a new code and design review.

@tyxla
Copy link
Member Author

tyxla commented Dec 22, 2016

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.

@tyxla tyxla closed this Dec 22, 2016
@matticbot matticbot removed the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Dec 22, 2016
@tyxla tyxla deleted the update/site-settings-general-toggles branch December 22, 2016 12:29
@tyxla tyxla removed the [Status] Needs Design Review Add this when you'd like to get a review / feedback from the Design team on your PR label Dec 22, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Site Settings All other general site settings.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants