[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