[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:  4.7
Component:  Administration        |     Version:
 Severity:  normal                |  Resolution:
 Keywords:  needs-patch REST-API  |     Focuses:  javascript
----------------------------------+-------------------------

Comment (by joehoyle):

 I think this is looking great - on the questions, this is broadly my
 opinion, however I'll also ask someone else from the REST API team to
 weigh in.

 > Bootstrapping data helps in displaying recent drafts more quickly, but
 there's still a delay for as long as it takes for the dashboard script to
 load. I added some placeholder elements to give the illusion of incoming
 content and reduce the jarring effect of items suddenly appearing.

 I think the effect is very cool, and I don't really see this as much of a
 limitation. Right now, it's true that it makes a while to get your admin
 scripts bootstrapped because the admin loads, well, a lot of stuff, and by
 doing it this way we are basically accepting it's going to load last, but
 I think that's ok.

 > It's still not clear how we'd access certain data from JavaScript.
 Content such as: formatted dates, links where filters are run server-side
 (e.g. edit link), truncated content, etc. Script localization, porting
 functions to JavaScript, and newer browser features like
 Intl.DateTimeFormat (with appropriate fallbacks) can help achieve these.
 Other content might require filters on the API endpoints return values
 themselves.

 So, broadly speaking I think we should be looking at shifting a lot of
 this stuff to the front-end. This like truncated content / excerpts,
 localized dates etc. In a REST API driven world, content transformation
 etc is expected to live much more on the client that on the backend. So,
 yes - I think we should be looking at solving things like date formatting
 via JavaScript that can then be used in the admin anywhere.

 > Quick Draft already requires JavaScript anyways, but it's worth
 consideration for if and how content should be rendered "isomorphically"
 (i.e. complete markup sent from the server, but thereafter controlled in
 the browser). This could help remedy the need for placeholders as the
 script loads, but the state of tooling is such that the logic would need
 to be duplicated to implement (rendering in PHP/Backbone, querying from
 REST API/WP_Query).

 I'm not sure what the "official" stance on JS compatibility is. Does /
 should the wp-admin function without JavaScript? I don't think it does
 very well right now (e.g. how do I insert an image into a post) so I think
 we may be ok to say that we can require the use of JS for a feature. Given
 that, and the nature of the WP Admin application, I don't see isomorphic
 rendering as that important. I was even a little surprised to see this
 patch does a `rest_do_request` for the post list, rather than on-load. It
 makes sense as long as the Quick Draft is always shown, if I hide it in
 screen options for example, then really we shouldn't be preloading that
 data (sorry if that case is actually handled), in which case those logic
 checks, like "is this box actually shown, or is it hidden with css" is
 much easier to answer from the javascript context, and we can be much
 smarter about when to load data.


 @adamsilverstein:

 > How do we support filters in existing callbacks (for backwards
 compatibility) or if we want to add them PHP side for a future feature?
 Could we start leveraging JavaScript filters?

 If this is for backwards compat, I don't see a case for the JS filters -
 the PHP filters side of things is a little more tricky. For example, as we
 replace admin-ajax stuff, those used to be filterable in a different way.
 Given these filters can be quite esoteric I'm not sure that we need to
 support admin-ajax filters. However, I'm sure there are situations where
 we _will_ need to support PHP filters, (like `prepare_attachment_for_js`
 for example) and in those cases we'll have to do the usual "try and work
 out the most elegant hack to fire them with the same things as before"
 type thing that happens whenever we re-build a feature in WordPress.
 That's not always an easy thing to do, and I don't see a great fix-all
 solution there, given how different every filter can be.

 > What is the best way to add data that is not part of the standard
 responses?

 This _can_ be done with adding meta, register_rest_field etc, however I
 think this should be looked at on a case-by-case basis. If there is data
 that we are outright missing from the API, let's try to get that into the
 API. If on the other hand, it's something presentation, that _did_
 previously live at the PHP-send-it-over-the-wire-with-the-data level, we
 should take a fresh look at how to go about achieving the same result from
 a JavaScript / Front end centric point of view. I appreciate the REST API
 is a lot more "pure" it it's approach, and that can be frustrating coming
 from a PHP/WP world where we just put any data we need _anywhere_ to get
 the job done. I don't want to discard that pragmatism, but I think we
 should be striving to keep things "RESTful".

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