Forem: Tasnim Reza

3 ways to handle Async/await error.

Tasnim Reza — Fri, 24 Apr 2020 08:38:33 +0000

When comes to asynchronous operation, we always think about JavaScript Promise methods right? But there are other ways we can sort this out. I found the most profound way is async/await. async is used when we are writing any asynchronous operation and await is used when we are waiting for that asynchronous operation.

const getPersons = async () => {
    // we are making the actual database ie REST api call
    return fetch('persons');
}

const process = async () => {
    // we are waiting for persons
    const persons = await getPersons();
    console.log(persons);
}

There are a number of ways we can handle errors in JavaScript. In this article, we'll talk about the 3 most used ways to handle async/await error.

1. Promise.catch

We know we can use promises with async. We'll add a catch block with the asynchronous method.

const getPersons = async () => {
    return fetch('http://person')
        // here we added a promise catch method
        .catch(error => {
            //TypeError: Failed to fetch
            console.log(error);
        });
}

const process = async () => {
    const persons = await getPersons();
    console.log(persons); // undefined
}

process();

This way we can handle unhandled promise rejection error. But the downside of this approach is we have to add a catch method for each asynchronous operation.

2. A wrapper of Promise.catch

We can create a wrapper function so that we don't need to add the catch method of each asynchronous operation.

const asyncWrapper = async (promise) => {
    return promise.catch(error => {
        console.log(error); //TypeError: Failed to fetch
        return error;
    });
}

const getPersons = async () => {
    return asyncWrapper(fetch('http://person'));
}

const process = async () => {
    const persons = await getPersons();
    console.log(persons); //TypeError: Failed to fetch
}

process();

It is better hah? So, what we did here? We extract the catch method from getPersons to asyncWrapper. We handle the error inside the wrapper and return the error to the outside to show some error message to the user.

In this approach there are slight difficulties, each and every time we have to check, there is a valid person or not? This is tedious and there is no clear way to know that there is an error. We can solve this problem

const asyncWrapper = async (promise) => {
    return promise
        .then(result => [null, result])
        .catch(error => [error]);
}

const getPersons = async () => {
    return asyncWrapper(fetch('http://person'));
}

const process = async () => {
    const [error, result] = await getPersons();
    console.log(error, result); //TypeError: Failed to fetch, undefined
}

process();

This is way better right? Here we use JavaScript destructing pattern. We add a .then method and return the success case as [null, result]. That means, if your asynchronous operation is successful, it will return the result where the error is null

On the other hand, we returned [error] means the result is undefined. It is other way around, when error is present there is no result and when the result is present there is no error! In this pattern, we clearly know when an error happened.

3. Promise.allSettled

We know Promise.allSettled is very powerful method where it shows the reason why your asynchronous operation is failed. If you want to learn more, check this article

https://dev.to/tasnimreza/3-most-powerful-javascript-promise-methods-2g8f

const asyncWrapper = async (promise) => {
    const [result] = await Promise.allSettled([promise]);
    return result;
}

const getPersons = async () => {
    return asyncWrapper(fetch('http://person'));
}

const process = async () => {
    const { reason, value } = await getPersons();
    console.log(reason, value); //TypeError: Failed to fetch, undefined
}

process();

We use Promise.allSettled inside the wrapper and await to finish the job. When the asynchronous operation is finished, it destructing the result to the result array. Because Promise.allSettled always return array.

Finally we use object destructing to receive the result. As we know Promise.allSettled return status, reason, value. Here we ignore the status because it is not needed.

When the asynchronous operation is failed, reason is present and value is undefined. If the call is successful, value is present and reason is undefined. In this way we clearly know when the error is present.

Note: There is a common way to handle error in JavaScript is using try...catch I skip this because it is quiet well known pattern.

Summery

Thanks for reading and I hope you learn something from this article. If you have any question please let me know in the comments. I hope your code will be much better after using any of these pattern!

3 most powerful JavaScript Promise methods

Tasnim Reza — Mon, 20 Apr 2020 07:56:03 +0000

A Promise is an Object that is used to return a deferred computation. Mostly the deferred computation is asynchronous operation. The function that return a promise, we can attach success and failure callback. For example

fetch('url')
.then(successCallback,failureCallback)
.then(...)
.catch(...)
.finally(...)

In this article, we'll learn 3 most used promise methods.

1. Promise.all

The Promise.all ( iterable ) method returns a new promise object, that fulfils when all the promises passed or any first one is rejected. This method is useful when we need to handle multiple promises.

Imagine a scenario, where we want to make black coffee. We need coffee beans, coffee mate and fresh water. We send 3 request to collect these ingredients. We can make request one after another then it'll take longer time. The efficient way will be if we can make the requests parallel and a way to know when all the requests are finished. Here comes Promise.all

let collectBeans = fetch('bring me Kopi Luwak');
let collectMates = fetch('French Vanilla');
let collectWater = fetch('fresh tubewell water');

Promise.all([
  collectBeans,
  collectMates,
  collectWater])
  .then(ingredients => console.log('make coffee'),
    ohNoo => console.log('I´m sorry'));

Promise.all will make sure that all the asynchronous jobs are resolved. If any of them is failed the whole process will be failed. For example if collectBeans failed then Promise.all doesn't care about other two requests. This is the downside of Promise.all

const promise1 = Promise.reject('rejected');
const promise2 = 42;
const promise3 = new Promise((resolve, reject) => {
    setTimeout(resolve, 100, 'foo');
});

Promise.all([promise1, promise2, promise3])
    .then(
        values => console.log(values),
        reason => console.log(reason) // rejected
    );

In this example promise1 is rejected so entire chain is failed. Promise.all is useful when we need to wait for multiple works but the works are not depended to each other.

2. Promise.allSettled

The Promise.allSettled( iterable ) also takes an array of asynchronous job and return a promise object. The promise will be resolved regardless of any rejection. This is the only difference with Promise.all. Promise.all fails if any one is failed.

const promise1 = Promise.resolve(3);
const promise2 = new Promise((resolve, reject) => setTimeout(reject, 100, 'foo'));

Promise.allSettled([promise1, promise2]).
    then(results => console.log(result));

/*
[
    {
        status: "fulfilled",
        value: 3
    },{
        status: "rejected",
        reason: 'foo'
    }
]
*/

In this example, we see promise2 is rejected but the returned promise is resolved with status.

This method is useful, when we need to wait for multiple parallel asynchronous job and they all need to be satisfied (resolve/rejected). This method is useful for REST Api health check.

3. Promise.race

The Promise.race (iterable) is also takes an array of asynchronous job and return a promise object. The promise will be resolved as soon as first resolve of reject happens. When any of the passed promise is resolve or reject, we get the output immediately.

const promise1 = new Promise((resolve, reject) => {
    setTimeout(resolve, 500, 'one');
});

const promise2 = new Promise((resolve, reject) => {
    setTimeout(resolve, 100, 'two');
});

Promise.race([promise1, promise2]).then(value => {
    console.log(value); //two
});
// Output is:
// "two"
// because promise2 is faster

If any of them is reject the output will be the same

const promise1 = new Promise((resolve, reject) => {
    setTimeout(resolve, 500, 'one');
});

const promise2 = new Promise((resolve, reject) => {
    setTimeout(reject, 100, 'two');
});

Promise.race([promise1, promise2]).then(value => {
    console.log(value); // this is never called
}, reason => console.log(reason)); // two

// Output is:
// "two"
// because promise2 is faster

This method is useful, when we need to wait for multiple asynchronous job but we are happy as soon as any of them resolve of reject. For lottery house or broker shop we can use this method.

Summery

Thanks for reading and I hope you learn something from this article. If you have any question please let me know in the comments.

Angular Dependency Injection 101

Tasnim Reza — Fri, 10 Apr 2020 19:56:11 +0000

Dependency Injection is a design pattern. Every framework has its own way of implementation. Angular has its own way, they called it DI Framework. In this article I'll walk you through the basics of Dependency injection.

Dependency Injection coined by two words, Dependency and Injection.

Dependency Injection

To understand Dependency lets consider an example I want to eat Swedish meatball. Before eating I have to have the meatball right? What are the ways we can have it

I can make it myself with raw ingredients.
I can buy frozen meatball and cook it.
I can order it from nearby restaurant.
I can hire a Sheff who'll prepare it either from my kitchen or somewhere else.

Let's consider the first case "I'll make it myself"

class SwedishMeatballMaker {
  constructor(private ingredientProvider: IngredientProviderService){}

  private collectRawIngredients(){
    return this.ingredientProvider.getRawIngredients();
  }

  private prepareIngredients(){
    const rawIngredients = this.collectRawIngredients();

    const cookableIngredients = rawIngredients + "prepare to be cookable";
    return cookableIngredients;
  }

  public cook(){
    const cookableIngredients = this.prepareIngredients();
    const meatball = cookableIngredients + "Put on the oven";
    return meatball;
  }
}

You see the whole making process is dependent on IngredientProviderService without having proper provider the meatball will not be Yummy! This is called Dependency.

The second term is Injection To understand this, lets consider the previous example. Now we want to have the meatball in our hand right? What are the ways to have it on hand?

Manage the Ingredient Provider by yourself.
Look for the good provider in the Internet.

So looking at the internet and contact them with proper information(what type butter, what type onion, what type milk, what type egg and so on... it requires a long list actually :P ); So this process is called Injection.

No one wants to manage it by themselves, it is a hell lot of pain right? In the same way if you want to build a robust, flexible enough, testable, scalable and maintainable in a long run App then you need a solid DI framework.

In the Injection process they need to know the service is Injectable?

Injectable Service

Injectable Service is a class which is annotated by @Injectable() decorator (https://www.typescriptlang.org/docs/handbook/decorators.html) or it is declared in the provider array in component or module

@Injectable()
class IngredientProviderService {}

//or declared in the component's provider array
@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss'],
  providers: [IngredientProviderService]
})
export class AppComponent {
    //....
}

//or declared in the module's provider array
@NgModule({
  declarations: [AppComponent],
  imports: [BrowserModule],
  providers: [IngredientProviderService],
  bootstrap: [AppComponent]
})
export class AppModule {
}

This is very simple hah! Yes it is. With the annotation Angular compiler will generate the necessary metadata. In the following figure, we can see the overall picture of different types DI provider.

Metadata

The @Injectable() decorator required some information to provide a good service. So in our example while we're looking at the ingredient provider,they can be different types

Local provider
Nationwide provider
Global provider.
Universal provider

The different provider has different characteristics.

Local provider

Local provider has less responsibility and can be accessible within the community. If we call them from outside of the community they might refuse to provide the service. In Angular context, we can make the injectable class accessible to another component's or class's life cycle. When that component or class is destroyed, the injectable class instance is also destroyed.

//app.component.ts
@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss'],
  providers: [IngredientProviderService]
})
export class AppComponent {
  constructor(private ingredientProviderService: IngredientProviderService) {
    console.log(this.IngredientProviderService.getRawIngredients());
  }
}

//ingredient-provider.service.ts
export class IngredientProviderService {
    public getRawIngredients(){
        return 'raw ingredients';
    }
}

In this example we provide IngredientProviderService in the component provider array. This type of declaration doesn't required any @Injectable() decorator. The instance of IngredientProviderService is available only inside the AppComponent or its children component. Any other component declared in the same module can not access it.

Nationwide provider

Nationwide provider has more responsibility and more accessibility. Different community within the nation can access it and they can make the meatball. In Angular context, a service or class can be accessible within the module.

@NgModule({
  declarations: [MyComponent],
  imports: [],
  providers: [IngredientProviderService]
})
export class MyModule {
}

// or using the @Injectable() annotation
@Injectable({
    providedIn: MyModule
})
export class IngredientProviderService {
    public getRawIngredients(){
        return 'raw ingredients';
    }
}

In this example we used @Injectable() decorator with a parameter providedIn: MyModule. We say this service will be available within MyModule. Whenever this module created, it creates a brand new instance of IngredientProviderService.

Global provider

Global provider has enormous responsibility and can be accessible across the country. In Angular context, a service or class can be accessible across the application.

@NgModule({
  declarations: [AppComponent],
  imports: [BrowserModule],
  providers: [IngredientProviderService],
  bootstrap: [AppComponent]
})
export class AppModule {
}

// or using the @Injectable() annotation
@Injectable({
    providedIn: 'root'
})
export class IngredientProviderService {
    public getRawIngredients(){
        return 'raw ingredients';
    }
}

In this example, we declare the IngredientProviderService in the AppModule's providers array. We need to declare it in the main module where we import the BrowserModule in this example AppModule is the main module. Another way we can say it providedIn: 'root'. Now IngredientProviderService is accessible across the modules. We need to handle this type of service carefully otherwise it can cause memory leak.

If we need a service that can be accessible across the modules but each module need a fresh instance then we need to say providedIn: 'any'

@Injectable({
    providedIn: 'any'
})
export class IngredientProviderService {
    public getRawIngredients(){
        return 'raw ingredients';
    }
}

Universal provider

Universal provider is the boos of the Universe. If we can make small community in Mars in coming year and someone from there want to eat Swedish meatball then we need a provider that can serve across the planet. In Angular context, if there are multiple application running in the page and we need a service across the application.

@Injectable({
    providedIn: 'platform'
})
export class IngredientProviderService {
    public getRawIngredients(){
        return 'raw ingredients';
    }
}

In this example we use providedIn: 'platform'. platform is the key to make it available across the applications.

Conclusion

Dependency Injection is very important in Angular. If we want to be good at Angular, there is no escape form DI. So make time to get solid basics.

Thanks for reading and I hope you learn something from this article. Don't forget to leave a comment, how you understand the DI.

Can you remember "Can't bind 'x' since it is not a known property of 'y'"?

Tasnim Reza — Tue, 07 Apr 2020 09:46:47 +0000

This is the most upvoted error in Stackoverflow (https://stackoverflow.com/questions/38892771/cant-bind-to-ngmodel-since-it-isnt-a-known-property-of-input)

Angular has a very decent description of what are the reasons behind this error. In this article, we will dig a little bit further to understand and memorize the reasons in a way so we'll not google again (hopefully!).

Before start, let's have a quick look at what the document says

This error often means that you haven't declared the directive "x" or haven't imported the NgModule to which "x" belongs.

Perhaps you declared "x" in an application sub-module but forgot to export it. The "x" class isn't visible to other modules until you add it to the exports list.

So we'll get this error if we don't import the correct module or if we forgot to export some components.

Let's explore the use cases

1. Module is not properly imported

Let's add a module say ModuleA and a component say ComponentA alongside AppModule Let's make this module empty



@NgModule({
    declarations: [ComponentA],
    imports: [],
    providers: [],
    exports: [ComponentA]
})
export class ModuleA { }

Now in the HTML try to use ngFor



<h1 *ngFor="let foo of bar">{{foo}}</h1>

In the console, we'll see a warning



Can't bind to 'ngForOf' since it isn't a known property of 'h1'.

The problem is, it doesn't say which component, to find out we need to expand the warning and see ComponentA_Template has this issue.

Also, the warning doesn't tell which module is missing, unfortunately, we need to find out this ourselves, in this case, it is required CommonModule.

In a similar fashion, this can happen for ngModel which required FormsModule. Even it is applicable for our custom component for example if we forgot to import ModuleA to AppModule then it'll show a similar type of error.

Important to remember, sometimes you'll see this error to browser but most of the time this error is shown in the build

2. Wrong property binding in `HTML` template

We know in general HTML is case-insensitive, so if we bind a property wrongly it doesn't show any error for example

if you write <td colSpan="2"> instead <td colspan="2"> it'll render correctly but if we try to write something

<td colspan="{{1+1}}"> instead <td colSpan="{{1+1}}">

It'll show error



Template parse errors:
  Can't bind to 'colspan' since it isn't a known native property

Important to remember in Angular most of the property binding is camelCase like ngModel, ngClass and so on

3. Wrong Input/Output declaration

We know this is a very powerful communication medium but sometimes it can be troublesome. So when we are in this situation we need to look the annotation syntax @ or make sure it is present in the input/output array.

If we declare Input() public foo: string; instead @Input() public foo: string; but this is hard to reproduce!

So how it can be missing from input/output array



@Component({
  selector: 'component-a',
  templateUrl: './component-a.html',
  styleUrls: [],
  inputs: ['fooo'] // it can be misspell since it is string
})

In the template



<component-a foo="bar"></component-a>

Then we end up with an unpleasant error



Uncaught Error: Template parse errors:
Can't bind to 'item' since it isn't a known property of 'app-item-detail'

Important to remember, It is a best practice to use annotated @Input()/@Output() declaration and avoid alias naming

Rule of thumb

If the element is Angular directive then check CommonModule is in place
If the element is Web Component then check CUSTOM_ELEMENTS_SCHEMA is added to @NgModule.schemas
If the element is added by you then make sure the respective module is imported and the component is in the export list.
If we're using @Input()/@Output() follow the best practices, ie. always use the annotated declaration.

I hope you understand the reasons for this error and you'll avoid the trap. If you have any question please let me know in the comments. Happy coding

Learn the basics of Angular error handler.

Tasnim Reza — Sat, 04 Apr 2020 17:11:32 +0000

In this article, we'll discuss three basic principles of handling the error of an Angular app.

1. Handle bootstrap level error

This type of error is the most dangerous because they can block our entire app. There are a few reasons this error can happen for example, if we made any mistake in the component constructor or module constructor or if the root route is failed to load or render. Now the question is how we can track those errors? The answer is simple, if we bootstrap our app using ´CLI´ then it is already added in our ´main.ts´ file

platformBrowserDynamic()
  .bootstrapModule(AppModule)
  .catch(err => console.error('Handle bootstrap level error', err));

Otherwise, we need to add the catch block ourselvs.

2. Handle module-level error

The module-level error means regular errors. While we are interacting with the app, some exceptions can happen. Angular provides a very clear guideline of how we can handle this type of errors. This is a very good practice to set up a generic handler that can handle all types of errors. Angular has a generic error handler class called ErrorHandler. We need to inherit this class. This class has a generic method called handleError that we need to override. Let's implement this

export class GenericErrorHandler implements ErrorHandler {
    handleError(error: any): void {
        console.error(error);
    }
}

Now we need to add this handler to our module

@NgModule({
//..
providers: [
    { provide: ErrorHandler, useClass: GenericErrorHandler }
  ],
})

One of the key tasks of this generic error handler is tracking the error. We may want to post the errors to the error tracker. The error tracker implementation should be here.

I would prefer to have a single error handler for the entire app To ensure this we need to add this handler to the AppModule. There can be an exception like if we made an app that has client-side/customer-facing and admin-side both in a single app. We may want to handle errors separately. In that case, we can add two different error handlers on the top-level module like AppClientModule, AppAdminModule.

3. Handle in component level

Definitely we can handle errors in component level. So there is a question what do we mean by handling errors in the component level? If we add try-catch or promise-catch inside the component then it is handled at the component level. In that case, our generic or global error handler can not detect this error.

So it a downside of handling errors in component level. But there are cases when actually we need to do this. For example, we want to show a very specific message to the user if something is broken or if the user didn't fill the form correctly.

We need to handle this case in a way so that our generic error handler can perform its task. As we already know, one of the key tasks of the generic error handler is tracking errors.

I found two ways to perform this task

Re-throw the error with the original message, like

try {
  let foo: any;
  console.log(foo.bar);
} catch (error) {
  console.error('Handle error in component level: ', error);
  throw new Error(error);
}

Add a shared service at the application level. Application-level services are top-level, they can be accessed from all over the application. From the generic error handler class and inside the component we can use this service to track the error.

Conclusion

I hope you understand the different levels of errors and how to handle it gracefully. If you have any question please use the comment box below :)

7 Practical Use Cases of JavaScript Array.from

Tasnim Reza — Wed, 01 Apr 2020 20:56:51 +0000

Definition

Array.from ( items [ , mapfn [ , thisArg ] ] )

Parameter

items: required, it could be Iterable like Map, Set, WeakMap, WeakSet or arrayLike object like regular Array, string, NodeList, HTMLCollection and so on.

mapfn: optional, It is a regular map function like

function(item, index){
  return item*2;
}

thisArg: optional It could be any type of object which can be accessible from inside the mapfn via this keyword

Array.from([1,2,3], function(item, index){
console.log(this); //1
}, 1);

1. Transform iterable to array.

We can transform any iterable to array. Let's see some examples for built-in iterables.

Array.from(new Set([1,2]));
[1,2]

Array.from(new Map().set(1, 1));
[[1,1]]

2. Find unique items from array

We can use this method to identify unique items from array, though i prefer to use spread operator. like [... new Set([1,1,2])]

Array.from(new Set([1,1,2]));
[1,2]

3. Create array from user-defined iterable

Sometimes we need to define our own iterable objects. We can convert them into array in a similar fashion.

function* simpleIterator() {
    yield 1;
    yield 2;
}
Array.from(makeIterator())
[1,2]

4. Clone any array 5 Some use cases for arrayLike object

Since Array.from shallow copies item so we can use to clone any array.

let foo = [1,2,3];
let bar = Array.from(foo);
foo === bar
false

The object equality foo === bar false means, they aren't same object though they have the same items.

5. Convert string to character array

Since string is an arrayLike object so convert them into array.

Array.from('how are you');
["h", "o", "w", " ", "a", "r", "e", " ", "y", "o", "u"]

//It is Unicode supported
Array.from("I💖U")
["I", "💖", "U"]

6. Convert arrayLike object to array

Another useful use-case would be mapping items while converting them into an array. For example HTMLCollection is an arrayLike object, what if we want to change the textContent?

let divs = document.getElementsByTagName('div');
Array.from(divs, div=> div.textContent = 'hello')
["hello", "hello", ...]

7. Prefill an array

Also, it can be useful to prefill an array

Array.from({length:3}, x=> 0);
[0, 0, 0]

Forem: Tasnim Reza

3 ways to handle Async/await error.

1. Promise.catch

2. A wrapper of Promise.catch

3. Promise.allSettled

Summery

3 most powerful JavaScript Promise methods

1. Promise.all

2. Promise.allSettled

3. Promise.race

Summery

Angular Dependency Injection 101

Dependency Injection

Injectable Service

Metadata

Local provider

Nationwide provider

Global provider

Universal provider

Conclusion

Can you remember "Can't bind 'x' since it is not a known property of 'y'"?

1. Module is not properly imported

2. Wrong property binding in HTML template

3. Wrong Input/Output declaration

Rule of thumb

Learn the basics of Angular error handler.

1. Handle bootstrap level error

2. Handle module-level error

3. Handle in component level

Conclusion

7 Practical Use Cases of JavaScript Array.from

Definition

Parameter

1. Transform iterable to array.

2. Find unique items from array

3. Create array from user-defined iterable

4. Clone any array 5 Some use cases for arrayLike object

5. Convert string to character array

6. Convert arrayLike object to array

7. Prefill an array

Further more

2. Wrong property binding in `HTML` template