Javascript – Object watch (on all browsers)

Javascript’s is a function which tends to work only on Firefox.. How do we make it work on other browsers? Below is the code snippet to achieve this:-


Common JS Snippet for making to work on all browsers

if (! {
Object.defineProperty(Object.prototype, “watch”, {
enumerable: false
, configurable: true
, writable: false
, value: function (prop, handler) {
oldval = this[prop]
, newval = oldval
, getter = function () {
return newval;
, setter = function (val) {
oldval = newval;
return newval =, prop, oldval, val);

if (delete this[prop]) { // can’t watch constants
Object.defineProperty(this, prop, {
get: getter
, set: setter
, enumerable: true
, configurable: true

// object.unwatch
if (!Object.prototype.unwatch) {
Object.defineProperty(Object.prototype, “unwatch”, {
enumerable: false
, configurable: true
, writable: false
, value: function (prop) {
var val = this[prop];
delete this[prop]; // remove accessors
this[prop] = val;


Code Example:-

//Create an object and assign a initial value

var my_object = { blog_name:  “” };

//Adding listener (watcher)‘blog_name‘, function (id, oldval, newval) {
console.log(‘my_object.’ + id + ‘ changed from ‘ + oldval + ‘ to ‘ + newval);
return newval;

Now changing the value of blog_name will print the console statement:-


Angular JS Best Practices

1. Create one directive per file
2. Create one controller per file
3. Create one service per file
4. Have only routes and general usablility code on app.js
5. Don’t ever user $rootScope, rather make use of Angular services
6. Prefer Restangular for complex API calls, $http for simple API calls, avoid $resource.
7. Don’t use {{ }} on view files, rather use either ng-bind (or) data-prefixed version
8. Use native for loops than angular.forEach
9. Only for a small storage purpose go for $cookieStore, for storing medium and large informations use $localStorage or $sessionStorage according to the need


UpperCamelCase for Controllers and constructor Services, lowerCamelCase everywhere else.


The naming of the controller is done using the controller’s functionality (for example shopping cart, homepage, admin panel) and the substring Ctrl in the end. The controllers are named UpperCamelCase (HomePageCtrl, ShoppingCartCtrl, AdminPanelCtrl, etc.).


Name your directives with lowerCamelCase.


Name your filters with lowerCamelCase.


Use camelCase to name your services.

  • UpperCamelCase (PascalCase) for naming your services, used as constructor functions
  • lowerCamelCase for all other services.

Note that Services always return singletons. Unless you create a special service to return a newed object each time it gets called–in this case, and only in this case should you use PascalCase naming.


├── index.html
├── scripts
   ├── controllers
      └── main.js
      └── ...
   ├── directives
      └── myDirective.js
      └── ...
   ├── filters
      └── myFilter.js
      └── ...
   ├── services
      └── myService.js
      └── ...
   ├── vendor
      ├── angular.js
      ├── angular.min.js
      ├── es5-shim.min.js
      └── json3.min.js
   └── app.js
├── styles
   └── ...
└── views
    ├── main.html
    └── ...



  • One should try and place the <script> tag including the angular.js and related angular scripts at the bottom of the page to improve the app load time. This is because the HTML loading would then not be blocked by loading of angular.js and related scripts.


  • Complex javascript code should be made as a method in the controller (added as a method to the $scope) and then, should be called from the view. This is unlike putting the complex Javascript code as Angular expressions, right, in the view.


  • With real applications, one should avoid creating controllers in the global scope. Rather, one should use “.controller” method of the Angular Module to work with $scope object. Take a look at the sample code below illustrating this point:

Controller defined in the Global Scope:

function HelloController( $scope ) { 
      $ = "Guest";
  • The controllers should only be used to setup initial state of the $scope object and add one or more behaviour to this object. One should avoid using controllers to do some of the following:
    • Manipulate DOM,
    • Format input,
    • Filter output,
    • Share code or state across different controllers
    • Manage the life-cycle of other components (for example, to create service instances)
  • A controller should contain only the business logic needed for a single view. The functionality should rather be moved to services and these services should be injected into the controllers using dependency injection.
  • The recommended way to declare the controller function is to use the array notation such as following because it protects against minification.

Controller defined using “.controller” method (Recommended way)

var helloApp = angular.module( "helloApp", [] ); 
helloApp.controller( "HelloController", function($scope){ 
$ = "Guest"; 


  • While writing unit tests for controllers, one of the recommended ways is to inject $rootScope & $controller. Take a look at the sample unit tests on this page: The following is the sample code representing injection of $rootScope and $controller objects.
    function( $rootScope, $controller ){ 
    scopeMock = $rootScope.$new(); 
    $controller( 'CompanyCtrl', {$scope: scopeMock} ); 


  • One should prefer using the dash-delimited format (e.g. ng-model for ngModel). While working with an HTML validating tool, one could instead use the data-prefixed version (e.g. data-ng-model for ngModel).
  • Prefer using directives via tag name and attributes over comment and class names. Doing so generally makes it easier to determine what directives a given element matches.
  • While creating directives, it is recommended to prefix your own directive names to avoid collisions with future standard.


  • With large templates (HTML content with Angular directives) within an HTML file, it is recommended to break it apart into its own HTML file and load it with the templateUrl option.

Dependency Injection

The preferred way of injecting the dependencies is by passing the dependency to the constructor function rather than using one of the following other ways. In this way, the responsibility of creating the dependency object lies with other objects or function. This is straight forward for those who have worked with one or more dependency injection framework in the past. However, this could be useful information for the beginners. Following are other ways of doing dependency injection in Angular:

  • Create it using the new operator.
  • Look for it in a well-known place, also known as a global singleton.
  • Ask a registry (also known as service registry) for it.

Also Refer :



Always use Restangular instead of $resource or $http

Advantages of Restangular over $http

  • It uses promises. Instead of doing the “magic” filling of objects like $resource, it uses promises.
  • You can use this in $routeProvider.resolve. As Restangular returns promises, you can return any of the methods in the $routeProvider.resolve and you’ll get the real object injected into your controller if you want.
  • It doesn’t have all those $resource bugs. Restangular doesn’t have problem with trailing slashes, additional : in the URL, escaping information, expecting only arrays for getting lists, etc.
  • It supports all HTTP methods.
  • It supports ETag out of the box. You don’t have to do anything. ETags and If-None-Match will be used in all of your requests
  • It supports self linking elements If you receive from the server some item that has a link to itself, you can use that to query the server instead of writing the URL manually.
  • You don’t have to create one $resource object per request. Each time you want to do a request, you can just do it using the object that was returned by Restangular. You don’t need to create a new object for this.
  • You don’t have to write or remember ANY URL. With $resource, you need to write the URL Template. In here, you don’t write any urls. You just write the name of the resource you want to fetch and that’s it.
  • It supports nested RESTful resources. If you have Nested RESTful resources, Restangular can handle them for you. You don’t have to know the URL, the path, or anything to do all of the HTTP operations you want.
  • Restangular lets you create your own methods. You can create your own methods to run the operation that you want. The sky is the limit.
  • Support for wrapped responses. If your response for a list of element actually returns an object with some property inside which has the list, it’s very hard to use $resource. Restangular knows that and it makes it easy on you. Check out
  • You can build your own URLs with Restangular objects easily. Restangular lets you create a Restangular object for any url you want with a really nice builder.

$http – $http is built into Angular, so there’s no need for the extra overhead of loading in an external dependency. $http is good for quick retrieval of server-side data that doesn’t really need any specific structure or complex behaviors. It’s probably best injected directly into your controllers for simplicity’s sake.

$resource – $resouce is good for situations that are slightly more complex than $http. It’s good when you have pretty structured data, but you plan to do most of your crunching, relationships, and other operations on the server side before delivering the API response. $resource doesn’t let you do much once you get the data into your JavaScript app, so you should deliver it to the app in its final state and make more REST calls when you need to manipulate or look at it from a different angle. Any custom behavior on the client side will need a lot of boilerplate.

Restangular – Restangular is a perfect option for complex operations on the client side. It lets you easily attach custom behaviors and interact with your data in much the same way as other model paradigms you’ve used in the past. It’s promise-based, clean, and feature-rich. However, it might be overkill if your needs are basic, and it carries along with it any extra implications that come with bringing in additional third-party dependencies.

Angular JS Dynamic searching for a collection of objects, with min & max range (i.e., persons with age from 18 to 60)


<div ng-repeat=”car in cars | filter: byRange(fieldname, min_value, max_value” >





$scope.byRange = function (fieldName, minValue, maxValue) {
if (minValue === undefined) minValue = Number.MIN_VALUE;
if (maxValue === undefined) maxValue = Number.MAX_VALUE;

return function predicateFunc(item) {
return minValue <= item[fieldName] && item[fieldName] <= maxValue;

That’s it just pass in the field name, min_value and max_value to the ‘byRange’ function and get the dynamic searching for collection of objects.

Adding custom filters on active admin using Ransacker

Scenario for below code…
Customer placing orders for a several line items of a vendor in a shopping website..
Tables : Order (has many line items)
line item (belongs to vendor)

Following is the code for filter by vendor on order’s page (Note: order table is not directly related with vendor, there can be multiple vendors involved on a single order. Order table does not have vendor_id and similarly vendor table not having order_id. But line_items table have order_id and vendor_id stored, so this needs to customized at it’s best)

filter :vendor_in,
:as => :select,
:label => ‘Vendor’,
:collection => proc {{ |vendor| [vendor.username,] }.uniq }

ransacker :vendor,
formatter: proc { |selected_vendor_id|
results = Order.has_vendor(selected_vendor_id).map(&:id)
results = results.present? ? results : nil
}, splat_params: true do |parent|

# Executes the query which fetches the orders of selected vendor
def self.has_vendor(vendor_id)
self.joins(:line_items).where(“line_items.vendor_id = ?”, vendor_id).uniq

That’s it you are done!