woops, misclicked... instead of a big SELECT WHERE id in (1,2,3), but what that does mean is that there's only one pending XHR instead of twenty, which can incur quite a lot of overhead, I found we had a huge latency cost with all those little XHRs.
e On Thu Nov 20 2014 at 5:00:01 PM Eric Eslinger <[email protected]> wrote: > 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.
