Backbone provides models, collections, and views for complex Javascript applications. The model is used to bind key-value data and custom events; the collection is accompanied by a rich API of enumerable functions; the view can declare event handling functions and connect to the application through the RESTful JSON interface.
When we develop a web application with a lot of Javascript, one of the first things you need to do is to stop attaching data to the DOM object. Create Javascript applications through complex and varied jQuery selectors and callback functions, including keeping synchronization between HTML UI, Javascript logic and data, is not complicated. But for client applications, a good architecture usually has many benefits.
Backbone renders the data as a model, you can create models, verify and destroy models, and even save them to the server. When the UI changes cause the model attribute to change, the model will trigger the "change" event; all views that display model data will receive notifications for the event, and the view will then be re-rendered. You don't need to search for the DOM to search for elements with the specified id to manually update HTML. —Once the model changes, the view will automatically change.
It provides a set of web development frameworks, key-value binding and custom event processing through Models, collections provide a rich set of APIs for enumeration functions, event processing through Views, and interaction with existing Applications through RESTful JSON interface. It is a js framework based on jquery and underscore.
Backbone is born not stubborn. One of the most basic points you get from the documentation is: use the tools provided to do whatever you want.
This is very good because there are so many different applications and it is also very easy to start writing an app. This approach may prevent us from making as few mistakes as possible when we first start.
When something is done wrong, we need to discover and find a way to correct it.
The following tips can help you avoid the errors we encounter during development:
1. Views are data-independent (Data-Less)
Data belongs to models (models) and not views. Next time you find that you store data in a view (or worse: in the DOM), move it to the model immediately.
If you don't have a model, creating one is very simple:
= new ();
There really is no need for any other operation.
You can listen for change events on your data, and even sync it online with your server.
2. DOM events only change models
When a DOM event is triggered, for example, clicking a button, do not let it change the view itself. Change this model.
Changing the DOM without changing the state means that your state is still stored in the DOM. This rule allows you to keep your status consistent.
If you click on a "Load More" edge link, do not expand the view, just change the model:
('readMore', true);
OK, but when does the view change? Good question, the next rule will be answered.
Change only when the model changes
Events are amazing, please use them. The easiest way is to trigger it after each change.
(, 'change', );
A better approach is to trigger the change only when needed.
(, 'change:readMore', );
This view will always be consistent with its model. No matter how the model changes: this view will remain updated when responding to actions from the command interface or debug information.
4. The bound things must be unbinded
When the view is removed from the DOM, use the 'remove' method, which must be unbound from all bound events.
If you use 'on' binding, your responsibility is to use 'off' to unbind. If unbinding is not done, the memory recycler cannot free up memory, resulting in a degradation in your application's performance.
This is where 'listenTo' comes from. It tracks the binding and unbinding of the view. Backbone will perform 'stopListening' before moving this from the DOM.
// Ok:
('change:readMore', , this);
// magic:(, 'change:readMore', );
5. Keep chain writing
From render and remove methods, 'this' is always returned. This allows you to write method chains.
().$(otherElement);
This is a good way, don't break it.
6. Events are better than callbacks
Waiting for response events is better than callbacks
Backbone models (models) trigger 'sync' and 'error' events by default, so these events can be used instead of callbacks. Consider these two situations.
({
success: handleSuccess,
error: handleError
});
//This is better:(model, 'sync', handleSuccess);
(model, 'error', handleError);
();
It doesn't matter when the model is filled (fetched), handleSucess/handleError will be called.
7. Views are scoped
A view should never operate on a DOM other than it itself.
View will reference its own DOM element, such as 'el' or jquery object '$el'
That means you should never use jQuery directly:
$('.text').html('Thank you');
Please limit the selection of DOM elements to your own domain:
this.$('.text').html('Thank you');
// This is equivalent to// this.$('.text').html('Thank you');
If you need to update a different view, just trigger an event and let the other view do it. You can also use Backbone's global Pub/Sub system.
For example, we block page scrolling:
var BodyView = ({
initialize: function() {
(Backbone, 'prevent-scroll', );
},
preventScroll: function(prevent) {
// .prevent-scroll has the following CSS rules: overflow: hidden; this.$('prevent-scroll', prevent);
}
});
// Call now from anywhere else:('prevent-scroll', true); // Block scrolling('prevent-scroll', false); // Allow scrolling
One more thing
Just read the source code of backbone and you will learn more. Take a look at the source code and see how these magical things are implemented. This library is very small and has good readability, and it will not take more than 10 minutes to read.
These tips help us write clean, better readable code.