Posts: Remove PostCountsStore Flux store

[aduth]

This pull request seeks to migrate the remaining single component using PostCountsStore Flux store to use Redux post counts state, <PostsNavigation />.

Testing instructions:

Verify that posts navigation continues to behave as it did previously, with and without Redux state persistence (disable by restarting Calypso with DISABLE_FEATURES=persist-redux make run).

Specifically:

• Jetpack sites and all sites posts list do not load counts and always display all statuses
• Post counts update to reflect "Everyone" / "Only Me" selected toggle state
• When shown as select dropdown due to limited space, ensure items reflect correct count
• Statuses are hidden when no counts exist, except Published and Drafts
  • This behaves slightly different than master, specifically that we always show the links for published and drafts even while counts are being loaded (master shows an empty <SectionNav />)

Ensure that no remaining references to post counts Flux store remain. I did note a remaining &meta=counts query parameter in the sync handler test data, but this was not easily removed (assumed hash generated by query parameters).

[aduth]

Already encountering at least one regression with how we were previously optimistically handling changes to posts in the counts store. Trashing a post in this branch does not increment counts accordingly in the navigation bar. We could explore cherry-picking pieces from #4557 for incrementing counts on the trash (publish, etc) actions.

[mtias]

@aduth perhaps it's wise to finish moving to state.posts first.

[aduth]

perhaps it's wise to finish moving to state.posts first.

Even at that point, if we want to preserve the optimistic updating of post counts, we'll still probably want to explicitly dispatch an action to increment the counts from the trash button callback.

More broadly to this point, #4557 has uncovered some difficult complexities in managing post state in response to changes, which we haven't encountered to this point. Specifically around managing reducer relations between different parts of the tree, which is frowned upon / not obviously possible. So it's not as simple as I'd hoped in adding a handler for post change actions to the counts reducer, since we can't know the previous item's state from that reducer.

[mtias]

Wonder if we could keep track of local count modifications separately and use them to modify output of selectors getCount = state.counts + state.counts.local. Whenever a new fetch occurs our "dirty" count gets reconciled.

[aduth]

Wonder if we could keep track of local count modifications separately and use them to modify output of selectors

I'll need to look again, but there are a few more complications, especially around (a) having two-step trashing for posts and (b) knowing the previous status for a post (not just incrementing count for trashed, but also decrementing count for current/previous status).

[aduth]

We should probably plan to revive this pull request in the near future, seeing as currently we're making duplicate redundant requests for post counts on the post listing screen (drafts list <QueryPosts />, filter counts PostCountsStore posts endpoint meta). Looks like the major blocker was transitioning post counts on actions, which we have something of a solution for as of #6040.

[lancewillett]

Closing as older and possibly abandoned. Feel free to re-open if still valid and in-progress.