Avoiding Common Backbone.js Pitfalls
ozkatz.github.com
Avoiding Common Backbone.js Pitfalls
1–10 of 15 posts
Re: Avoiding Common Backbone.js Pitfalls
#2For what it's worth, all 5 of these points are addressed by the Backbone docs, and there are some further nuances worth mentioning:
1. listenTo() is great when you're connecting from an object (frequently a View) that will be removed long before the object that its observing is removed. But when the two (the observer, and the observed) tend to live and die together in the same cycles, no special care is needed, as garbage collection will simply remove both together.
2. An easier way to avoid multiple DOM reflows when rendering collections, is to simply use a less granular template instead of a document fragment. You can even render the "item" template directly within the optimized "collection" template (remember, a template is just a function that takes data and returns HTML). For example:
3. Absolutely. Addressed in the FAQ: http://backbonejs.org/#FAQ-bootstrap. While bootstrapping models, be careful that you don't inject arbitrary user JSON into the page without properly escaping it first -- if there's any data shared publicly between different users of your app. Otherwise they can throw a "" into their post, and ruin your day.4. All of Backbone's "save" calls are optimistic by default. If you'd rather a specific call be pessimistic instead, just pass "{wait: true}", in order to wait for the server to respond with a 200 OK before emitting the change on the client.
5. Yep. Instead of putting further model changes in a "success" callback, simply have a listener waiting for the "change" event. Then Ajax is out of the equation, and whenever the model state is considered to be "change"'d on the client-side, that change propagates appropriately through the system.
Re: Avoiding Common Backbone.js Pitfalls
#3Great article highlighting some common areas for attention -- especially when first moving from vanilla jQuery to something like Backbone ... but important for any basic Model/View layer separation. For what it's worth, all 5 of these points are addressed by the Backbone docs, and there are some further nuances worth mentioning: 1. listenTo() is great when you're connecting from an object (frequently a View) that wil…
Regarding #4, I totally agree. This is why I'm talking explicitly about the "success" callback - it is often misused.
Re: Avoiding Common Backbone.js Pitfalls
#4Front loading data is an easy way around this and if you're savvy enough you can create a fairly clean, agnostic shim to programmatically handle this for you (so long as you can make your backbone info align with your backend model structure).
Re: Avoiding Common Backbone.js Pitfalls
#5Re: Avoiding Common Backbone.js Pitfalls
#6Re: Avoiding Common Backbone.js Pitfalls
#7Re: Avoiding Common Backbone.js Pitfalls
#8Is backbone the best Javascript framework to go with these days? I'm keen to switch to this style of web development but I'm waiting for the community to pick a winner.
Re: Avoiding Common Backbone.js Pitfalls
#9Is backbone the best Javascript framework to go with these days? I'm keen to switch to this style of web development but I'm waiting for the community to pick a winner.
Re: Avoiding Common Backbone.js Pitfalls
#10I'm looking at the source and it looks like it does not.
https://github.com/marionettejs/backbone.marionette/blob/mas...