DEV Community: Shakil Ahmed

Understanding TypeScript Decorators

Shakil Ahmed — Fri, 16 Apr 2021 17:49:53 +0000

Decorators are used to modify classes and its members (methods, properties).

The question may be, why do we need decorators to change those things? Why not directly change in the declarations?

Directly changing is not scalable. If you need the same changes in 100 classes, you have to write it 100 times. Using decorators, you write it once and apply it as many times as you want.

Decorators give you a central point of change which easier to work with. Frameworks like NestJS, Angular use decorators extensively.

In TypeScript, you can decorate the following things:

class
method
property
accessor
parameter

Decorators are a TypeScript feature and are not officially included in JavaScript yet. However, they are likely to be added in the future (Currently in stage 2).

Class decorator

// The following decorator makes any class more Funky
function makeFunky(target: Function) {
    return class extends target {
        constructor() {
            super()
        }
        funkIt() {
            console.log("Get The Funk Outta My Face")
            }
        }
    }
}

@makeFunky
class Car {
    wheels = 4
    state = 'pause'
    drive() {
        this.state = 'running'
    }
}

const car = new Car()
car.funkIt()
// logs: Get The Funk Outta My Face

Decorators are just functions, makeFunky is the decorator above. makeFunky gets the class Car it's applied to as a parameter. It returns a new class which is just a modified version of the original class.

Decorators are called when the class is declared—not when an object is instantiated.

Method decorator

Decorators applied to a method gets the following parameters

target : for static methods, target is the constructor function of the class. For an instance method, target is the prototype of the class.
propertyKey : The name of the method.
descriptor : The Property Descriptor for the method

function log(target: Object, propertyKey: string, descriptor: PropertyDescriptor) {
    const originalMethod = descriptor.value
    descriptor.value = function () {
        console.log('arguments are ', arguments)
        const result = originalMethod.apply(this, arguments)
        console.log(`result is ${result}`)
        return result
    }
}

class Calculator {
    @log
    add(x: number, y: number): number {
        return x + y
    }
}

const calc = new Calculator()
calc.add(10, 20)

/*
[LOG]: "arguments are ",  {
  "0": 10,
  "1": 20
} 
[LOG]: "result is 30" 
*/

Property decorator

Similar to method decorator. Gets the same parameters target, propertyKey, and descriptor as the method decorators. Its return value is ignored.

function logMutation(target: any, key: string ) {
    var _val = target[key]
    Object.defineProperty(target, key, {
        set: function(newVal) {
            console.log('new value is ' + newVal)
            _val = newVal
        },
        get: function() {
                return _val
            }
        })
}

class Person {
    @logMutation
    public age: number

    constructor(age: number) {
        this.age = age
    }
}

const jack = new Person(20)
jack.age = 40

/*
[LOG]: "new value is 20" 
[LOG]: "new value is 40" 
*/

Accessor and parameter decorators

Accessor decorators are same as method decorators, but they are applied to either the getter or setter method of a single member.

Parameter decorators are applied on, you got it, parameters.

Decorator Factory

A common pattern in decorator usage is calling a function that returns a decorator. Here's the previously mentioned method decorator log , returned by invoking the function logger

function logger(functionName: string) {
    function log(target: Object, propertyKey: string, descriptor: PropertyDescriptor) {
        const originalMethod = descriptor.value
        descriptor.value = function () {
            console.log('method name: ' + functionName)
            console.log('arguments are ', arguments)
            const result = originalMethod.apply(this, arguments)
            console.log(`result is ${result}`)
            return result
        }
    }
    return log
}

class Calculator {
    @logger('add')
    add(x: number, y: number): number {
        return x + y
    }
}

const calc = new Calculator()
calc.add(10, 20)

/*
[LOG]: "method name: add" 
[LOG]: "arguments are ", {
  "0": 10,
  "1": 20
} 
[LOG]: "result is 30" 
*/

Decorator in the wild

Some use cases of decorators as being utilized by popular libraries/frameworks.

NestJS uses the class decorator @Controller('pathName') to define a class as a controller. Decorators associate classes with required metadata and enable Nest to create a routing map (tie requests to the corresponding controllers). It also uses decorators to define modules, injectable instances for its dependency injection system.
TypeORM uses decorators to define a class as an entity @Entity(), tagging properties as columns @Column(), auto-incremented ID etc.
The NPM package class-validator is used for validating properties in an object (used in validations such as income data, arguments of a function). It has decorators like @IsInt() @Min(5) @Max(25) to set restrictions on a particular field.

Unit testing is more important than you think

Shakil Ahmed — Sun, 11 Apr 2021 02:23:00 +0000

The most important benefit unit testing gave me is being able to make changes without fearing things might blow up due to even a small change. The whole process of Software development is dealing with complexity where each new step creates a brand new tangle in the already existing fuck sandwich of a stack.

For smaller projects, you may get away okay without writing unit tests. But in a decent sized project with more than one developer involved, it's a must if you want to keep your sanity intact.

As engineers, all we do is making things that reduce human effort. So why hurt your brain thinking about whether your current changes will break another feature? leave it to the software to test. Unit testing is testing your function as a small unit of your entire app. Besides making sure your function is working properly, this practice has some beneficial side effects as well.

Superior error handling

The difference between a good and bad software is that the former handles errors better. When you write code with tests in mind, you know there will be test cases that provide invalid data or invoke the function with incorrect parameters and expect it to throw certain errors. Having tests in mind will automatically force you to write better code and deal with different types of errors in proper way.

Another way it helps you handle errors better is you can copy test cases for similar features from open source projects. For example, if your code deals with http requests, you can find the test cases commonly used on network requests and add those to your code. Why reinvent the wheel?

Better reasoning about the software

Test driven develoment is overall a better strategy of software development in my opinion. Thinking about your code in this approach gives a clearer picture.

How to choose a mechanical keyboard

Shakil Ahmed — Thu, 25 Mar 2021 10:41:03 +0000

Mechanical keyboards are fantastic. It's one of the few ideas that were replaced by worse alternatives. Lightweight webpages have been replaced by bloated junks, fast desktop apps have been replaced by chromium wrappers made with electron. Awesome mechanical keyboards have been replaced by subpar rubber dome keyboards. Good thing is, mechanical keyboards are gradually making a comeback. There are more and more enthusiasts out there. Me being one of them.

Enough with the prelude! Tell me what should I consider while buying a mechanical keyboard.

I'm glad you asked. While buying a mechanical keyboard, there are 2 primary things to keep in mind. What switch type do you want and what keyboard size do you want.

Mechanical keyboard switch types

Since switches in a mechanical keyboard are the most important part of the keyboard's typing experience, I'm going to focus on it first.

Mechanical keyboard switches traditionally come in 3 types; clicky, tacticle, and linear. For easier referencing, they are denoted by certain colors. Clicky ones are called blue switches, tactile ones are called brown switches, and liner ones are called red switches.

Blue switches

MX Blue switch manufactured by Cherry

Blue switches are the most satisfying switches. They give a click sound along with the tactile feedback. Many people including me are a fan of the sound.

However, they are really loud. My mechanical keyboard with blue switches used to keep the whole neighborhood awake until late night. When I typed fast, it vibrated the room with brilliant explosions of light, sound, and energy. The switches were quite satisfying, but the people around me thought otherwise, giving it the nickname ' the machinegun'.

If there are people around you, don't buy a keyboard with blue switches. Get the blue switches only if you work alone and have decent noise isolation in your room.

Red switches

They need less pressure (actuation force) than the blue switches on a keypress. Red switches are linear switches having no tactile or sound feedback at all. Since they need less force for a press, they are popular particularly among gamers and touch typists. These switches are quiet and produce very little noise making them usable in office environments.

Brown switches

Brown switches are a middle-ground between the loud blue switches and quiet red switches. They provide a tactile feedback without creating much noise. Most typists prefer this switch over the others. I'm currently using a keyboard with brown switches as my daily driver and the experience is pretty good. It's not as great as the blue switches IMO, but there are no complaints from neighbors anymore.

Mechanical keyboard size

The keyboards in several form factors, named after how many keys they contain.

Full size keyboards

We all have used this keyboard size. One thing to note here is it contains 2 sets of numerical keys. One on the top of alphabets, the other is on the side of the keyboard. If you are someone who inputs numbers a lot, you may find the the extra keyboard on the side quite handy.

Full size keyboard layout

TKL (Tenkeyless) size keyboards

Redragon Kumara k-552 (TKL layout)

I don't need the extra number pad found on the full size keyboards. That's why I prefer TKL over the full layout. It's smaller in size without sacrificing any functionality.

70%-75% keyboards

RK71 keyboard (70% layout)

They retain only the essential keys. Some non-essential keys may not be present depending on the layout. For example, the above 70% keyboards do not have dedicated function keys. Function keys are accessed by pressing fn + number

60% keyboards

This layout is very compact and gaining in popularity lately. I personally don't prefer it since I use the navigation keys like Del, PgUp, PgDn a lot.

Note that you will be able to access all the standard keys that you do not see on the layout by pressing different combinations.

For more information regarding mechanical keyboards or to participate in discussions, check out this subreddit: https://www.reddit.com/r/MechanicalKeyboards/

Disclaimer : The information and the lists on this post are in no way exhaustive. I have intentionally left out other not-so-common switch types and layouts.

Focus on one thing for longer

Shakil Ahmed — Fri, 19 Feb 2021 12:42:47 +0000

I read on a book that said “When you desperately want something, the universe conspires to make it happen”. This sentence is about perseverance, not desire. Focusing on something for a long time is a reflection of perseverance.

Focused work gives better return

The difference of results between continuous attention and fragmented attention over a period of time is significant. With fragmented attention you will only get a superficial idea of the subject. It takes time for a mind to be submerged into something.

Some works are not doable without attention

It’s true you can a lot of work without much attention. Logistical tasks such as filling up a form or making powerpoint presentation of the sales figures do not have to be meditative.
But solving creative problems require intense attention. Works like fixing a complex bug in code, editing a research paper, writing a persuasive business proposal demand time and concentration.

Focused work is insightful

Immersing into a task gets us something else other than just getting it done. It provides insights. Insight come from deep concentration, it makes you question the why of things rather than how.

To be light is to lose one’s root. To be restless is to lose one’s mastery.
— Tao Te Ching

Unit testing is more important than you think

Shakil Ahmed — Tue, 14 Aug 2018 18:00:00 +0000

For smaller projects, you may get away okay without writing unit tests. But in a decent sized project with more than one developer involved, it's a must if you want to keep your sanity intact.

Better reasoning about the software

Test driven develoment is overall a better strategy of software development in my opinion. Thinking about your code in this approach gives a clearer picture.