|
Couple of points I'd love you guys to elucidate for me:
|
#
¿
Sep 20, 2013 05:39
|
|
|
|
| # ¿ Apr 25, 2024 05:20 |
|
|
PlesantDilemma posted:On the app that we used backbone.js for, we did not have to do 'backbone specific' back-end work. We just ignored backbone.sync and wrote our own ajax handlers for getting data from the server. So we don't call model.sync() or model.fetch(), but the rest of the backbone system works fine. I think I might have explained myself poorly. The question was about how easy it'd be to turn only one portion of the front-end into a MVC thick-client javascript app with Backbone vs Angular respectively.
|
|
#
¿
Sep 20, 2013 08:45
|
|
|
Say I hypothetically want to implement a page where I let a teacher edit a class roster. Add students, remove, edit names etc, very similar to your traditional ToDo list sample. I still want the rest of the website to be server-side templated, but I might want to make the actual editing part of the student list to fully MVCed to avoid obnoxious refreshes. I'm familiar with Backbone and could get that done in there pretty painlessly, but I keep hearing that with Angular you might get more structure that would implementing something like the above a less boilerplatey process. I'm a big fan of a thick API approach (and I have to support virtually the same functionality in mobile as well, meaning I need to push as much logic down as possible to avoid duplication), and am very happy with treating my MVC web UIs as a really dumb and simple wrapper, with no sophisticated logic. Is that something Angular would be a great fit for?
|
|
#
¿
Oct 17, 2013 18:57
|
|
|
So I've gone through the knockout.js tutorial and it looks pretty minimalistic and very embeddable, from what I can tell. Not opinionated about how you sync the data, so you can just regular jquery ajax or whatever else you fancy. Anybody here have experience using it over a few months?
|
|
#
¿
Oct 22, 2013 01:21
|
|
|
Does anybody here support mobile clients in addition to your thick web clients? I've recently been trying to move our backend from being just an API servicing web/mobile to actually doing server-side templating itself, but my struggle is with having to support multiple flows when one should really suffice. What I mean is that I pretty much cannot avoid using ajax on client-side for DELETE/PUT routes or I have now support the _method hack that Rails does, which now means I have to make sure I interpret my GETs and POSTSs correctly based on the additional param. That's not even the biggest pain point, but now the backend has to control redirections between pages on form submission, I have to expose the same API routes in the URL (rails-style, again) or duplicate them and many others. On one hand I'd like development to be faster without having to go through client MVC, on the other I get to re-use the same API routes and the same input validation facilities I already have in place. Tough call, but I'm probably going to err on the side of keeping the backend cleaner and purely JSON-based at this point.
|
|
#
¿
Oct 22, 2013 22:18
|
|
|
Anyone here got experience with Marionette? I'm liking the idea of perhaps swapping the regular Backbone views with the "managed" ones to avoid some of the typical boilerplate, and the region swapping logic seems pretty reasonable too (even though layoutManager is supposed to be doing the same). I like the idea that you can pick and choose which pieces of it you want instead of buying into the entire ecosystem of classes, which seems to go a bit over the top with all the different options.
|
|
#
¿
Nov 19, 2013 21:52
|
|
|
sim posted:If you're going to use Backbone to any extent, Marionette is pretty much required for view management. Like you said, you'll end up writing boilerplate code for everything Marionette does anyway, so you might as well just use it from the beginning. CollectionViews (and ItemViews) are super useful too. Ended up using LayoutManager for now, seems like it provides pretty much the same benefits of view lifecycle management.
|
|
#
¿
Nov 21, 2013 04:13
|
|
|
|
| # ¿ Apr 25, 2024 05:20 |
|
|
This has been bothering me for a long time and maybe you guys know the answer. Does anybody have advice on how to properly structure lazy fetching of resources in nested views with Backbone + LayoutManager? Say you have a tree of views, and the topmost view calls render() (that's how LayoutManager does it at least) on its children views, which recursively go ahead and call render() on their own children etc. This is all fine and well until you need to fetch() a collection or a model in order to be able to render one of the views in the tree, an asynchronous operation. Do you essentially call fetch() on initialization of each view and immediately render a spinner in place, then register a callback on whenever the collection is done and just replace the contents? I think this is the simple case, but I also think there's a situation where some views don't quite know what children views to initialize until an outstanding fetch is completed, in which case now calling render() recursively cannot work, and you have to manually setup logic that checks for the presence of data. The other hassle is that you need to account for two ways of fetching data: sometimes you already have it (a user lazily fetched it before, and never reloaded the app), you can render right away, and sometimes you don't, so you need to do an async operation. Really wish this crap was less convoluted 
|
|
#
¿
Dec 8, 2013 06:25
|
|