CPT: Move PostTypeListPost to standalone block directory

[aduth]

This pull request seeks to move the <PostTypeListPost> component to my-sites/post-type-list/post.jsx to blocks/post-item/index.jsx, renamed as a standalone <PostItem> component. This is part of a series of pull requests aimed at refactoring the custom pots types listing components for more generalized and customizable usage.

Testing instructions:

Verify that there are no regressions in the display and interaction of the custom post types list page post items.

/cc @mtias

Test live: https://calypso.live/?branch=move/cpt-list-post-item

[mtias]

It'd be nice to have a class for this.

[aduth]

It'd be nice to have a class for this.

Refactored in 0483005

[mtias]

Looks good to me.

[mtias]

@aduth can we plan on adding it to the blocks gallery in devdocs?

[aduth]

@mtias : Pushed up a handful of new commits to document and add a DevDocs example for <PostItem />. Turned into a bit of a rabbit hole, and in the process refactored sites state and enhanced the <QuerySites /> component for requesting a single site (necessary for the edit URL in the example to correctly include the site slug). This query component and state isn't used anywhere yet, so it should be low risk.

Looping in @gwwar as the original author of this state and query component (#5066).

[gwwar]

Do we need to be careful about the case where we may need to wait until a siteId is available? We might accidentally trigger an all sites request if we pass through a falsy value before we pass through a siteId.

[aduth]

Do we need to be careful about the case where we may need to wait until a siteId is available? We might accidentally trigger an all sites request if we pass through a falsy value before we pass through a siteId.

Yes, but I think that should be on the developer to ensure that if they're intending to request a single site that they not render the <QuerySites /> component until the site ID is ready. That said, we could/should probably have better documentation about this behavior.

[gwwar]

The sites request is heavy enough that I'd think it be worthwhile to try and avoid this case. I can see this being overlooked in a PR pretty easily.

Have we considered creating a QuerySites and QuerySite component?

[aduth]

Have we considered creating a QuerySites and QuerySite component?

I know it had come up previously in the case of single post vs. all posts for a site, and IIRC there was a desire to keep it to a single flexible component that could accommodate both cases. I see benefits to both angles. Separate components not only avoids this as a mistake, but is also a simpler implementation for the individual components. Another alternative to consider is only doing the "mass" request if explicitly passing a null parameter for siteId or a separate allSites (or similarly named) prop.

[aduth]

Some context: #2350 (comment)

[gwwar]

This shouldn't hold up the PR, but I think splitting it into two keeps it simple and makes it easier to use.

Passing an explicit null parameter works too, but we'd need to communicate the convention. Currently, selectors often return null so this would be easy to accidentally trigger.

[mtias]

To me it's just an attribute difference of the same query — the same way I can say "query only posts for this author" I should be able to say "query all my latest drafts". Mentally I'm querying for the same item (posts) and I don't care how our API is setup, or whether I'm hitting different endpoints. Agreed on guarding against triggering unnecessary fetches, though. Perhaps allSites is a good prop to have.

[gwwar]

Fair enough, and if we ever end up paging the results this makes sense too. I think an extra prop works better than giving extra meaning to null. Usage then looks like:

<QuerySites allSites />
<QuerySites siteId={ siteId } />