Why study backbone? That’s a good question. In this age of front-end framework explosion, there are more and better development options than backbone, React, Vue, Angular, etc. But these in the use of these frames, the heart is always writing a feeling of unsteadiness. How is MVVM bidirectional binding implemented? How does react implement the Virtual DOM diff algorithm? The downside of a big framework is that it’s hard for beginners to really understand how it works. The principles don’t change, the apis do.

So I decided to calm down to learn backbone, and seriously study its principle. Dig a hole here. Backbone and underscore are reading these days, and strive to write a source code analysis article.

The best way to learn about frameworks is to write an app, so I wrote an app to practice. There was a lot of wasted time in the middle of a completely pointless tangle, so it took a long time to get it right.

This article is a summary, more personal. Mainly talk about the harvest and experience.

Application functions

The app is a resume generator. Backbone + jquery + underscore + webpack + SCSS for the front end and Express for the back end. You can fill in your personal information through the browser interface, send the data to the back end, and use NodeJS to store the data and generate static files. See github’s address for more details.

Related learning materials

Backbone belongs to the typical, when learning to feel very simple, when writing their own face meng forced frame. React was a lot harder to learn, and some of the functional programming stuff was sometimes confusing with Redux. However, it’s still relatively easy to write a passable application by following the tutorials recommended by Redux. However, backbone is on the contrary, it is not difficult to learn, but it is difficult to control a lot of things when writing, and there are many more places to think than using a big frame.

One of the better tutorials is this one. This tutorial introduces the basic knowledge of MVC, backbone, as well as a Todo application, a back-end application and a modular application using RequireJS. Going through this tutorial is probably enough (I only saw Todo… however). . But it is difficult to understand and write big applications with backbone.

modular

Webpack is used here. To be honest, Webpack is a god. AMD or CMD or ES6 modular standard or can be easily packaged compression, there are many very convenient plug-ins, can not be cool… Back in the days of Backbone. Perhaps modularity is not particularly popular, so many examples were introduced with Script. The naming of pollution problems is obvious. Making multiple requests also affects performance. Therefore, it is necessary to package through modularization.

The model and the collection

In Backbone, the code amount of Model and collection is much smaller than view. In the main processing is the view presented data. More importantly, the model is closely tied to the data types of the back-end database. In general, the back-end interface is expected to be “RESTful”, with the front and back ends using JSON as the means of data transfer. In this way, the fetch process is easier when the data is fetched from the back end, and the local data is saved to the server for more natural data processing (all json). Of course, this is not mandatory, using traditional jquery Ajax can also be used, but it might be against the original purpose of backbone. . This is not observed in the application I wrote. The reasons will be explained later.

The default and initialize methods are usually overridden in the model. ToJSON and parse methods need to be overridden if special processing is required for save and fetch data.

In my application, the data structure is quite special. The resume has several small nested collections and several attributes that are not collections, making it a more complex structure. Therefore, toJSON and parse methods were rewritten, but the rewritten parse method was not used later because it was more convenient and straightforward to use jquery ajax directly. See this link for a way to override it. Specifically, when you need to save and post data to the database, parse the model attributes into json structures, and then save them. When fetching data, several collections are initialized with the obtained data (usually json), and then directly added to the model’s properties (attributes in the form of a.b).

. This should have been resolved with a backbone-Relational library or something, but it would have been nice to have solved the problem. In the View, the collection and model will change according to the user’s operation of the view, and the change will affect the view’s data presentation. Other operations on model and collection can be added, deleted, and modified in specific situations. These operations are also often written in views.

view

The View is a big one, and the view is the biggest part of the code in this application.

A view, as the name suggests, is a view, a presentation of data. This is often used with templates. When writing a back-end Express application, because EJS has the include function, the template is sliced into small pieces to avoid the HTML main file becoming too large. But many examples of Backbone simply cram large blocks of templates into the main HTML file. Obviously bad for maintenance. So reference someone else’s code, write the following auxiliary function, read in the VIEW HTML file, and add to the corresponding view template, after reading all call callback function. The code is as follows:

var loadTemplate = function(views, callback) { var deferreds = []; $. Each (views, function(index, view) {if(require('./views/' + view)) { Reds push($.get('.. /tpl/' + view + '.html', Function (data) {function(data) {// Prototype require('./views/' + view).template = _. Template (data); })); } else { alert(view + " not found"); }}); // Call callback $.when. Apply (null, deferreds).done(callback); }Copy the code

This isn’t the best way to deal with HTML oversize problems, but it works fine here.

The main elements in the view are Events, Render and Initialize. In initialize, you can listenTo some model events by listening to.

Sometimes render is required when writing initialize, but in many cases this is not required. After returning this in the render function, you can inject model into the template in other places, such as the router, and then insert the HTML returned by render directly into the page.

var view = new formView({});
this.$container.html(view.render().el);Copy the code

router

Backbone provides convenient routing functions. In my app, the entry of the whole program is the router function. You can use different URLS to bind different functions, and call the view’s function in the function to implement different HTML fragments of different routes. However, in the actual operation, there was a difficulty that could not be solved from beginning to end, probably because my personal ability was not enough. It was replaced by a worse method. The problem is as follows: If you want to define the route ‘/: TAB /:filename’, the route function will be called every time the route changes. If I create a new model instance in this routing function, then when I want to change the TAB, I have to trigger the routing function again to create a new Model. However, I hope that the model will not change, because TAB is a TAB page in filename and cannot be rebuilt by changing a TAB. How do you do that? After three days of thinking, I finally gave up… (Or maybe your needs are a little weird.)

Other small gains

Window.print () calls the browser print function. One small takeaway is the size of the browser print, adjust it to A4 proportions and margins, and then determine the scale of the center area of the page. The second harvest is to find that taobao icon library iconfont is really very good, it is also very convenient to use, you can go to borrow material HHH later

sorry

This little app still leaves a lot to be desired

  1. Not enough UI, not enough resume page design. (Want to explode the head do not know how to do better…)

  2. The function is not powerful enough, it would be nice if many contents could be filled in more carefully…

  3. It’s not convenient enough to deploy Github.

  4. Node generates pages using some concatenated string methods, which are not very elegant…

conclusion

Through the preparation of backbone application, backbone is a preliminary understanding of it. I also have a general understanding of the MVC framework. Backbone and underscore are currently looking at the source codes of backbone and underscore. Tomorrow or tomorrow, WE will start to write an article about the source code interpretation and summarize the areas worth learning in Backbone. (I’m still reading it now, but I think it’s interesting to see the browser compatibility considerations in History, and I want to look at design patterns in Events.) The last of this summer vacation will slowly see several times backbone, learn a good!

Backbone aspect I still a small white, the article has the mistake please light spray, mutual learning! Thank you!

Code here, I hope to help you ~