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

Editor: Add PostListStoreFactory #708

Merged
merged 8 commits into from
Dec 11, 2015
Merged

Editor: Add PostListStoreFactory #708

merged 8 commits into from
Dec 11, 2015

Conversation

timmyc
Copy link
Contributor

@timmyc timmyc commented Nov 25, 2015

Part of #303 - In order to have multiple components in a given view that need to interact with distinct query options of a post-list-store - the current post-list-store needs to be abstracted into a factory akin to the category-store.

Background
While building the "Parent Page Selector" in the editor - both the parent page selector and the post scheduler were modifying the post-list-store query options, and as such the query results. This lead to some odd behavior between the two, and ultimately was fixed by disabling the post scheduler when editing pages.

By moving to a factory setup, components like the post-list-fetcher can create their own instance of a post-list-store to ensure query options and results are not polluted by other components on the page.

This branch indeed got a bit larger then I typically like, but a large amount of the new lines are in the form of tests. Additionally, reading the diff of post-list-store might be a bit difficult and is probably best read outside of the diff viewer. I did not change any logic within the post-list-store, just restructured it to flow with the factory setup, and ES6-ified it.

To Test
Test coverage for the post-list-store has been added in this branch. The tests can be executed by performing cd client/lib/posts && make.

Additionally, the post-list-store acts as a data provider for the following components. All should be interacted with during testing to ensure no odd behavior is encountered

  • my-sites/drafts/draft-list.jsx Can be tested by using the "Drafts Drawer" in the editor
  • my-sites/menus/item-options/post-list.jsx Test via the menu builder by adding menu options for both a page and a post. Interact with the search box here as well and validate the search filter still operates as expected
  • my-sites/pages/page-list.jsx View a page list for a site. Interact with the filter bar by toggling between Drafts and Trash. Filter pages using search
  • my-sites/post-selector/index.jsx Open a page in the editor, interact with the parent page selector in the sidebar.
  • my-sites/posts/post-list.jsx Open a sites posts list. Interact with the filterbar and search.
  • post-editor/editor-ground-control/index.jsx Inside the post editor, expand the post scheduler. Ensure calendar items are circled as expected for dates where posts have been published.
  • Stats Insights Page - The "Latest Post Summary" on the insights tab of the stats page also uses the post-list-store. Validate that data shows up as expected inside this module

@timmyc timmyc added [Feature] Post/Page Editor The editor for editing posts and pages. [Status] In Progress labels Nov 25, 2015
@timmyc timmyc self-assigned this Nov 25, 2015
@timmyc timmyc added Framework [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. and removed [Status] In Progress labels Nov 25, 2015
@@ -14,11 +14,12 @@ var PostListStore = require( 'lib/posts/post-list-store' ),

var PostListFetcher;

function dispatchQueryActions( query ) {
actions.queryPosts( query );
function dispatchQueryActions( postListStoreId, query ) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Was it a conscious decision to not have postListStoreId be an optional second parameter, falling back to a default store ID as we did with the term actions?

Copy link
Contributor

Choose a reason for hiding this comment

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

Nevermind, I didn't see that this was the fetcher component and that you're specifying a default prop below.

@timmyc
Copy link
Contributor Author

timmyc commented Nov 25, 2015

@aduth thanks for the review. In de35df8 I made changes per your feedback - specifically moved _nextId to a module level variable so it is incremented across all post-list-stores and added a test case around that.

last = require( 'lodash/array/last' ),
max = require( 'lodash/collection/max' );
import debugFactory from 'debug';
const debug = debugFactory( 'calypso:posts-list' );
Copy link
Contributor

Choose a reason for hiding this comment

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

Nitpicking now, but I'd still keep the dependencies blocks for imports only and move this assignment to Module variables, though I'm not sure whether there's any precedent here.

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree. This matches precedent as well: there are 44 instances of import debug or import _debug in the code, and only 6 are immediately followed by the const debug statement.

Because I was curious:

String Count
import debugModule 25
import debugFactory 12
import _debug 4
import Debug 3

@aduth
Copy link
Contributor

aduth commented Dec 7, 2015

Not to throw a wrench in everything, and I think its implications require far more work than what we're working towards here, but we should start to think about how problems like these can be addressed and/or better solved in the global Redux state tree that we're moving towards. Posts will probably end up being one of our most complex state subtrees, as it involves querying, pagination, and hierarchy.

Some very rough and naive ideation of how this tree could look:

{
    posts: {
        byId: {
            100: {
                title: 'Hello World'
            }
        },
        queries: {
            'status=publish': {
                posts: [ 100 ],
                fetching: false,
                page: 1
            },
            'status=publish&search=mypost': {
                posts: null,
                fetching: true
            }
        }
    }
}

With selectors to pull out posts:

function getPosts( state, query ) {
    return state.posts.queries[ query ].posts.map( ( postId ) => {
        return state.posts.byId[ postId ];
    } );
}

We can certainly move forward with the approach in this pull request, but it behooved me to at the very least mention Redux in the context of this conversation.

module.exports = function( id ) {
if ( ! id ) {
throw new Error( 'must supply a post-list-store id' );
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not es6ify this as export default function( id )?

@nylen
Copy link
Contributor

nylen commented Dec 7, 2015

This branch indeed got a bit larger then I typically like, but a large amount of the new lines are in the form of tests.

At first I was like

😩

but then I was like

😎

This works well in my testing, and appears to me to be the shortest path between where we are and getting link search working, which is the # 1 user request for the editor (that we're tracking, at least): pKdGS-XV-p2

Left a few inline notes, which shouldn't block this from being merged. The added tests are nice and give us more confidence both now and in the future when we move this logic to Redux.

@timmyc timmyc force-pushed the add/post-list-factory branch from de35df8 to f7cb813 Compare December 7, 2015 21:14
@timmyc
Copy link
Contributor Author

timmyc commented Dec 7, 2015

Okay rebased the branch to pull in @gwwar's recent addition to the post-list-store of the hasRecentError() method. Added tests for that new method in 054f011, and took care of @nylen's feedback in 5cf488f

@timmyc
Copy link
Contributor Author

timmyc commented Dec 9, 2015

ping @mtias and @aduth are you both okay with this moving ahead as a temporary solution until a redux approach can be adopted?


if ( siteID ) {
debug( 'Fetching posts that have been updated for %s since %s %o', siteID, params.modified_after, params );
wpcom
.site( siteID )
.postsList( params, PostActions.receiveUpdated.bind( null, id ) );
.postsList( params, PostActions.receiveUpdated.bind( null, id, postListStoreId ) );
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this need to pass postListStoreId? I'd think any instance of the PostListStore would be interested in receiving updated posts.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

At first glance I think I would agree with you, but if I'm following the logic correctly, in the store if we allow all posts to be passed down regardless of postListStoreId, we would end up with post.IDs that could possibly not map to the store's active query #

Copy link
Contributor

Choose a reason for hiding this comment

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

if I'm following the logic correctly, in the store if we allow all posts to be passed down regardless of postListStoreId, we would end up with post.IDs that could possibly not map to the store's active query

Yeah, appears so, which is unfortunate, since receiving updated posts should be agnostic to the currently active list. It's not a big concern and more of an ideal, perhaps something we can aim to improve in future iterations.

@aduth
Copy link
Contributor

aduth commented Dec 9, 2015

Outside of my question related to whether we can allow all instances of post stores to receive updated posts, I have no objections with merging this. Tests well for me. 👍

@timmyc
Copy link
Contributor Author

timmyc commented Dec 11, 2015

After discussing this in our team hangout again yesterday I'm going to give this a merge.

timmyc added a commit that referenced this pull request Dec 11, 2015
@timmyc timmyc merged commit 7116d67 into master Dec 11, 2015
@scruffian scruffian removed the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Dec 11, 2015
@mtias mtias deleted the add/post-list-factory branch December 11, 2015 17:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Post/Page Editor The editor for editing posts and pages. Framework
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants