-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Conversation
@@ -14,11 +14,12 @@ var PostListStore = require( 'lib/posts/post-list-store' ), | |||
|
|||
var PostListFetcher; | |||
|
|||
function dispatchQueryActions( query ) { | |||
actions.queryPosts( query ); | |||
function dispatchQueryActions( postListStoreId, query ) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
@aduth thanks for the review. In de35df8 I made changes per your feedback - specifically moved |
last = require( 'lodash/array/last' ), | ||
max = require( 'lodash/collection/max' ); | ||
import debugFactory from 'debug'; | ||
const debug = debugFactory( 'calypso:posts-list' ); |
There was a problem hiding this comment.
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 import
s only and move this assignment to Module variables
, though I'm not sure whether there's any precedent here.
There was a problem hiding this comment.
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 |
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' ); | ||
} |
There was a problem hiding this comment.
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 )
?
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. |
de35df8
to
f7cb813
Compare
|
||
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 ) ); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 #
There was a problem hiding this comment.
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.
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. 👍 |
After discussing this in our team hangout again yesterday I'm going to give this a merge. |
Editor: Add PostListStoreFactory
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 currentpost-list-store
needs to be abstracted into a factory akin to thecategory-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 apost-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 thepost-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 performingcd 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 encounteredmy-sites/drafts/draft-list.jsx
Can be tested by using the "Drafts Drawer" in the editormy-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 expectedmy-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 searchmy-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.post-list-store
. Validate that data shows up as expected inside this module