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

Move preferences to redux #5401

Merged
merged 29 commits into from
Jun 9, 2016
Merged

Move preferences to redux #5401

merged 29 commits into from
Jun 9, 2016

Conversation

artpi
Copy link
Contributor

@artpi artpi commented May 16, 2016

Moves Preferences data to redux, as listed in #5046

  • Introduces preferences redux tree
  • Introduces QueryPreferences component
  • Uses this in post-editor

Nice and shiny readme

Motivation

  • We need it for offline - its in the editor
  • I want to create calypso-labs to let users enable experimental features and need a place to store data

Testing

Only preference moved is editor mode, so:

  • while editing, change editor mode to html
  • close window
  • clear localstorage
  • open new window, go to post editing and see if the mode is html

CC @rralian @gwwar @mtias @aduth @retrofox

@artpi artpi self-assigned this May 16, 2016
@artpi artpi added the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label May 17, 2016
this.recordedDefaultEditorMode = true;
}
const editorMode = this.props.editorModePreference || 'tinymce';
if ( ! this.recordedDefaultEditorMode ) {
Copy link
Contributor

Choose a reason for hiding this comment

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

This is not quite the same effect as existed previously, as before we had guarded against recording the default mode until after preferences have loaded. With this refactor, we can't guarantee that the recorded mode is in-fact the user preference, as it may simply be the fallback value while preferences are loading.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks! That logic was very well hidden! I rewrite it a bit to behave in the same way and maybe a bit clearer.

@artpi artpi removed the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label May 17, 2016
case PREFERENCES_RECEIVE:
return false;
case PREFERENCES_FETCH:
return true;
Copy link
Contributor

@gwwar gwwar May 17, 2016

Choose a reason for hiding this comment

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

Don't forget to not persist this

case SERIALIZE:
case DESERIALIZE:
    return false;

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done!

@aduth
Copy link
Contributor

aduth commented May 19, 2016

We should also be sure to remove the <PreferencesData /> rendering from post-editor/controller.js and switch the <PostEditor /> preferences propType with editorModePreference.

@artpi
Copy link
Contributor Author

artpi commented May 20, 2016

@aduth @gwwar thanks for taking the time! I implemented your suggestions and now I will write proper tests.

We should also be sure to remove the...

done.

@artpi
Copy link
Contributor Author

artpi commented May 20, 2016

Also, I think I will move this in following direction:

  • Instead of having generic key/value store for options, I will introduce dedicated reducer for each one. That way, the shape will be more clear. Also will solve schema problems for serialization.
  • Move bumpstat in loading default editor mode to analytics middleware, thus cleaning up post editor/
  • Also: tests.

@artpi artpi force-pushed the new/redux-preferences branch 2 times, most recently from 5b5e5dd to 4d297b0 Compare June 8, 2016 12:09
} );

it( 'should use DEFAULT_PREFERENCES from constants as a default', () => {
expect( reducer( undefined, {} ).values ).to.deep.equal( DEFAULT_PREFERENCES );
Copy link
Contributor

Choose a reason for hiding this comment

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

.eql is deep equal, and .equal checks for reference equality

@gwwar
Copy link
Contributor

gwwar commented Jun 8, 2016

👍 I took this out for a spin and it works well. Ping me when you add a schema in and I can retest persistence. We should be able to :shipit: after that makes it in.

@aduth
Copy link
Contributor

aduth commented Jun 8, 2016

Not sure if we have a particular timeline for this, but I'd really like to start investigating some improvements to how we accept preferences in our REST API generally, especially in mind of some of the hacks we've needed to incorporate (including entire preferences payload in update) and to address 2FA authorization stale issues (#202).

I guess this may not be a blocker for the pull request, since as long as the action creator and selectors signatures continue to match our intended direction (single preference updating and retrieval) it won't be difficult to change the underlying request/storage behavior.

Ref: 600-gh-io

@gwwar
Copy link
Contributor

gwwar commented Jun 8, 2016

especially in mind of some of the hacks we've needed to incorporate (including entire preferences payload in update)

These issues are out of scope for this PR but +1 for fixing these in follow up PRs. Do we have issues open for some of the API improvements?


const values = combineReducers( mapValues( DEFAULT_PREFERENCES,
( value, key ) => createReducerForPreferenceKey( key, value )
) );
Copy link
Member

Choose a reason for hiding this comment

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

Very interesting usage :D

@aduth
Copy link
Contributor

aduth commented Jun 9, 2016

So I'd taken for granted our discussion about the need for getState being based on the need to pass the entire settings payload when updating a single value. But I investigated this more and this is not true. You can pass a single key-value pair object and the other preference keys will not be affected. With this in mind, I think we should revise our setPreference action creator to avoid getState.

Past discussion:

@artpi
Copy link
Contributor Author

artpi commented Jun 9, 2016

@aduth : thanks for investigating!

With this in mind, I think we should revise

Done.

@gwwar
Copy link
Contributor

gwwar commented Jun 9, 2016

👍 Looks good to me. Don't forget to squash. 😄

@gwwar gwwar added [Status] Ready to Merge and removed [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. labels Jun 9, 2016
@artpi artpi merged commit a091318 into master Jun 9, 2016
@aduth
Copy link
Contributor

aduth commented Jun 9, 2016

Hmm, testing this live, it doesn't seem that the change in preference takes effect when switching editor tabs after the first refresh. It takes a second refresh in order to stick.

@@ -884,7 +886,9 @@ export default connect(
receivePost,
editPost,
resetPostEdits,
setEditorPostId
setEditorPostId,
setPreference,
Copy link
Contributor

Choose a reason for hiding this comment

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

Not using setPreference prop?

@mtias
Copy link
Member

mtias commented Jun 10, 2016

@artpi reloading a page seems to get rid of my recently selected sites.

@artpi
Copy link
Contributor Author

artpi commented Jun 10, 2016

reloading a page seems to get rid of my recently selected sites.

That seems unrelated, I did not touch recentSites, I only introduced a framework.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants