[wp-trac] [WordPress Trac] #40748: Use REST API for Community Events

WordPress Trac noreply at wordpress.org
Fri May 12 19:28:08 UTC 2017


#40748: Use REST API for Community Events
-------------------------------------------------+-------------------------
 Reporter:  iandunn                              |       Owner:
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
Component:  REST API                             |  Review
 Severity:  normal                               |     Version:  trunk
 Keywords:  has-patch dev-feedback needs-unit-   |  Resolution:
  tests                                          |     Focuses:  javascript
-------------------------------------------------+-------------------------
Changes (by iandunn):

 * keywords:   => has-patch dev-feedback needs-unit-tests


Comment:

 [attachment:40748.diff] is an iteration on
 [https://core.trac.wordpress.org/attachment/ticket/40702/40702.11.diff
 40702.11.diff] from #40702, props @flixos90, @adamsilverstein, @azaozz,
 @swissspidy. (It'd be nice to give @georgestephanis and @ocean90 props on
 this as well, since they should have gotten it for #40702 but accidentally
 didn't.)

 Changes made:
 - refresh after r40651
 - call `renderEventsTemplate` in `modelMe.always`, so the logic is more
 straight-forward and less scattered throughout the various event
 callbacks.
 - fixed bug when searching for location that isn't found (e.g., `narnia`).
 `response.code` doesn't exist, need to use `response.responseJSON.code`
 - remove unneeded property checks in `tmpl-community-events-event-list`
 because they should always exist
 - related to removing those unneeded checks, I fixed a bug where date/time
 data didn't show up when displaying cached events. An alternative approach
 would be to call `WP_REST_Community_Events_Events_Controller()` in
 `wp_get_community_events_script_data()`. I don't have a strong opinion
 about which is better.
 - load the dashboard schema after `app.init` has been called, but before
 `getEvents` is called. This way, we don't have to wait on the schema to
 load when we have cached data, but we can start loading the schema
 immediately on `init`, instead of waiting until `getEvents` gets called.
 This is really only helpful for situations where there is cached data, but
 then the user decides to manually change locations. In those situations,
 though, it could potentially mean they only have to wait on 1 HTTP
 request, instead of 2.
 - removed duplicate `requestParams`, `initiatedBy`, `spinner` statements
 inside `dashboardLoadPromise.done`
 - removed `rest_url` and `nonce_url` from
 `wp_get_community_events_script_data()` because `wp.api` provides those
 - removed `delete response._embedded` and `._links` from `meModel.success`
 because `response` isn't being passed to `renderEventsTemplate` anymore
 - removed `console.log` statements
 - removed stray `;`

 === Next Steps ===
 * Feedback and iterations on [attachment:40748.diff]
 * Discussion on namespace, see @jnylen0's comment in
 [https://core.trac.wordpress.org/ticket/40702#comment:41 comment:41 in
 #40702]

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


More information about the wp-trac mailing list