That could probably work pretty well in certain cases, especially when your
$http calls don't vary much but do have some extra massaging to do. I do
like how it encapsulates stuff like loading / error / loaded state
messaging quite nicely.
I'm personally not fond of it primarily because I like to put view/markup
stuff in HTML, and state management stuff in javascript (I was also not
happy about it in polymer, but I understand why they do that).
Instead, what I ended up doing with stuff like related lists (I don't often
fetch all of a thing, but instead fetch all the things that belong to the
page's thing with some relation, like all the user profiles who have liked
this post, or all the replies to this post or whatever) is to create
self-inflating references. So a post has a list of likers that looks like:
post.likes = [{type: 'profile', id: 1}, {type: 'profile', id: 2}] and so
forth. Because I have well-defined data models from the back-end, I do
stuff like use Object.defineProperty on the Profile class, so when I do {{
profile.name}} somewhere in an HTML view, the getter will:
1) immediately return either its cached value or a reasonable default if
there is no cached value (empty string, empty list, etc).
2) if there is no cached value, initiate a $http.get to fetch the value in
question
3) when the $http.get returns, update the cache. This happens inside a
digest cycle anyway ($http.get().then() is inside an $apply or whatever),
so then the view eventually pokes profile.name again, and step 1 returns
"Bob Smith".
This way, I can attach related lists to objects for relatively low cost,
and then only load them when they're actually needed (the fetch stuff only
happens after the thing is painted, so if it is hiding behind an ng-if or
in an infinite scroll buffer, it will remain uninflated). It also means I
usually don't have to put a lot of $http.get().then stuff in my controller
code- I just say $scope.view.post = Post.find($stateParams.postId); and let
the overly-complicated model object code take care of the rest. I've also
attached other useful stuff as related lists on the user's profile object
(my posts, my inbox, etc), so it all just shows up on time.
Of course, this also means that I end up kicking off a ton of individual
XHR requests (all fifteen likers of this post need their name loaded
together) which is inefficient, so I ended up writing my own batching layer
on top of $http.get to do just that.
Eric
On Thu Nov 20 2014 at 3:09:09 AM Samuel Richardson <[email protected]>
wrote:
> At the moment in my app I'm handling all fetching of data inside my page
> controllers. A repeating pattern in all of them goes something like:
>
> $http.get('/users.json').then(function (users) {
> scope.users = users;
> });
>
> After looking at and using Polymer's web components, I found their
> <core-ajax> element which is used for loading data and I'm thinking about
> implementing something similar in my code.
>
> This would consist of a directive with a transclude which would load the
> data via ajax and place it into the page controllers scope (or directives
> scope if it's used inside a directive). It could look something like:
>
> <load-ajax path="/users.json" params="{}>
> <div ng-repeat="user in users">
> {{user.name}}
> ...
> </div>
> </load-ajax>
>
> I want some feedback on if this is a good idea or if I'm trying to do too
> much with the directives. My thoughts are:
>
> Pro
> ---
> * DRY all the ajax loading code (my code is actually more complex then
> this example so this is quite good)
> * Easy for the designers to fetch data for the templates.
> * Easy to show loaders while the promises have not resolved (simple
> ng-show/hide inside the load-ajax template html)
> * Easy to have attr.$observes on the params to automatically re-fetch the
> data. You could use this easily with route params etc.
>
> Con
> ---
> * Hides what is being added to the scope as it's not visible in the
> controller.
>
> Thoughts? Am I going down the wrong track? ;)
>
> --
> You received this message because you are subscribed to the Google Groups
> "AngularJS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/angular.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.
