Angular Debugging Made Simple: Building a Custom Logging Service

ArunKumar Nadikattu — Tue, 25 Apr 2023 10:43:19 +0000

Are you still using console.log for debugging your Angular applications? Do you want to create a custom logging service that suits your application’s specific needs? If so, this guide is for you.

Why use a custom logging service?

Though console.log and other console methods are useful for application debugging, they have their own limitations. They are not fully flexible and not very idle to disable all logs in one go in production. So, a custom logging service can be helpful in providing more detailed information such as user actions and the state of application. Moreover, we can customize the service to log only specific information, especially in production.

First let’s see a simple logging service



// Simple Logging Service
export class SimpleLoggingService {
  log(...data: any[]) {
    console.log(...data);
  }
}

// Usage
export class SimpleLoggingComponent implements OnInit, AfterViewInit {
  private $simpleLogger = inject(SimpleLoggingService);

  constructor() {}

  ngOnInit() {
    this.$simpleLogger.log('SimpleLoggingComponent - initialized');
  }

  ngAfterViewInit() {
    this.$simpleLogger.log('SimpleLoggingComponent - view initialized');
  }
}

This works fine. but what about the line of code which logged.

Even though the log is called in component, the console shows the log with line number of services’ console.log. What is the solution then?

Let’s try the geeky way.

Bing the console.log with itself and call it as a function in the component. Sounds geeky? Check the below snippet.



// Custom Logging Service
export class CustomLoggingService {
 /**
  * Here we bind console.log with itself and return the binded method
  */
  log = console.log.bind(console.log);
}

// Usage
export class CustomLoggingComponent implements OnInit, AfterViewInit {
  private $logger = inject(CustomLoggingService)

  ngOnInit() {
    this.$logger.log('CustomLoggingComponent - initialized');
  }

  ngAfterViewInit() {
    this.$logger.log('CustomLoggingComponent - view initialized');
  }
}

And the result …

DevTools' Console logs exact file and line number where the log is called.

Now let’s enhance the logging service.

We can further extend the service with any other console method we wish to have in our application. for example,



export const SHOULD_DISABLE_LOGGER = 
    new InjectionToken<Boolean>('SHOULD_DISABLE_LOGGER');

export class CustomLoggingService {
  log = console.log.bind(console.log);
  error = console.error.bind(console.error);
  warn = console.warn.bind(console.warn);
  debug = console.debug.bind(console. Debug);

  constructor(
    @Inject(SHOULD_DISABLE_LOGGER) shouldDisableLogger: boolean
  ) {
      if (shouldDisableLogger) {
        this.debug = (...data: any[]) => {};
      }
  }
}

On a personal note, I prefer to use console.debug method for general logging. This requires you to enable verbose logging in DevTools console to see the debug logs. And followed by using an injectable token to disable debug logs in production.

You can see my Preferred Custom Service here

Here is the Source code(stackblitz) containing the example shown above.

That’s it — have fun and happy debugging ;)

ArunKumar Nadikattu

Fix mistaken commits in Git 🔁!

ArunKumar Nadikattu — Thu, 02 Sep 2021 15:11:55 +0000

It is common issue that every developer makes code mistakes at any point of time in his career. One such mistake happens with git also.

Let assume that you've committed some code and later realised that
it is a false commit. Now you want to undo that bad commit. so, how do you do it ?

There are 2 possible ways to undo it: git reset and git revert.

git reset

git reset will move both HEAD ref pointer and current branch ref pointer to specified commit.

You should be careful when resetting as this will change the commit history.

It has 3 main options:

--mixed: The Staging Index is reset to the state of the specified commit. Any changes that have been undone from the Staging Index are moved to the Working Directory. This is the default option.
--hard: It will remove all unstaged changes. Most dangerous option.
--soft: The uncommitted changes or the commits in-front of selected commit will not be removed. It is the most safest option.

command » git reset [ --soft | --mixed | --hard ] <commit-hash>

git revert

Unlike git reset, git revert does not move the ref pointers to that snapshot. This command will uncommit the targeted commit, and that commit can be anywhere in-between the git timeline. A revert command takes user specified commit, inverse the changes of that commit, and finally create a new commit. This newly created commit will be appended at top of the commit timeline.

command » git revert <commit-hash>

When to use `reset` & `revert` ?

revert doesn't modify commit history, unlike reset. With revert you can target any particular commit in history, whereas reset only works backword from last commit.

In conclusion, use revert if the changes also exist in remote repository and use reset if the changes exist locally.

Follow me on Twitter: twitter.com/mastrero_
Github: github.com/mastrero
LinkedIn: linkedin.com/in/arunkumar-nadikattu

PS: This is my first post in dev.to

Forem: ArunKumar Nadikattu