I'm testing it out now to see how it goes. Encapsulating the load states
makes it very easy to implement loading / failure messages in the dom. If I
go further and implement query string params via an attribute on the
<load-ajax> directive then I can setup watchers on them to automatically
re-fetch data too.
I do have limited massaging of data in some cases (e.g. outputting it into
AngularGantt) but I think I might actually handle it in a similar manner to
the AJAX calls via a custom directive which adds the transformed data to
the parent scope.
I really like your implementation of the dependent loading. I'm going to
refactor our caching system soon and you've given me some good things to
think about. We're dropping support for IE8 which means I can use the
define property getters/setters (and we're using TypeScript, even easier!).
I'm not convinced on the request batching though, wouldn't that make it
hard to implement caching on your API endpoints if every request is
slightly different depending on the state of the logged in user?
Sam
On Friday, 21 November 2014 05:35:46 UTC+11, Eric Eslinger wrote:
>
> 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]
> <javascript:>> 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] <javascript:>.
>> To post to this group, send email to [email protected]
>> <javascript:>.
>> 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.
