Skip to main content

More on MVVM with Backbone Stickit plugin

In my last post, I mentioned about two way binding a.k.a MVVM in Backbone using Backbone.Stickit plugin. The Stickit plugin does provide awesome two way binding, but in addition it includes several features that are very much apt when modifying state of model or the view. I've been using these features in my project regularly.

The bindings configuration is used to specify the binding between the view and model. When you specify this configuration, the model changes are observed and view is updated whenever there is a change and similarly any changes in the view would update the model. There are many scenarios where in the format of the model or view has to be changed. For example, the model stores a date in a specific format and the view has to display the same in a different format. The Stickit plugin provides methods - onGet and onSet which can be used in such scenarios:



Here, instead of providing a one to one mapping between the view element and the model attribute, an object containing the binding configuration is specified. The configuration has three attributes - observe, onGet and onSet. The 'observe' attribute specifies the model attribute that the view element should be mapped to. Before the view element is updated, the 'onGet' function is called, here the function formats the date value present in the model and the view is updated with the formatted value. Now when you change the date in the view, the 'onSet' method is invoked before updating the model. The 'onSet' method, formats the input date and updates the model. These two methods intercept the update of view and model; helping you to format data correctly.

The other feature that I use regularly when working with authorization piece is the use of 'visible' and 'visibleFn'. In a scenario where, based on the logged in user's credentials some part of the page would be hidden or shown to the user; this feature comes very handy.


Here the function assigned to 'visible' attribute is executed to check whether the logged in user is an 'admin'. It returns a boolean value and based on the whether it is true or false, the view element would be shown or hidden. The 'visibleFn' is optional, by default if 'visible' is true then the view element would have the style attribute 'display' set to 'block' and if false, the element would have 'display' property set to 'none'. If you want change the 'display' property from 'block' to say 'inline-block' or if you want perform an animation before hiding the element, then the 'visibleFn' should be specified.

Another feature that I have used in my projects is the use of 'selectOptions'. This feature is used to populate a 'select' element in the form with 'option' tags using a collection of objects.

Here 'selectOptions' specifies the collection attribute which contains an array of objects, each object with properties 'timeZoneName' and 'timeZoneId'. These properties are assigned to 'labelPath' and 'valuePath' attributes. When 'option' tags are generated, the label name and value of the option tag would be referencing these properties. The 'defaultOption' configuration is used to either specify the default value or define a placeholder for the select element. When you select an element from the 'select' drop down, the model attribute 'timezone' would be updated.

There are several other features in the Stickit plugin, like adding custom handlers, selectively updating the model or view - http://nytimes.github.io/backbone.stickit/ 
Labels:

Comments

Post a Comment

Popular posts from this blog

How to use the APP_INITIALIZER token to hook into the Angular bootstrap process

I've been building applications using Angular as a framework of choice for more than a year and this post is not about another React vs Angular or the quirks of each framework. Honestly, I like Angular and every day I discover something new which makes development easier and makes me look like a guy who built something very complex in a matter of hours which would've taken a long time to put the correct architecture in place if I had chosen a different framework. The first thing that I learned in Angular is the use of the APP_INITIALIZER token.
Post a Comment
Read more

On GraphQL and building an application using React Apollo

When I visualize building an application, I would think of using React and Redux on the front-end which talks to a set of RESTful services built with Node and Hapi (or Express). However, over a period of time, I've realized that this approach does not scale well when you add new features to the front-end. For example, consider a page that displays user information along with courses that a user has enrolled in. At a later point, you decide to add a section that displays popular book titles that one can view and purchase. If every entity is considered as a microservice then to get data from three different microservices would require three http  requests to be sent by the front-end app. The performance of the app would degrade with the increase in the number of http requests. I read about GraphQL and knew that it is an ideal way of building an app and I need not look forward to anything else. The GraphQL layer can be viewed as a facade which sits on top of your RESTful services o...
Post a Comment
Read more

Using MobX to manage application state in a React application

I have been writing applications using React and Redux for quite some time now and thought of trying other state management solutions out there. It's not that I have faced any issues with Redux; however, I wanted to explore other approaches to state management. I recently came across MobX  and thought of giving it a try. The library uses the premise of  `Observables` to tie the application state with the view layer (React). It's also an implementation of the Flux pattern wherein it uses multiple stores to save the application state; each store referring to a particular entity. Redux, on the other hand, uses a single store with top-level state variables referring to various entities.
Post a Comment
Read more