javascript Archives • Modern Web and Mobile Development and more...

Hi there! How are you? I hope you are well!

Well, in the last few days I happened to bump into a very sloppy code in some part of the application I am working on daily: yes, we have code like this! Although, we are trying hard to maintain great quality and test our code it is very difficult to control every part of the app which is distributed among several teams. So, I got a call that we have a bug on that particular part developed by another team etc etc. Dear lord! It was a mess! I wonder how it worked to start with!!

So, here is a small function which wraps webview’s executeScript function:

executeScript(command, callback) { 
  this.win.executeScript({ code: command }, values => { 
    if (values && values[0]) { 
      callback(validateScriptResult(values[0])) 
    } else { 
      callback(values) 
    } 
  }) 
}

Well, here is the thing: if you read about the signature of the function you will see that the second argument is a callback and guess what! Optional! This is ok for the moment, because we wrapped it and we explicitly pass a callback to the this.win.executeScript (this.win is the webview). The problem arises on how we use the wrapped function: we either provide a command only or both command and callback arguments! We also have the callback argument optional! But, wait! We explicitly pass it down the internal function. If we do not pass a callback what happens?

Ops!!

Then again we have the internal callback with values etc… Where on Earth do we pass values there? I think it is the internal values passed there when the code is executed etc etc… So, we call that callback EVERY time… Aha!!

So, I got an error in the console: callback is not a function!

🙁

You know what this means at first glance? Yes, we pass a callback to the upper function which has a wrong type: it is either undefined or an array or I do not know what!!! Most probably undefined!

So, defensively thinking we do the following:

executeScript(command, callback) { 
  if (callback) {
    this.win.executeScript({ code: command }, values => { 
      if (values && values[0]) { 
        callback(validateScriptResult(values[0])) 
      } else { 
        callback(values) 
      } 
    })
  } else {
    this.win.executeScript({ code: command })
  }
}

Not very elegant maybe (some other dev proposed inline ternary on the argument etc.) but I really like it: it is super readable and conveys the message to a fellow developer of the callback being optional!

Another case

Lately, especially after TDD writing tests I found a lot of small uncaught things like the following.

In a React component we had a piece of code like this:

const { someProp } = this.props

and then after this,

if (someProp.property)

What is the problem with this check? It is very subtle to distinguish it at first sight!

The problem is that we are certain that we have an object there, which property or method we can freely call anytime we want! Boom! someProp can be undefined and guess what! It WAS in that particular case… for some inexplicable reason.

So, now every time I call a method in a check, I FIRST check if the object exists!! Simple as that….

if (someProp && someProp.property)

to avoid sky falling in our heads!!

Problems of this approach

When coding like this, we lose the information an exception can provide, e.g. for the first case we have a callback that is not working properly somewhere in the application and we know it because it raises the error. If we put the check there we get no info of this! On the other hand, if we had tested and coded that callback correctly we would not have crashed the system like this in the first place!

Like always, I think there is a tradeoff and a choice you need to make on how to handle errors and how to safeguard your code! A subtle bug now can break things (or maybe not) later on… But when it breaks them you need to make sure it does not halt the system to pause!

Until next time…

Cheers

PS: after I finished this post I searched for defensive programming! Well, what do you know! I am on point!

https://en.wikipedia.org/wiki/Defensive_programming

During this awesome lesson by Hack Reactor at Udacity, it happened that I had several revelations about the JavaScript language itself!

Prototype chains

Supposing the we have an object obj with a property prop. When we want to create a new object called obj2 which inherits all properties and methods from obj we have to use this method of the Object prototype: Object.create(obj)

This way the two objects are connected with each other!

See the gist below for a simple demonstration of this delegation.

Eventually, all objects in JavaScript delegate all failed lookups to the higher level prototype which is Object.

I had some time ago one of the most, probably THE most exciting and nice job interview in my whole life!

Near the end of the interview I had to solve some interesting JS problems.

One of them was to write a function which validates both of these:

console.log(sum(2,3));

console.log(sum(2)(3));

The solution is this:

function sum(a,c) {

   if (c !== undefined) {

       return a + c;

   }

   return function(b) {

         return a + b;

    } 

}

If you ask me, this is a really nice little exercise!!

The second one was a for loop like this:

for (var i = 0; i < 5; i++) {

    setTimeout(function() {console.log(i);}, i * 1000);

}

This exercise had to be implemented in order to print i like this:

The solution?

Using ES6 change var to let. Or, use a closure like this:

for (var i = 0; i < 5; i++) {

    (function(a){
        setTimeout(function() {console.log(a);}, a * 1000);
    })(i);

}

This had to implement block scope! Nice huh?

PS: Thank you Nicolas for the most interesting interview ever! He used a tool like this here: https://coderpad.io! Super cool stuff!

UPDATE: Of course, I did not pass to the next round, I blew it somehow! But, I earned an important insight out of this interview! I NEED TO STUDY JS MORE. Pure JS that is… no frameworks, no libraries! Yep! Lesson learnt!

M	T	W	T	F	S	S
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

Tag: javascript

Defensive coding

Another case

Problems of this approach

About JS prototype

Prototype chains

JavaScript inquiries

Categories

Tag cloud

Recent posts

What I learnt from developing a Slack app: part 2

2021 new year's resolutions

What I learnt from developing a Slack app: part 1

How to test login with Cypress and CircleCI in a secure way

2020's year resolutions