Editor: Manage post title edits using global Redux state

[aduth]

This pull request seeks to implement the logic necessary to start assigning edited post values through Redux state, including displaying the current value, editing the value, saving edited values, and considering edited values in Redux state for "dirty" and "empty content" checking. As of this pull request, only title edits will be managed through global state.

The implementation includes compatibility with the Flux approach, specifically in assigning edited values from Redux state to the Flux store prior to saving. This will be removed in future iterations as the editor becomes completely dependent upon Redux state, especially once we start saving the post through Redux action creators.

Testing instructions:

Verify that titles can be viewed, updated, and saved in the post editor. Verify also that the Save option is shown iff the post has any revisions which differ from the saved post, and only if the post has "content" (non-whitespace-only title, content, or excerpt assigned). Confirm expected behavior for new posts and pages, and existing posts and pages.

[timmyc]

With the new connect approach in EditorTitle it might be nice to get rid of passing the site object in here and perhaps just call isPermalinkEditable here instead and pass that resultant boolean as a prop in its lieu.

[timmyc]

Testing out well for me. I did hit an edge-case bug, which exists in production as well that seems to be triggered by the protect-form mixin removing store from context.

Steps:

1. Open up a new post
2. Add a title
3. Click the new post button before the autosave hits, note the protect form warning is shown, click cancel
4. Autosave kicks in
5. Then click the new post button again and things go sideways:

Worth noting I could not re-create the bug by clicking "Back" in the sidebar.

[aduth]

Thanks @timmyc ! I rebased to resolve merge conflicts and to address your comments:

With this new prop, should we tidy up line 57 that is still using this.props.site.ID

Replaced with this.props.siteId comparison in rebased 7176235.

With the new connect approach in EditorTitle it might be nice to get rid of passing the site object in here and perhaps just call isPermalinkEditable here instead and pass that resultant boolean as a prop in its lieu.

In the rebased 7176235, I've removed the passing of site prop to <EditorTitle /> and replaced it instead with a connect selector to pass site object from getSelectedSite selector instead. This is usually only discouraged when passing around the entire object and not knowing whether any consuming children are using computed properties that don't exist in the Reduxified object, which is not the case here (source).

Since we are grabbing the siteId in the connect statement, should we just pass it in as a prop and utilize here?

It makes sense for the drafts reset, yeah, but for resetting edits to the post object itself on the subsequent lines, I'd feel safer to continue pulling the site ID from the post object. The rebased 59fe3fe changes this line.

I did hit an edge-case bug, which exists in production as well that seems to be triggered by the protect-form mixin removing store from context.

Since this affects production, I'll see to investigating this as a separate pull request, perhaps in parallel to this one.

[timmyc]

Since this affects production, I'll see to investigating this as a separate pull request, perhaps in parallel to this one.

Seems like a good idea. Took another glance and a spin and all is looking well! Excited to see the editor moving in this direction.

[nylen]

I rebased this PR to eliminate conflicts after #6040 and other changes. Works well in my quick testing but needs more 👀 .

[aduth]

@nylen : Given #6548, were you planning to move forward with merging this? Or chip away some of the pieces for the CPT taxonomy use-case, rebasing this one later once we're comfortable that it's working well?

[nylen]

chip away some of the pieces for the CPT taxonomy use-case, rebasing this one later once we're comfortable that it's working well

That was what I had in mind - rebasing seemed like a good way to explore and this code and get it ready for re-use. Still, I don't yet understand some of the code I cribbed from here well enough to be confident merging, and #6548 isn't quite working yet.

[timmyc]

@nylen @aduth I don't think this branch has been looked at much since our meetup in Bend 😢

Since we now have a bit more editor traction in Redux, do either of you want to grab this and run with it - or should I pick it up?

[aduth]

I'm not opposed to someone picking it back up, but personally I'd planned on chipping away at some of the easier migrations to help shake out requirements and bugs before tackling this critical one.

[aduth]

Superseded by #8814