Debounce And Throttle in Javascript

The greatest concern faced by UI developers is the performance issues in situations where functions are being executed excessively and in some cases unnecessarily


There are two ways in order to control the execution of functions using Debounce and Throttle, which come in handy when on handling events such as mouse scroll or window resizing.

A simple explanation of debounce and throttle is that the number of times a function is executed over a period of time is throttle and the time passed between each execution of a function is implemented as debounce.

 

Real Time Example:

Debounce: The perfect example for debounce would be resizing of the window in a desktop. Imagine we are to get the value of the screen size, but it would be useless to execute the function as the user drags on the size of the screen but we would be interested only in the final value of the screen size after it has been resized, as explained in the link(https://css-tricks.com/debouncing-throttling-explained-examples/)

debounce

Throttle: An example of throttle can be explained through the infinite scroll, where we have to determine the scroll position and load data before the user reaches the bottom. In this case, it wouldn’t be advisable to use debounce, as it would allow us to call the function only after the user stops scrolling. But throttle would ensure that we constantly check how far is the user from the bottom and act accordingly.

throttle

The major advantage of throttle over debounce is that we have the option to store ignored executions and execute them at last after all the function calls are made

Implementation:

A code sample for implementation of debounce

//original code from  Jhey Tompkins blog

//https://medium.com/@_jh3y/throttling-and-debouncing-in-javascript-b01cad5c8edf

var debounce = function(func, delay) {

var inDebounce = undefined;

return function() {

  var context = this,

    args = arguments;

  clearTimeout(inDebounce);

  return inDebounce = setTimeout(function() {

    return func.apply(context, args);

  }, delay);

}

}

 

The above function could be linked to a click event as follows:

 

debounceBtn.addEventListener(‘click’, debounce(function() {

return console.log(‘Hey! It is’, new Date().toUTCString());

}, 3000));

 

In the above code, when the button click event is called the function gets executed with the delay of 3 seconds, but if another click event is triggered before the execution of first click, then it is replaced by the second event.

 

Similarly, a code implementation for throttle would be

 

//original code from comment of maninak

//https://gist.github.com/makenova/7885923

function throttle(func, msWait) {

var time = Date.now();

return function() {

if ((time + (msWait || 100) – Date.now()) < 0) {

func();

time = Date.now();

}

}

}

Can be used as:

window.addEventListener(‘scroll’, throttle(myOnScrollFunction), false);

The above code ignores execution of the function for the events that are being called within 100ms of execution of the previous function call.

Conclusion:

Debounce and Throttle are techniques used to optimize the event handling.Both throttling and debouncing will rate-limit execution of a function.

In Summary:
Debounce will bunch a series of sequential calls to a function into a single call to that function. It ensures that one notification is made for an event that fires multiple times.

Throttle will delay executing a function. It will reduce the notifications of an event that fires multiple times.

References:
1.https://css-tricks.com/debouncing-throttling-explained-examples/
2.https://medium.com/@_jh3y/throttling-and-debouncing-in-javascript-b01cad5c8edf
3.https://gist.github.com/makenova/7885923

4.https://stackoverflow.com/questions/25991367/difference-between-throttling-and-debouncing-a-function

5.http://reactivex.io/documentation/operators/debounce.html#collapseRxNET

6.http://reactivex.io/rxjs/class/es6/Observable.js~Observable.html#instance-method-throttleTime

 

AngularJs SEO with Prerender.io

Built a beautiful, snappy, user-friendly website using AngularJS, and now you want more users to start browsing it. But, AngularJS which fully embraces the asynchronous model creates problems for Google’s crawlers and this is how the google indexes an angularJs sites:

Angular Seo

Obviously, this is not what you want your users to view. Now what do we do?

What to do?

Thought a lot 🙄 but still no success???? 🙁

Nevermind 🙂 , here’s how to get your site to the top of the search results.

Lets start  by setting up your prerender server :

1.git clone https://github.com/prerender/prerender.git. Then cd Prerender, to go to the directory
2. npm install Instal module dependencies
3. node server.js Run the service (available nohup node server.js & so that it runs in the background)

Client Side: Follow Google’s Javascript crawling protocol with hashbang

For reference, the full protocol is here.

Google’s Javascript crawling protocol is meant for websites that render using Javascript or need to wait on AJAX calls to complete. If you follow Google’s protocol, Google will send a request to your server with a modified url so that you can return the static HTML version of the page rendered by prerender server. Here’s how:

If you use urls with #

Nothing after the hash in the url gets sent to your server. Since Javascript frameworks originally used the # as a routing mechanism, that’s the main reason why Google created this protocol.

Change your urls to #! instead of just using #.

angular.module('exampleApp').config([  
    '$locationProvider',
    function($locationProvider) {
        $locationProvider.hashPrefix('!');
    }
]);

Google looks for #! urls and then takes everything after the #! and adds it as a query parameter called _escaped_fragment_. That way, Google effectively fixes the problem of everything after the hash not being sent to your server.

Google finds urls like this:

http://www.example.com/#!/product/123

Google sends a request to your server like this:

http://www.example.com/?_escaped_fragment_=/product/123

, intercept the request on the nginx server like this (imagine the prerender server resides on port 3000 whereas your backend server on port 4000) :

server {
 listen 80;
 server_name www.example.com example.com;
 location ~* / {
   set $prerender 0;
   if ($http_user_agent ~* "baiduspider|
       twitterbot|facebookexternalhit|
       rogerbot|linkedinbot|embedly|
       quora link preview|showyoubot|
       outbrain|pinterest|slackbot") {
   set $prerender 1;
 }
 if ($args ~ "_escaped_fragment_") {
   set $prerender 1;
 }
 if ($uri ~ "\.(js|css|xml|less|png|jpg
     |jpeg|gif|pdf|doc|txt|ico|rss|zip|
     mp3|rar|exe|wmv|doc|avi|ppt|mpg|
     mpeg|tif|wav|mov|psd|ai|xls|mp4|m4a|
     swf|dat|dmg|iso|flv|m4v|torrent)") {
   set $prerender 0;
 }
 if ($prerender = 1) {
  rewrite .*/$scheme://$host$request_uri?break;
  proxy_pass http://localhost:3000;
 }
 if ($prerender = 0) {
   proxy_pass http://localhost:4000;
 }
}

Thats it!

SEO issue solved

Now you’re well on your way to lots of new users, courtesy of the search engines! Good luck  😉

NodeJs Essentials: How to restart your nodeJs server programmatically in the event of a failure

You are excited about your new found love for NodeJs and you start creating an application. You have some REST apis wired up and you are all set to change the world! But for some reason, you have some unhandled error in your code and your nodeJs server crashes! Now you got to restart it to make sure it stays up. Ever crossed this scenario? If so, this is for you.

To demonstrate this, let’s look at the below scenario


http.createServer(function (request, response) {
console.log('Ready to accept request');
response.writeHead(200, {
'Content-Type': 'text/plain',
'Access-Control-Allow-Origin' : '*'
});
response.end('Hello World\n');
}).listen(1337);

This is a very simple http server that sends ‘Hello World’ as a response to the requester. To run this program,

  • Save the code above to a file (e.g. hello-world.js)
  • Go to terminal and locate the file. Run node hello-world.js
  • Access ‘http://localhost:1337’ to see the response on your browser/REST client like below
    NodeJs hello world http server

What a happy world!

Your nodeJs program worked!

Now all is fine, until there is an error in your code and your app crashes! Lets simulate this by the below code. Notice, how I am trying to access a property of variable ‘i’ which is not defined.

var http = require('http');
http.createServer(function (request, response) {
console.log('Ready to accept request');
// This line below is going to break your server!
var j = i.someProperty;
response.writeHead(200, {
'Content-Type': 'text/plain',
'Access-Control-Allow-Origin' : '*'
});
response.end('Hello World\n');
}).listen(1337);

Run this code, and hit the http://localhost:1337 url and you will see that the server fails with the below message.

ReferenceError: n is not defined
at Server. (/Users/srijithradhakrishnan/Desktop/httpServer.js:5:17)
at emitTwo (events.js:106:13)
at Server.emit (events.js:191:7)
at HTTPParser.parserOnIncoming [as onIncoming] (_http_server.js:543:12)
at HTTPParser.parserOnHeadersComplete (_http_common.js:105:23)

So, how do we recover from a failure like this and keep the server running? For this, we could use the cluster module from nodeJs. Here is how it could be used.


var http = require('http');
var cluster = require('cluster');
// The master's job to spawn workers initially and when they die
if (cluster.isMaster) {
// Get the number of processor cores
var cpuCount = require('os').cpus().length;

// Create a worker for each CPU
for (var i = 0; i < cpuCount; i += 1) { cluster.fork(); } // When a worker exits, fork a new one cluster.on('exit', function(worker) { console.log('Worker %d died', worker.id); cluster.fork(); }); } else if (cluster.isWorker) { // The real work here for the worker http.createServer(function (request, response) { console.log('Ready to accept request'); // This will cause the server to crash var i = n.start; response.writeHead(200, { 'Content-Type': 'text/plain', 'Access-Control-Allow-Origin' : '*' }); response.end('Hello World\n'); }).listen(1337); // Exit the process when there is an uncaught exception console.log('Worker %d running!', cluster.worker.id); process.on('uncaughtException', function() { console.log('Handled the exception here'); process.exit(1); }); }

  • Now, run the code.
  • See that the master has spawned as many workers are there are cores in your cpu. So if you have a four code CPU, you should see 4 workers spawned!
  • hit the 'hello world' api, you would see that one of the workers died but was respawned again by the master.

Thus your nodeJs server can live on for eternity!

(ok that was too much, but you get the point!)

What really is Javascript’s Event Loop

All of us know Javascript is a “single-threaded non-blocking asynchronous concurrent language, It has a call stack, an event loop, a callback queue, some other apis and stuffs” . We have also heard about V8 – Chrome’s Javascript runtime engine.

Many of us have known already about Javascript’s Event loop, but for the newbies this must be a good read.

Putting the big picture,

Squashapps-chrome-runtime

Let’s see what happens when this piece of code is executed,


console.log('hi');
setTimeout(function cb() {
console.log('JSC');
},5000);
console.log('how are you');

The result in the console would be,
hi
how are you
JSC

How this code is manipulated in V8 is,

  • When that piece of code is executed, console.log(‘hi’) is pushed onto the stack and “hi” is printed in the console.

Eventloop

  • The next thing is, the timeout function is triggered. The timeout function is not in the stack so a timer is kicked off in the webapis  which will run for 5 secs.

Eventloop-timeout

  • Since the timer is run by the webapi and also the stack is empty, console.log(‘JSC’) is pushed onto the stack and “JSC” is printed in the console.

Eventloop-2

  • After 5 sec, once the timer is done the function is queued up in the task queue

Event loop

  • Here is where the event loop comes into picture, the job of the event loop is to execute the task queue in a FIFO manner only when the stack is empty.

So, you may have a question “What if some process is taking place in the stack and the timeout is done?”  The answer is the timeout function will be put onto the queue and it will wait until the stack is empty, no matter how many seconds timeout you gave.

What do you think will be the output for this code?


for(var i=0; i<1000000000; i++) {
console.log(i);
if(i===0){
setTimeout(function cd() {
console.log('hi');
},2000);
}
}

I was asked the same question by my CEO one day in my office, the next moment i replied
0,1,2,3 and so on and after 2 secs some where in between
‘hi’ and then all the way to
…. 1000000000

But that’s not right, I totally forgot about the event loop. The exact output would be
0,1,2,3, … ….. …… , 1000000000
hi

You may ask me, what if I give a timeout(function(), 0); , even then the timeout function is going to go to the task queue and it should wait until the event loop is triggered and will be triggered  when the stack is empty 😉

“Go through this wonderful presentation by Philip Roberts which was my inspiration”.

Beware of the Event loop!

Happy coding!

How to implement SwiperJs slides with IONIC 1.x using ion-slides

With the release of V1.2, ionic announced the support for SwiperJs with the new directive ion-slides. The older ion-slidebox will be deprecated over the new ion-slides. As there was very less documentation and a lot of developers confused on how to get an instance of the swiper in your controller, I decided to write this blog post.

Here’s the forum where I posted the original answer

AngularJS Controller

 

How to use ion-slides in IONIC
AngularJS Controller


HTML

Screen Shot 2016-07-05 at 11.38.31 AM
HTML part

REFERENCES

  1. It can be made much more extensible. The different options available for
    the swiper like effect, speed ..etc is here (Look under Swiper parameters)
  2. Take a look at the api docs here
  3. Awesome Swiper Demos here
  4. Here’s an example gist

With IONIC 1.2 release’s support of swiper, the mobile hybrid developers could now unleash the power of SwiperJS!

Happy coding!

Top 9 mistakes to avoid for Angular v1 developers

AngularJs has seen a tremendous improvement over the last couple of years. With a strong core team, thousands of supporting modules in the ecosystem and backed by Google, AngularJs is the most favourite UI javascript library currently!

But ‘with great powers comes great responsibilities!‘ More and more developers are flocking to AngularJs everyday and it becomes more important to understand the nuances and code accordingly.  Here are some top mistakes developers make while coding in AngularJs and the steps to avoid them!

  1. Modularity

    Keeps angularjs code modular - By Srijith Radhakrishnan, SquashApps
    Keeps angularjs code modular

    Oh please! Please put stuff where they belong! We all have our tendencies to piece together a quick app for a client demo or something and put all stuff in the controllers. You wont believe me how many times I have seen a controller go beyond 500 lines of code!

    • Use Services/Factories wherever required
    • Directives are meant for DOM related stuff. Use them!
    • Keep a watch on the size of the file. Its sometimes as simple as that. If you think it is getting big, time to refactor!
  2. Overloading the RootScope
    Dont overload the rootscope
    Don’t overload the rootscope

    Lot of us think that rootScope in the angular world is some kind of a goods train and we could load all the stuff we want to on it and it would be delivered at the right spot! (Forgive my analogy!) Hope you get the point. When we want to share information between controllers or other modules, the first thing that comes to the mind is ‘Why not use rootscope!?

    • Well, at first, its all going to be fine
    • Then one day, rootScope is going to be a huge datastore on your client side application
    • This could overload angular’s digest cycle in watching these variables and cause a performance degradation
    • You could argue that the performance hit is going to take a while, but hey! It is going to happen!
    • Check out this wonderful explanation on SO about this
  3. Too many watchesDont have too many watches in AngularJSKind of relates to my previous point. Watch is usually used to ‘watch’ a variable and do operations when its value changes. The problem is that ‘watch expressions’ are run multiple (!) times during angular’s digest cycle. Boils down to a simple math. If 1 watch expression is triggered multiple times during a digest cycle, just imagine the performance hit that an app with 100 watch expressions takes!
  4. Broadcasting (events) like a radio station!
              There may be scenarios where broadcasting an event is the right way to go. But sometimes, we tend to solve the problems in the easiest way. After all, we are humans. (or are we??) . If there is a need to transfer data from modules within the app, you could use a factory, or a location parameter in the url or rootscope (sparingly!) or session/local storages or using controller inheritance (so in your child controller you would just do $scope.$parent.getSomeData())
  5. Cancelling Timeouts/IntervalsThere might be a scenario where you might need to add a $timeout to perform some actions after a stipulated time.
    Although timeouts could be totally avoided, if you really have to deal with them, cancel them after the controller is destroyed. You could listen to the controller’s destroy event like this and cancel the timeouts/intervals you created within the controller

    // Creating a timeout
    $scope.timer = $timeout(function() {
           doSomething();
    }, 1000 );

    // Cancel it when the controller is destroyed
    $scope.$on(‘$destroy’, function (){
        $timeout.cancel($scope.timer);
    });

     

  6. DOM manipulations

    DO NOT absolutely do DOM manipulations in controller. Why?

    • DOM manipulations are slow
    • Controllers are not meant for DOM manipulations!
    • Directives are meant for just that.
    • And if you have a directive for DOM manipulation you could reuse it in any other controller. But you cant reuse it if its within the controller itself
  7. Understanding callbacks
    Understand callbacks before you jump into Angular. A lot of times timeouts have been created for the lack of understanding on callbacks. Take for example this simple scenario

    • You want to call a REST api and get a response
    • Then print something on the html. Simple.WRONG: $http.get(some_URL, function(success){}, function(error){});
      $timeout(function(){
      #Hey it takes 5 secs for the above call to complete. Let me just do a timeout!
      $scope.message  = ‘Call success’;
      }, 5000);Btw, this does not exactly execute in 5 seconds. There will be a blog soon on why! (I know you know it already, but we still want to write about it!)RIGHT : 1)  $http.get(some_URL, function(success){$scope.message = ‘Call success’;}, function(error){$scope.message = ‘Call failed’;});(OR)2) var promise = $http.get(some_URL);
      promise.then(function(success){$scope.message = ‘Call success’;}, function(error){$scope.message = ‘Call failed’;});Read more about promises here and about callbacks here
  8. Dependency Injection
    • We found this the hard way but dont inject dependencies for your angular module like thisBAD app.controller(‘MyController’, function(Dep1, Dep2){
      });GOOD app.controller(‘MyController’, [‘Dep1’, ‘Dep2’, function(Dep1, Dep2){
      }]);ok Why do I have this redundancy? Why are my dependencies first injected as inline array annotations and then as parameters to the controller?
      Simple answer
      : Minification
      Detailed: JS minifiers rename the arguments before minification and then  Angular has no absolute idea of what those arguments are! There are two solutions to this
    • Either follow the implementation in the ‘Good’ section above (or)
    • Use tools like ng-annotate which would automatically do the inline array annotations for you.Read more here
  9. JSHINT (static code anaylis) and Tests!

    JS Linting and TESTS are your friends!
    JS Linting and TESTS are your friends!


    Often times, we ignore these guys as we need to meet that one deadline or go to the market before the other guy does! So much that we forget the good stuff that they bring. I am just going to jot down the advantages

    • JSHINT has caught more bugs than all the fish ever caught in human history (Crazy Analogy again. Forgive!)
    • If you had a friend who would sit with you all day while you code and test all your stuff, would you be happy?
      1. If the answer is YES, Karma is the name! Not the literal meaning, but this awesome test runner
      2. If the answer is NO, you need some socializing 😉(Note: if you have a large inherited codebase with no absolutely no tests, dont go about making that your priority! Of course tests are important but not more than the core business! Allocate may be 20% of your time weekly to write tests for the old code and dont write any new code without tests. Eventually you would be boasting a decent test coverage!)I am planning to do a blog later on how Panitr maintains near perfect test coverage

Following good coding practices not only enriches your knowledge but also helps the future app maintainer to not go mad and file a lawsuit against you 😉