Site settings: only update clean fields with updated poll data

[gwwar]

Fixes #43 #40 and #42 where unsaved changes to site settings could be wiped out on rerender. This is triggered by SitesList polling periodically via the /me/sites endpoint. Note that this affects all settings, not just the site tagline.

Testing Instructions

1. Navigate to: http://calypso.localhost:3000/settings/
2. Select a site when prompted
3. Update some site settings
4. Wait around 30 seconds for SitesList to update

Expected: Your unsaved changes are still there.

cc @hoverduck @rralian

[mtias]

I don't think we should disable the refreshing of data completely. That means that once I hit the settings page, any changes that may happen externally won't be reflected. It's specially noticeable if you open two tabs with settings and in the second one you change the site title. After the poller kicks in, you'll see that the sidebar in the first site updates the selected site with the new title, however, the from field would still have keep the old one.

I think a better solution would be to have the notion of "dirty" for the fields, and leave alone fields that the user may have changed during a poller cycle update.

[rralian]

I think a better solution would be to have the notion of "dirty" for the fields, and leave alone fields that the user may have changed during a poller cycle update.

Yeah, I agree with this.

[gwwar]

I think a better solution would be to have the notion of "dirty" for the fields, and leave alone fields that the user may have changed during a poller cycle update.

@mtias @rralian added in 7a65179 Let me know if the mixin should live somewhere else, or if you have a better idea for a name.

[rralian]

Should we move the clearing of dirtyFields down to the success case below? If there's some transient internet hiccup and you're in the error case where you just need to resubmit, I think we'd still want the dirtyFields to be retained until the form is successfully submitted. Otherwise your changes would potentially be cleared out while you are in that error state.

[gwwar]

👍 good catch, I'll only clear that out in the success case

[rralian]

This is great. I had one suggestion, and if you agree, I think this is good to 🚢 once that change is made. I wonder if this would be a useful module to open source separately and publish via npm? I wouldn't do so in this PR, but I think we need some sort of strategy around open sourcing smaller modules. I think this is what @retrofox was talking about in our hangout last week.

[gwwar]

I'll also add an omit( this.state, 'dirtyFields' ) so we don't send over an unneeded field.

[rralian]

👍 likewise, good catch

[gwwar]

I wonder if this would be a useful module to open source separately and publish via npm?

It's a pretty good candidate for it. Sounds like we might want to add in some generators to make publishing npm packages easier? Like boilerplate babel config/testing setup.

[gwwar]

Should we move the clearing of dirtyFields down to the success case below?

@rralian Fixed in 83aba4d