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

[WordPress Trac]

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

Comment (by pento):

 Reviewing [attachment:38342.15.diff]:

 * In `wp_dashboard_print_recent_drafts_template()`, the edit URL is still
 hard coded. This is a blocker, we cannot be setting the example of
 hardcoding URLs that previously could be filtered.
 * The `@deprecated` comment should use the full version, `4.7.0`.
 * Is `rest-api.php` the best place for a filter that only needs to be run
 on the Dashboard home?
 * None of the `QuickPress` functions have JS docs. Let's set a good
 example. :-)
 * Having the timezone offset (and the current user ID, for that matter)
 come from the Quick Draft settings is not very extendable. This is
 information that should be available to all features as they're ported,
 rather than each one needing to reimplement it.

 Replying to [comment:58 aduth]:
 >   I'm not wild about the date formatting code.
 >
 > With good utilities, I could see this logic living in the template. The
 bulk of the current logic is converting to the site time on the client.
 What do you envision being the arguments and return value of the utility
 method you mentioned? I'm not familiar with what's involved in adding a
 library like Moment.js, but given the quirks and variations in parsing and
 formatting dates, I couldn't recommend it enough.

 A good start would be a function that does exactly what the current
 formatting code is doing - take a date (ISO8601, `Date` object or unix
 timestamp), and return it with the site's current date formatting
 settings.

 >   Generally speaking, the JavaScript feel overly verbose
 >
 > Are there specific parts that could be simplified?

 As @joehoyle mentioned elsewhere, this was a bit a rabbit hole to poke at,
 without really going into detail. Let me try and expand a bit. :-)

 I'm looking at this patch with the firm point of view of "how does this
 look as a pattern for existing Dashboard features to be ported to the REST
 API in the future?". With that in mind, I keep running into problems. For
 such a small feature, we've had to make quite a few architectural
 compromises - some of these have been fixed, some of them seem to be
 genuine sticking points, or symptoms of larger problems. I'm not wild
 about the idea of continually running into these same problems every time
 we try to port a feature across.

 When I read the `QuickPress` code, it's not dissimilar in structure to the
 media grid, with which we've significant problems maintaining over the
 years. Is that a problem with all Backbone-based code? Would we face
 similar problems if we were to use other libraries?

 The decision to use Backbone seems to be based on the fact that we always
 use Backbone. Given that we're talking about the future of WordPress
 Dashboard development, I really would like to see some exploration of
 other technologies. React has gone really well for Automattic with
 Calypso. Vue.js seems to be gaining a lot of traction with folks who find
 React to be overkill. There hasn't been much discussion on what the best
 direction here might be.

 At the end of the day, I don't think that keeping it as Backbone is a
 blocker. But the original point of this ticket was to both test for
 shortcoming in the endpoints, which it has done successfully; and spark
 investigation into what the future of WordPress Dashboard development will
 look like, which it hasn't.

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