Large organization of web applications backbone.js

Question

I am currently working on a large web application based on backbone.js and you have a lot of problems with organization, zombies, etc., so I decided to do the main code refactoring. I already wrote a bunch of helper functions for working with "zombies"; however, I would like to start from the very beginning and create a good structure / organization for the code. I did not find many great tutorials / examples for large-scale backbone.js organization, so I started from scratch and would like to know if I can get some opinions on where I started.

I obviously set up my code in a global namespace; but I would also like to keep this namespace pretty clean. My main app.js keeps class files separate from the global namespace; you can register a class (so that it can be created) using the reg () function, and the inst () function creates an instance of the class from an array of classes. Thus, in addition to 3 methods, the MyApp namespace has only Router, Model and View:

var MyApp = (function () { var classes = { Routers: {}, Collections: {}, Models: {}, Views: {} }; methods = { init: function () { MyApp.Router = MyApp.inst('Routers', 'App'); MyApp.Model = MyApp.inst('Models', 'App'); MyApp.View = MyApp.inst('Views', 'App'); Backbone.history.start(); }, reg: function (type, name, C) { classes[type][name] = C; }, inst: function (type, C, attrs) { return new classes[type][C](attrs || {}); } }; return methods; }()); $(MyApp.init); 

In models, collections, routers and views, I work as usual, but then you need to register this class at the end of the file so that it can be created at a later point (without cluttering the namespace) with

 MyApp.reg('Models', 'App', Model); 

Does this sound like an unnecessary way to organize code? Others have examples of how to organize really big projects with many routers, collections, models and views?

Answer 1

I recently worked on a Backbone project called GapVis ( here , the content presented here ). I don’t know if it’s really “really big”, but it is big and relatively complex - 24 viewing classes, 5 routers, etc. It may be worth a look, although I do not know that all my approaches will be appropriate. You can see some of my thoughts in a long introductory comment in the main app.js file. A few key architectural options:

• I have a singleton State model that contains all the current state information - the current view, which model identifiers we are looking for, etc. Each view that should change the state of the application does this by setting attributes to State , and each view that should respond to state listens for this model for events. This is even true for views that change state and update — the user interface event handlers in events never re-render the view, this is done instead by binding the display functions to state. This template really helped to separate the views from each other - views never call a method on another view.

• My routers are treated as specialized views — they respond to user interface events (for example, by entering a URL) by updating the state, and they respond to state changes by updating the user interface (i.e. changing the URL).

• I do a few things similar to what you offer. My namespace has an init function similar to yours and a settings object for constants. But I put most of the model and view classes in the namespace because I needed to reference them in multiple files.

• I use the registration system for my routers and I am considered one for my views, as a good way to keep the “master classes” ( AppRouter and AppView ) from being aware of each view, However, in the case of AppView it turned out that the order of children's views is important, so I ended up hard coding these classes.

I would not say that it was the “right” way to do something, but it worked for me. Hope this is helpful - I also had trouble finding examples with large projects using visible sources using Backbone, and I had to work out most of this as I walked.

Answer 2

These 2 resources helped me set up my core applications on a solid foundation:

• https://github.com/tbranyen/backbone-boilerplate
• http://ricostacruz.com/backbone-patterns/#namespace_convention

Answer 3

I use a space similar to what you are doing (at least for part of the classes), and all of my models, views and controllers look like this:

views / blocks.js:

 (function(cn){ cn.classes.views.blocks = cn.classes.views.base.extend({ events: {}, blocksTemplate: cn.helpers.loadTemplate('tmpl_page_blocks'), initialize: function(){ }, render: function(){ $(this.el).html(this.blocksTemplate()); }, registerEvents: function(){}, unregisterEvents: function(){} }); })(companyname); 

My JavaScript namespace looks like this, although I improve it every time I create a new application:

  companyname:{ $: function(){}, <== Shortcut reference to document.getElementById appView: {}, <== Reference to instantiated AppView class. classes = { <== Namespace for all custom Backbone classes. views : {}, models : {}, collections: {}, controllers : {}, Router: null }, models: {}, <== Instantiated models. controllers: {}, <== Instantiated controllers. router: {}, <== Instantiated routers. helpers: {}, <== Reusable helper platform methods. currentView: {}, <== A reference to the current view so that we can destroy it. init: function(){} <== Bootstrap code, starts the app. } 

What I would like all my views to have, I added a basic idea. My controller will call registerEvents on any new view it creates (after rendering) and unregisterEvents before it destroys it. Not all views have these two additional methods, so it first checks for existence.

Remember that all views have this.el.remove(); built in this.el.remove(); . This not only kills the views container element, but also discards all events associated with it. Depending on how you create your views through your controller, you may not want to kill an element and instead disable this.el.unbind () to disable all events.

Answer 4

In fact, there are different advantages and disadvantages of different methods. The most important thing is to find a suitable way to organize files. The following is the organization of the project that I am currently doing. Thus, the focus will be the same as the files associated with the module are placed in a folder. For example: people module, this module all files are placed in the modules / base / people directory. After updating and maintaining this module, you only need to focus on the files in this directory in a line, will not affect files outside the directory, and maintainability will be improved.

Hope my answer can help you, I hope you get some valuable advice.