|
The web link seems to be temporarily unconscious, but Addy Osmani's free e-book was my beginner's guide to backbone.js and brought me up to speed enough to build applications right away. https://github.com/addyosmani/backbone-fundamentals Los Techies has some useful http://lostechies.com/ For me, Marionette is a must. Build an application and then you will realize the difference in CollectionViews, CompositeViews, ItemViews, and Layouts . I can't ever imagine not using underscore.js again. RequireJS is a must. Anyone know of a guide to RequireJS that's a little less... dry(?) than the official documentation? I have trouble getting others started on it because of the incredibly flat tone.
|
#
¿
Sep 20, 2013 03:45
|
|
|
|
| # ¿ May 2, 2024 22:57 |
|
|
I'm certainly still very new to this too, so while I'm going to try to help, my word is still a mere suggestion at this point.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 thiiiink the "proper Backbone" way to avoid spaghetti code would be to call .fetch() on the model to retrieve the data, override .parse() to format it how your model is set up, and use .deferred to continue execution once the request is complete. It took me forever to break away from using $.ajax(). Deferred writeup - http://quickleft.com/blog/leveraging-deferreds-in-backbonejs Wheany posted:Well, I'm going to repost my question from the javascipt thread here: It sounds like a bad idea to refresh a view/form field the user is actively filling out. Is there another way you can structure this? How would this behave outside of a MV* environment?
|
|
#
¿
Sep 20, 2013 14:54
|
|
|
NtotheTC posted:Also, is there not a lot of code duplication required? For example, having to write client-side validation on form fields to gain the benefits of the fast response times/lack of page refresh, but also write validation on the back-end to cover off the genuinely prickish users that try to bypass all your client-side js code? You should be validating form input on both the frontend and backend. Frontend equally for security and for user convenience (and to save you a page reload), and backend for security.
|
|
#
¿
Sep 20, 2013 17:10
|
|
|
If you're working with JSON, use double quotes for the property names. If you're working with strings of HTML via JS, use single quotes so you don't need to escape every double quote. Otherwise, do whichever you prefer (or your team has agreed to use). Either way, just be consistent.
|
|
#
¿
May 11, 2014 18:19
|
|
|
Validation is the responsibility of both parts - on the front-end it mostly benefits the UI/UX (for a non-tampering user), but on the backend it's essential to enforce security and data sanitization. It's best to assume the worst.
|
|
#
¿
Feb 24, 2015 06:16
|
|
|
|
| # ¿ May 2, 2024 22:57 |
|
|
You want to listen to the collection for the 'sync' event, then trigger your method calls after. Though it might make more sense to fetch the collection in the code that normally creates that view instead. On a successful fetch, create that view, and then you know the fetched collection will be available. You could also instantiate a promise (like $.Deferred()) on initialize, resolve it on parse, and use $.when().then() to run code once it's resolved.
|
|
#
¿
Apr 30, 2015 21:55
|
|