Skip to content

Instantly share code, notes, and snippets.

@jmendiara

jmendiara/features.md

Last active August 29, 2015 14:20
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jmendiara/55cb370a9514e969f0f3 to your computer and use it in GitHub Desktop.
Save jmendiara/55cb370a9514e969f0f3 to your computer and use it in GitHub Desktop.
Download ZIP
Angular $http features wishlist
Raw
features.md

This is an opinionated list of desired Angular capabilities and feature lacks, to open debate and looking for best ways to solve them

Caches

  • We cannot be confident about the URL used as cache key: Removing, getting or updating $http cache entries in userland is hard and hacky. httpu.headers helps on solving this issue.
  • $cacheFactory.Cache is private: This causes reimplementing all the logic for a $cacheFactory API, instead of letting users to specify with kind of cache a $cacheFactory is returning.
  • We cannot control how a $cacheFactory.Cache key is generated: You have to decorate all your $cacheFactory implementations ($cacheFactory.Cache is private). Exposing a key generator method somewhere may help
  • We cannot know if a request comes from the server or the cache Core implementation in $http or an specific $http Caches decoration should be performed, maybe adding a userland header.

Interceptors

  • Every request traverses all the registered interceptors All interceptors needed for backend A, are traversed by requests against backend B (for example: A is your API backend, B is your webserver backend where you get templates from). When you are accessing several API backends, you have to code flags in every interceptors to guess if they apply. Specifying per-request o per-backend interceptors in core seems the best approach, as caches, paramSerializer (v2.4.0), transformRequest... httpu.composite helps on solving this issue.
  • Rejecting on request causes api inconsistency in subsequent responseError: cause of that undefined in the interceptor chain, rejecting in an interceptor request causes the first requestError reached to have the value of that rejection as param. But if a request fails in the core land (timeout or server error), the param to the first requestError is constructed by core in the resolvePromise. For example, it has a config property with the original request config. You have to code an object adaptation to keep consistency with interceptor.request rejections

URLBuilding

  • We cannot control how a full URL is generated (serialized from params and finally constructed) Finally, the $httpParamSerializer landed in v2.4.0, allowing you to custom serialize the request params. But still there is not full control in core to construct URLs, for example, concatenating parameters with ; or make whatever crazy thing you want. httpu.urlbuilder helps on solving this issue.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment