I do really stupid batching right now. One key thing is that my backend supports regular batching through a server plugin. I use hapijs, and the plugin is bassmaster. Basically, instead of doing a bunch of GET /user/1 /user/2 /user/3 individually, bassmaster allows me to POST a json request that looks like ['GET /user/1', 'GET /user/2'] and so forth, handles all the re-routing on the server side, and then responds with an array of results.
This doesn't make anything more efficient, query-wise (it still does individual SELECT statements in the SQL instead of a big SELECT WHERE id in (1,2,3 On Thu Nov 20 2014 at 3:34:24 PM Samuel Richardson <[email protected]> wrote: > 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]> >> 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. > -- 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.
