Using Backbone.js:
When a user logs out is it normal to delete a bunch of models and collections?
That's what I plan to do in my application to prevent zombie data/bindings but I dont know if it's the best way to handle things.
If this is a good practice should I just call delete this on cleanup?
the zombies you need to worry about come from binding to events. i wrote a post about this from the perspective of views: http://lostechies.com/derickbailey/2011/09/15/zombies-run-managing-page-transitions-in-backbone-apps/
in your case with models, you should do the unbinding first and then delete the models and collections you don't need. calling delete whatever is the best way to ensure that things are truly gone. be sure to unbind from your model and collection events first, or you'll end up with bindings that point to undefined and cause exceptions.
Related
I have a Backbone Collection that users are performing CRUD-type activities on. I want to postpone any changes from being propagated back to the server — the Collection.sync() should not happen until the user initiates it (like POSTING a form).
As it stands, I have been able to implement on-the-fly updates with no issue (by calling things like Model.destroy() on the models when deleted, or Collection.add() to add new models to the collection. As I understand, I could pass the {silent:true} option to my models, preventing .sync() from being called during .add()/.destroy(), but from what I can tell, that could lead to some headaches later.
I have considered overriding Backbone.sync, but I am not sure if that is the best route — I feel like there is some way to hook into some events, but I am not sure. Of course I have read through the Backbone docs, annotated source, and relevant SO questions before posting this, but I have hit a wall trying to extrapolate for this particular situation.
Eventually I will need to implement this in many places in my application, which is why I am concerned about best-practices at this stage. I am looking for some guidance/suggestions/thoughts on how to proceed with preventing the default behavior of immediately syncing changes with the remote server. Any help is appreciated — thank you for your time!
EDIT:
I went with Alex P's suggestion of refactoring: in my collection I set up some attributes to track the models that have been edited, added, or deleted. Then, when the user triggers the save action, I iterate through the lists and do the appropriate actions.
The first step is to ensure that your collection is being synchronised when you suspect it is. Collection.add() shouldn't trigger a Collection.sync() by default (it's not mentioned in the method documentation or the list of events, and I couldn't see a trigger in the annotated source).
Model.destroy() does trigger a sync(), but that shouldn't be a surprise - it's explicitly defined as "destroying a model on the server", and that sync() is performed on the model, not the collection. Your destroyed models will be removed from any collections that contain them, but I wouldn't expect those collections to sync() unless explicitly asked.
If your collections really are sync()ing when you're not expecting them to, then the most likely culprit is an event listener somewhere. Have you added any event listeners that call sync() for you when they see add or remove events? If your collection should sync() only on user interaction, can you remove those event listeners?
If not, then passing {silent: true} into your methods might be a viable approach. But remember that this is just stopping events from being emitted - it's not stopping that code from running. If something other than an event listener is triggering your sync()s, then preventing those events from being emitted won't stop them.
It would also be worth considering a wider refactor of your app. Right now you modify the collection and models immediately, and try to delay all sync()s until after the user clicks a button. What if you cached a list of all models to destroy & items to add, and only performed the actions when the button is clicked? Storing the model IDs would be sufficient to destroy them, and storing the collection ID and model ID would let you add items. It also means you don't have to fetch() the collection again if the user decides not to save their changes after all.
In our project we have a event agree-gator used to save the data.We have many views who listen to the save and do there work. its all independent.
Now what we want to do is have a mechanism to know that all views are done with the save.
Basically meaning find out if all event subscribers are done with there work.
Do you guys know of a pattern which we can sue or do we need to redesign save infrastructure.
Seems not dissimilar from what jQuery Deferreds allow you to do:
http://api.jquery.com/jQuery.when/
In an MVC controller is what holds the business logic. In backbone the
controllers have been renamed to route. Now there are couple of things
which bring in confusion.
Model should have business logic.
Collection is the collection of models.
Views are where the templates are rendered, and most of the DOM
event handling is done.
Apart from routing, what do the routers do? And where should more
of business logic go to the routers or to the models?
Do the views perform anything extra other than rendering DOM
variables?
Yes they should, also should be the ones with a "link" to the Backend, to do the CRUD, but can also validate object state, ensure backend and frontend model sync and other things.
Correct again, but they also have a very nice use that is to fetch lists of models from the server very easily.
They should also attach event handlers to HTML elements and models and react to those events accordingly.
4.They handle all URL changing events and direct them to display the proper views for that URL, routers give you the opportunity to change your page completely and keep track of the URL changes by using Backbone.history, so Back and Forward Browser buttons will keep working.
They do the URL mapping.
It's an awesome framework, I can't live without it anymore.
IMHO:
You don't need to use routers et all, if you use them the should just route.
Views should contain all the DOM/Model-Event listeners.
Some Ideas on structuring: http://ricostacruz.com/backbone-patterns/
Sorry if the question is vague but I am really having trouble finding information on this. I come from the Flex/ActionScript world where, for the most part, we have very simple Value Objects (VOs) to represent things like a User or an Address and we have Models that usually represented collections of those VOs along with business logic. There were some frameworks that would include a view model, MVVM. I know that there is no "right way" to do these things but I can't seem to point my finger on the basics.
Are all Backbone views supposed to have their own models? Given that I will likely not have a view called "User", would I also include domain models?
Would folders look something like this?
App
models
domain
User
Address
view
UserProfileModel
views
UserProfileView
collections
Users
Again, sorry if this doesn't make sense or is too general. I am just trying to get an idea of how far along the JS world has gotten in terms of MVC patterns. Thanks.
I don't think there is an only-one answer here. Every case will have an answer.
Are all Backbone views supposed to have their own models?
No.
There will be Views that will make reference to a Model, other ones will be making reference to a Collection. There will be also Views making reference to multiple Models, and others those will make reference to no-Model at all.
A View is an User Interface. It shows data to the User and listen to the events the User trigger on this data representation.
For example, if I have a Model called Friend and I want to create an interface to list a bunch of this Models I'll have:
FriendsView: which is a View that represents a Collection of Friends.
FriendView: which is a sub-View of FriendsView wich represent only one Friend. It can also listen to the click on the destroy button for this Friend.
But also I'll want to have a form to search from Friends in my server:
FriendSearchView: which not have reference to any Model or Collection. But is listening to the User filling an input field.
Would I also include domain models?
I don't know what do you mean with domain models but if you are asking about where to put the business logic Backbone is very agnostic about that. I recommend to put as much calculation as possible into the Models or Collections. Also you can use your own pure JS Util library.
Keep the Views clean. Only responding to User events and calling Model and Collection methods as needed. Also listening in changes in the Model or Collection from which it is showing the data.
How folders should look like?
Well, Backbone is again agnostic about this. There are a lot of literature about this.
My projects use to be small, less than 30 files. I put all of them in the same folder with a naming convection like this:
Friend
Friends
FriendView
FriednsView
I am just starting out with backbone and am trying to set up a view which has a question list. To the left of the list I have four filters, to filter the list by language, country, status, and study. The list and each of the filters are loaded into their own collections.
My idea was to make this one view with multiple collections, but I wonder if this is best practice in backbone since all the examples I have seen only have one collection per view.
Another idea was to break in into two views with one being responsible for the filters and then a child view being responsible only for the list of questions.
Or, is it more backbone style to drop all of the collections into a model and then pass that model to my view like it mentions here: http://documentcloud.github.com/backbone/#FAQ-nested
Thanks for your ideas.
Yes. Theoretically a view can encompass any number of inner objects/collections. It generally makes good sense to have views be as discrete as possible, but there could be reasons to wrap more than one thing in a single view.
This is all a matter of design. I don't see what creating a container model as a bucket for your collections buys you.
Don't be too concerned with the absolute best way. Sometimes it takes walking a little down the wrong path to figure out the better ways for your particular project.
I think it's completely legit to pass more than one model or collection to a view - when appropriate.
Passing a model or collection to a view constructor will automatically appended that object to the view instance (so it's in this.model or this.collection) but you can also pass other data such as extra collections and they will be located in the options object (accessible from within your view as this.options.countries, etc.). Your views initialize method, if it exists, will also be passed this object.
Not sure of best practices but if you can break it into views then its good. Otherwise you'll be better off creating a view model with multiple collections in it and use them in the view.