[wp-trac] [WordPress Trac] #38342: Quick Draft: Leverage REST API endpoints

[WordPress Trac]

#38342: Quick Draft: Leverage REST API endpoints
---------------------------------+-----------------------------------
 Reporter:  adamsilverstein      |       Owner:
     Type:  enhancement          |      Status:  new
 Priority:  normal               |   Milestone:  Future Release
Component:  Administration       |     Version:
 Severity:  normal               |  Resolution:
 Keywords:  has-patch 4.8-early  |     Focuses:  javascript, rest-api
---------------------------------+-----------------------------------

Comment (by joehoyle):

 Just getting stuck into to helping out here, after reviewing these
 patches, I think staying with the direction of @adamsilverstein's latest
 patch is the direction we should continue. @aduth I think the REST API
 custom endpoint is the wrong approach here - this is the antithesis of
 what the REST API is trying to solve. If we _need_ a custom endpoint just
 to build quick drafts, we have much bigger problems.

 We should be moving more to JS / front-end, that's what the whole
 separation of the API is meant for. Back end is for the resource logic and
 storage, front-end becomes the place to do presentational things. When
 switching to the REST API, there's no doubt a new class of problems to
 solve crop up, that are not present in our server-side rendering world. I
 can definitely understand the want to pull render logic back to the
 server, but I think we can do better, on the front end. This opens up much
 more possibilities even in dates alone, it's possible to do dynamic / live
 updating relative dates etc if we have that logic on the client.

 I think we are identifying some great pain points here, but the solution
 is to push forward and solve them on the client, paving the way for other
 parts of the admin to take this approach, and also help others with good
 examples. Going with a custom server controller I think is the opposite of
 that.

 It seems we have a couple of unsolved problems to solve:

 1. Pre-render placeholder counts before communicating with the API
 2. Date formatting, though it actually looks like maybe @adamsilverstein
 did solve this one?

 I think it would be nice to build the template more on the front end, to
 do that it seems primarily we'ed need:

 1. Edit Links on the resources via the API
 2. Translation strings passed via `wp_localize_script`.

 On "Pre-render placeholder counts before communicating with the API", I
 don't actually think we should worry about this. The place holder does not
 need to be accurate. Take Facebook, Slack etc - the placeholder style like
 this is never the right amount, it's just saying "expect some content to
 load in here", so - I think we should remove the count from the backend to
 simplify this.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/38342#comment:43>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform