So you are frustrated tackling BackboneJS and wondering why it isn’t solving your problems as you had expected it to, after hearing about its glorious penetration in many high profile projects. Well, join the club, you are not alone. Here I’ll share my expectations when I imported BackboneJS for the first time in my project and my learning that I gained after weeks of trial and error and frustration.
Backbone is like a hammer, if you do not know what you are trying to build, the hammer will not build it for you. It does give you some powerful functions, but the burden of creating a strategy for your front-end falls on your own shoulders. But worry not, here are some ideas that might help you create your strategy.
If you have written jQuery plugins, or developed any other UI elements, you would know that we tend to divide a page into different UI elements. Each UI element requests the data it requires and renders it within itself. With simple apps, this strategy works, but as the complexity of an app grows, things tend to become tedious. It becomes increasingly difficult to reduce redundant data requests and maintain integrity of those UI elements which render same data.
The Paradigm Shift
BackboneJS reverses this relationship between data and UI elements, and this is what I would like to call paradigm shift. If you would try to build your app with BackboneJS and traditional paradigm you will end up creating a meatball sundae.
In a BackboneJS app, your data is the primary citizen and views are slaves. In the rest of the post, I’ll try to explain how this master-slave relationship is supposed to work.
Model Is The Backbone
Model is the data structure of your application, hence earns the title of “backbone”. You instantiate your Model when your application initializes, display its state through different Views, update the state through different controls and so on and so forth. Everything revolves around the Model, so take extra care to keep it clean and maintain its integrity through different checks and balances.
Views Are Secondary Satellites
A piece of UI is called a View in BackboneJS world. Views serve to:
- Display models
- Change state of models
- Update themselves when model state is changed
A View is usually provided with a Model (or with a Collection of Models) on instantiation, with which the View binds itself. By binding I mean that the View updates itself when some events occur in the Model. A View only acts as a mediator between the Model and the user: when a Model is updated, View delivers the information to the user by visually updating itself and delivers user’s commands back to the Model using controls.
In theory, a View should not change its own state from within itself. If a View needs to be changed,
its Model should be changed only, and the Views bound to that model, including the first View, should updated themselves consequently. Similarly a View cannot change a Model’s state unless it a command from the user. The idea forces one to place most of the business logic into the Models.
Routers Only Help Setup A Stage
Routers only allow you to setup your model on a page (URL) and instantiate some views with it. Once your stage is ready, router remains there no more, and focus should be shifted towards the model states.
Don’t Use Any Plugin Before You Know The Problem They Are Solving
BackboneJS has a huge community and it keeps on churning a new plugin every other day. Many of those plugins look shiny and claim to make your life easier. Some of them definitely succeed in making life easier but in my opinion using them prematurely could backfire and increase complexity instead of decreasing it. So they should not be touched unless you really know the problem they are trying to solve.
Core BackboneJS library is powerful enough to tackle most of the complexity so give it a try first. Simplicity is the key.
Avoid Unnecessary Server Calls
BackboneJS forces you to expose server side database through REST APIs and makes it delightfully simple to bind those APIs to frontend Models. One might be lured to make everything dynamic and fetch ALL of the data dynamically, but that is not the point of BackboneJS and it will only make your app inefficient.
A better approach would be to categorize your data into two types: one which you know you will surely need on page load and the other, whose requirement will be dependent upon different events. Use dynamic fetches for only second type of data. For first type of data, print the data in JSON format in a script tag on your HTML page through your server side HTML generator, and instantiate your Models with that JSON on page load. This way you’ll be saving some extra HTTP requests and creating a better experience for your users.
Keep It Simple
As I mentioned earlier, the whole point of using BackboneJs is to make your code cleaner and simpler while creating rich user experience at the same time. Design simple Models and simple Views. Keep Models highly independent: a View may refer a Model in its code, but a Model should not refere a View. If it is not simplifying your code, you are probably doing something wrong.
Common Steps To Design A Page
Here is a small checklist that might help when designing a page.
- Create your Models.
- Create your views (which, at this stage, should only render initial states of their Models and not change their states).
- Bind your Views to Model events (make sure Views update themselves when their Models’ states are updated).
- Test your Views (update your Model state manually through console and see how the Views respond)
- Create your controls (which modify model state)
Of course, the ideas that I discussed above are not official and I learned them through my own experience. So they might be flawed or there might be some corner cases which I missed. If you happen to see any, please do let me know. One of the motivations behind writing this post was to get a validation of my learning from more experienced folks.
On the other hand, if this post helped you solve any of your problems, please share that as well. Any other ideas/thoughts/suggestions/feedback are welcome.
No related posts.