DEV Community: Kaushal Patel

VSCode 101 – Learn 20% for 80% efficiency

Kaushal Patel — Tue, 23 Feb 2021 16:57:40 +0000

VSCode has become the hot tool in development. We don't all have to like it, but you can't deny it is the most used development tool with over 50% of developers using it for their daily work.

The flexibility of VSCode is what makes it such a solid tool for various forms of development. Out of the box, it's a super simple text editor. There is never a reason to use any of its fancy tooling or community created extensions, however, if you really want to make the most of VSCode here are the 5 key areas you need to understand.

*Disclaimer!!*: Most of the shortcuts will state **Cmd, kindly translate this to **Ctrl* if you use a non-MacOS related device.*

Navigation

This editor is FULL of keyboard shortcuts, a lot of them come in handy for traversing the crazy number of tabs we mindlessly open up.

Cmd + P: Quickly Jump to File

If you don't know of this one already it's a superpower! You don't even have to be great at spelling, VSCode is really good at shortlisting the possible file(s) you may be looking for.

Another great way to traverse around without having the file explorer open is the top path bar; it's a hidden gem I recently learned about. You can click on the file or folder in the path, and it expands to let you pick any file sitting beside it. Check it out:

Since VSCode is based on Electron, you use the tab switching shortcut from Chrome + Terminal + Firefox... basically most applications that have tabs.

Cmd + Shift + [ or ]: Go to Left or Right Tab

Intellisense

Intellisense is my favourite component to VSCode, it's so seamless. VSCode gives you very basic static analysis and refactoring capabilities depending on the type of file you're editing.

Ctrl + Space: Activate autocomplete feature for item under cursor

The editor also showcases all of the properties, methods, and blocks of the current file in the Outline window (Bottom-Left). This can be opened from the Command Palette we used previously to navigate by simply entering @. You can use the Command Palette like this to navigate within your active file with either @ or :.

The real meat of intellisense comes in it's refactoring capabilities! I will showcase my most used feature and leave the rest for you to explore. Did you know you can rename a variable safely across your whole codebase?

I was only able to show an example from a local function in my project. Try it in your own codebase, it will affect the naming for all appropriate instances.

VCS/Git

I like using the command line for Git personally, on the other hand a lot of my co-workers say a GUI Git tool is the best.

Whichever option you choose, the out-of-the-box VCS and Git feature is useful. It's so powerful with diff-checking, conflicts, tracking by file, etc.... For command line users, this can be a time-saver. For GUI users, this means one less application to open and have running on your machine. To me, this is a win/win.

You can access the VCS window on the left-hand side (it looks like the Git logo). It's pretty difficult to cover everything it has to offer without adding a million images, but the big thing to note are the vertical ellipsis and the quick options when hovering over a file.

Refined and common Git commands can be accessed by clicking the ellipsis. The plus lets you add all changes to the next commit, whilst the hooked arrow lets you rollback all changes. When you click on a file, the diff will be shown in the main window as a split between old and new. Get used to checking this tab and running through your files before committing!! It has saved me from minor mistakes and endless build times on multiple occasions.

Now if only there was a way to review PRs in VSCode when using Github enterprise. If any of you know of a tool like this, please DM me on Twitter 🙏

Zen Mode

Let your mind be free of distractions 📿

Cmd + K -> Z

If you can use this mode effectively, you know you have mastered VSCode

Extensions

I think we all know about Extensions, they are essentially plugins to help with specific issues/expansions you want for the editor. As a web developer I use a few productivity and tracking extensions:

Todo Tree
Todo Highlight
Prettier
GitLens
Language-specific extensions
Bonus: Themes

Follow me on Twitter for updates on my ebook: Git Animated - A Visual Guide to Understanding Git 😎

Let me convince you why you should use Chrome's REAL debugger and not `console.log`

Kaushal Patel — Thu, 04 Feb 2021 14:08:51 +0000

We've all been introduced to the Chrome DevTools as new devs... heck, even regular users messing around with the browser have discovered the "Inspect Element" tool. As a dev, you will have learned about using console.log to print variables and logic to the "console" on the browser. This is all normal in the passage of a fresh web developer, however lot of devs never take full advantage of the Chrome DevTools.

Do you still use console.log as your sole debugging tool? There is a high chance that it's wasting you a lot of time when it comes to modern Frontend development for the web.

console.log is a viable logging tool, but as a debugger it lacks a lot vision. Let's take some sample projects and compare the two tools.

console.log

Here's an example of how we could log out json data that our application uses. Take note of how we have to log json out as a string. This means we cannot actually traverse the json; it'll be printed out as a flat string.

Below is the output we get from logging our product and cart data.

The effort it takes to explore this data is a little daunting. It's so easy to get stuck in a bad "debugging loop" with logging data that goes something like this:

1. Add logging 
2. Analyze what was logged
3. Realize we need more info
4. Repeat steps 1-3 until bug is found or we have an understanding of the issue

This seems like a fine solution for most, but we spend so much time: trying to re-serve the application, figuring out where and when data needs to be logged, understanding how all of the data interacts with itself........

Chrome DevTools

So, how can Chrome DevTools make this process any easier?

DevTools provides a proper debugger that can be manipulated in real-time. It displays the relevant data when a breakpoint is hit, shows the current call stack, and lets us use all of that in the console with temp globals. If we look back at our "debugging loop", we saved so much time by avoiding spinning up the app and hunting down exactly where to log info from.

It's all provided in the DevTools: all we have to do is set a breakpoint c:

The most useful "feature" that completely sells DevTools for me is that it is time-centric rather than data-centric. With console.log, we try to decipher what/when something happened with the information we log. Debugging with DevTools lets us actively walk through the running application, allowing us to see the flow of our data and logic. Example:

This feels like a superpower to me. I can actively walk through how my code is executed and watch the data be affected. Doing the same with console.log requires a lot of assumptions to be made based on the information logged. I think I've made it pretty clear, Chrome DevTools is a pretty effecient debugger, but that doesn't discredit console.log.

Every tool has its time and place.

When you NEED to use Chrome DevTools

I'll argue there is one reason we MUST use the Chrome DevTools, and that's to understand network requests. As a web developer, you almost definitely work with REST calls (or any other network related call). Javascript natively does not allow us to hook onto requests. Chrome DevTools to the rescue! Open the Network tab before the request is triggered; it'll record all network calls being made. This has been a lifesaver when it comes to spotting subscription leaks in RxJS, malformed request bodys, request failures, etc.

The Truth

Yes, we can absolutely stick to just using console.log for all your debugging needs. My first employer runs a web solutions business with over 200 regular clients... he solely relies on console.log. I understand he does this due to comfort and feeling in his "zone" logging everything, but if he took an hour to understand the DevTools that come with his browser, his work would be friendlier.

Chrome DevTools comes with a lot out of the box and that can feel very intimidating. I only described two parts to all of the Chrome DevTools assortment!! As a new dev, this is the main reason we skip using them and never come back. We end up sticking to console logging all our issues in hopes of finding the bug sooner or later.