Convert endpoint functionality to mixins #168
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR extracts the filtering and query parameter methods into mixin functions that can be added to a constructor to grant it the specified methods. In addition to this significant (architectural) change, filters and parameter setters no longer have implicit interdependencies: with the exception of .param itself, which is a part of the base WP-Request class, all filter methods depend on each other directly where needed so that any filter can be included into a subclass with no restrictions. The goal of this patch is to 1. decrease code duplication between endpoints 2. better surface and test edge cases in parameter and filter methods 3. simplify the ability to add filtering functionality to programatically- generated endpoint handlers (see #145) To accomplish these goals I - moved CollectionRequest filter methods into a filter mixin module - moved CollectionRequest parameter methods into a parameter mixin module - moved filter and parameter mixins from other endpoints (page, taxonomies, comments) into the filter and parameter mixin modules as appropriate - unit tested the new filter and parameter mixin modules - adjusted how `.filter` and `.param` function to address edge cases exposed during testing, such as unexpected behavior when calling `.filter` or `.param` with no second argument. - allowed filters to initialize their own private state objects (the `this._filters` and `this._taxonomyFilters` objects), so that they can be included into a prototype without any further pre-work required to make them function with that constructor - removed all existing explicit definition of `this._filters` and `this._taxonomyFilters` objects in endpoint request handler constructors, since those objects will now be created only when needed There is currently some duplicate testing logic between the mixin files and the request handler tests themselves; this is not seen as a detriment but since the mixins are fully tested the assertions in the constructor test suites may eventually be replaced with tests that verify the mixins have been applied properly.
kadamwhite
force-pushed
the
convert-endpoint-functionality-to-mixins
branch
from
90c1ebf to
6b7c758
Compare
kadamwhite
added a commit
that referenced
this pull request
Jun 24, 2016
This release makes some key changes, adds some essential functionality, and re-wires things under the hood. I am unilaterally adopting the model of naming releases after albums, because I am releasing this in Vienna and "Mozart's House" by Clean Bandit (New Eyes, track 1) has been stuck in my head throughout WordCamp Europe. **Autodiscovery** Autodiscovery is now supported via the `WP.discover` method (#181) **Bootstrapping** If you already have the API response object you want to bootstrap with, the `.routes` property from it can now be passed in when calling `WP.site` or instantiating a `new WP` object (also #181, documented #182): ```js var site = WP.site( 'http://my-endpoint.com/wp-json', endpointJSON.routes ); ``` A script to ease the process of downloading this JSON object was added in PR #175 **registerRoute** Arbitrary methods for custom endpoints can now be added without auto- discovery by using the `.registerRoute` method, which takes the same route configuration strings as `register_rest_route` in the API core. **Internal Re-Architecture** In #168 the innards of the library were totally gutted and re-written to support autodiscovery, registerRoute and bootstrapping. **Human-Readable names for HTTP verbs** `PUT` and `POST` are not the most intuitive words for what they do, and POST in particular caused a lot of semantic confusion with the post object within the WordPress data model. `.post` has become `.create`, and `.put` has become `.update`. **Upgraded Dependencies** Package dependencies and developer tools have all been updated to the latest version in their respective ranges. **Props** @props to the community that submitted code, bugs, issues, questions, or comments that added to & informed this release. For general advice & conceptual validation: @rmccue For assisting with the discussion about how to handle autodiscovery and custom route endpoints: @adamsilverstein @aedensixty @andreipot @artoliukkonen @BenHen75 @chrishutchinson @elyobo @gnarf @ishaan-puniani @jasonphillips @joehoyle @jupitercow @timmyc For opening issues and asking questions: @aedensixty @dasheck0 @JSteranko @nabeards @satish9323 @stompweb We still owe responses to: @MurhafSousli @smedegaard @tommedema @vtripolitakis
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR extracts the filtering and query parameter methods into Mixin functions that can be added to a constructor to grant it the specified methods. In addition to this significant (architectural) change, filters and parameter setters no longer have implicit dependencies on one another: with the exception of
.paramitself, which is a part of the base WP-Request class, all other filter methods depend on each other directly where needed so that any filter can be included into a subclass with no restrictions.Unit tests have been added for all new mixins.