Move editor mode to redux

[belcherj]

Fix

This PR moves the editor mode state from flux to redux.

Test

1. Open app
2. Click into note with markdown
3. Does the note display in edit mode?
4. Click preview button
5. Does note display in preview mode
6. Click between notes
7. Does preview mode remain enabled
8. Turn off preview mode
9. Does preview mode turn off
10. Turn preview back on
11. Turn off markdown in the info panel for a note
12. Does preview mode turn off?

Review

Only one developer is required to review these changes, but anyone can perform the review.

[belcherj]

@dmsnell @codebykat ready for more review

[belcherj]

@dmsnell @codebykat please rereview

[dmsnell]

No need to do all the work in this PR, but these actions somewhat subvert our normal Redux pattern. All we're doing is passing them to the child component, so how about moving them properly while we're fixing the other aspect of this one Redux state type.

That is, can we eliminate this action from the <NoteToolBar /> container and instead put it in <NoteToolbar /> where it's used?

In that file it looks like we're using state-based logic as well when all we care about doing is toggling. If we wanted, we could further remove the duplicated logic and create a second new action-type and let the reducer centralize and isolate that logic…

// action-types
export type SetEditorMode = Action<'SET_EDITOR_MODE', { mode: T.EditorMode }>;
export type ToggleEditorMode = Action<'TOGGLE_EDITOR_MODE'>;

// reducer
const editorMode: A.Reducer<T.EditorMode> = (state = 'edit', action) => {
   switch (action.type) {
     case 'TOGGLE_EDITOR_MODE':
       return state === 'edit' ? 'markdown' : 'edit';
     case 'SET_EDITOR_MODE':
     case 'App.setEditorMode':
       return action.mode;
     case 'App.newNote':
       return 'edit';
     default:
       return state;
   }
 };

Just mentioning the toggler because it stood out to me in <NoteToolbar /> that we're doing extra logic because we didn't have a semantic way of indicating what we wanted to do and because it's a small change while updating the edit mode logic. It's not essential but might be worth it and a good example of where Redux lets us think more about semantic app interactions than merely being a bag of global setters.

[dmsnell]

It looks like if we handle App.newNote in the editorMode reducer we can eliminate the old method altogether in app-state. For some reason I remember having an issue with that, maybe because newNote is a creator? If that's the case we might find it more appealing in the short-term to stub out a NEW_NOTE or CREATE_NOTE (I like "create" since it seems less ambiguous to receiving a new note from the server) action and trap on that

// action-types
export type CreateNote = Action<'CREATE_NOTE'>;

// editorMode reducer
case 'CREATE_NOTE':
  return 'edit';

Later on that action type could be filled-in with additional necessary properties when we remove it from app-state

[dmsnell]

changing from named states to boolean seems like a semantic regression.

does true or false mean "preview"?

I can follow the idea if we're saying "edit mode" is the mode, though particularly since we talk about edit vs. preview when discussing this I personally find 'edit' and 'preview' clearer in the code

[belcherj]

I reasoned about this for a while. I'd love to chat about it but I came to the opposite conclusion. We are in either editor more or preview. If edit mode is true then we are in preview. Just as is the tag panel open or closed, or are we in focus mode or is the note list open.