-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Switch post-author component to use /wp/v2/users/?who=authors
#6515
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
Conversation
|
@aduth This isn't quite working how I'd expect it to. Mind checking it out locally and giving it a look? |
To clarify, I can confirm the |
core-data/reducer.js
Outdated
| return [ | ||
| ...state, | ||
| ...action.authors, | ||
| ]; |
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 believe this would create duplicate authors if we trigger the request twice (it's not happening at the moment though :)). Maybe we can store them by Id :).
Also, why do we have an authors reducer instead of a users reducer. I believe we should have a users reducer and use the getAuthors selector to filter the data according to the user's object. This way we won't be duplicating data when we introduce the users fetching.
This looks more complex at first sight, but it's the way to go. Just imagine how you'd update the authors list if you create a new author from the JS side for instance? If it's all handled in a generic way in a users reducer, the selector will update its changes without any specific behavior to trigger the request again.
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 believe this would create duplicate authors if we trigger the request twice (it's not happening at the moment though :)). Maybe we can store them by Id :).
Fixed in 97a7a35
Also, why do we have an
authorsreducer instead of ausersreducer. I believe we should have ausersreducer and use thegetAuthorsselector to filter the data according to the user's object.
Because of #6361. With this approach, we keep the definition of "which user is an author" server-side.
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.
Because of #6361. With this approach, we keep the definition of "which user is an author" server-side.
Well! Can I suggest that it's not a good compromise going forward. This means that our data module would consider authors as a separate entity than users. While this may be ok shortterm, I don't think it's good because we have to think of the core-data module as a generic module to handle client data in any WP Admin context. It means another page could create users, which could also be "authors" but since this knowledge is only available server-side, the UI won't update once those users are created.
How can we move this knowledge client-side? what property do we need in the user's object to say that it's an author or not?
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.
While this may be ok shortterm, I don't think it's good because we have to think of the
core-datamodule as a generic module to handle client data in any WP Admin context.
Would you like me to move it to editor data then?
How can we move this knowledge client-side? what property do we need in the
user's object to say that it's an author or not?
We'd need to run a second query client-side for every user collection request. First, a WP_User_Query( [ 'who' => 'authors' ] ) to get all authors, and the second WP_User_Query for the full query. When preparing the results for return, we'd inspect whether the user is a part of the first query and include an author attribute correspondingly.
My preference is to keep this current implementation.
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.
In fact, this current implementation can be progressively enhanced to a better implementation in the future, should one arise.
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.
So we discussed this with @aduth and I believe there's a compromise to find here if we can't move the "author" knowledge to the client.
we can track the ?who=authors response as a set of IDs pointing to the canonical users state.
Also this relates to #6395 helper since ?who=authors can be considered just one query on the user model.
I'm fine using a compromise for now and generalizing this as a query in #6395 or similar.
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.
Can you clarify what changes you'd like me to make to this PR? Or, open a PR against this PR with your suggested changes?
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.
Sure, give me some minutes
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.
Here #6522 It's not tested etc... just to get the idea.
| } ), | ||
| withAPIData( ( props ) => { | ||
| const { postType } = props; | ||
| const { postType, authors } = props; |
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.
Passing the props down is useless, it's done automatically in withAPIData
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've merged my native users query implementation here. I believe it conflicts a bit with #6395 but we can easily refactor once one of the PRs hit master. |
|
@aduth @youknowriad Can we land this, and handle the conflict in the other PR? I'd like to move on with #6361 |
youknowriad
left a comment
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.
LGTM 👍 Thanks for all these REST API improvements @danielbachhuber
Description
Switches the
post-authorcomponent to use/wp/v2/users/?who=authorsand its underling REST API query parameters.See https://core.trac.wordpress.org/ticket/42202
See #3010, #6361
Screenshots
Checklist: