 tricks. Hi, Elf and JS. I just got everything ready. I'm going to present to you the best tips and tricks that you hopefully can add to your day-to-day of coding to have more fun, be more productive and efficient and show off to your friends. What else do you want to learn from tips and tricks? Maybe they learn something new too. I work on VS Code, so tips and tricks talks are a ton of fun for me as well because I can blend in my personal favorites that I show off to everybody who cares to listen and I can go back to the recent release notes and get all the amazing work that the team has done in front of you so you can start using them and I can go all the way back kind of beneath the surface of VS Code where a lot of amazing features linger that users haven't discovered yet. So I am happy. This is my happy place to show these tips and tricks to you. To get things started I mentioned you can show these tips and tricks to others. So how can you best show that? Often there's keyboard shortcuts involved and commands and all these little UI pieces one has to uncover and explain how to get there. So the best way to give tips and tricks is a remember the command and b if you know the command and use it more often learn the shortcut. Let's start with that. So when you want to demo something you can enable screencast mode. You did that. So now everything I do in VS Code is highlighted by VS Code itself. If I go back to what I just did typing screencast, hitting command shift P to open the command palette first, or F1. Screencast is already recently used so it's already now would be off. I want to switch it on again. Here we go. So now if you show all your crazy shortcuts, you customize and learn the new commands that you have memorized, this will help to explain it much better. This is how VS Code comes out of the box. So part one is we're looking at what are kind of the customizations that you can do to make VS Code adapt better to your workflow, to get the tools you most use most right in front of you, and to get just different styles that everybody has in the development into the tool you use most. Out of the box VS Code comes with a lot of amazing tools already. There's extensions for everything you need under the moon and it's a highly adaptable UI. So the first part already showed with a screencast mode. Let's check that first so we know it's on and I can present what I'm doing. First off, I love auto-save mode because I keep trying to perfect my code and don't save enough. And if I have auto-save mode on, I make sure to save often even though I don't hit command S or hit go into the menu. And then my build pipelines are set up to give me an instant preview so I can actually work on my code and keep coding away and see instantly what I'm doing. So let's enable that. We open settings, move that to the right and split pane, give it a little bit more room. An auto-save is actually the first option right on top. To show you how to search, you have auto-save within the command and it actually shows you two options. So if I go from off to after delay, it will now save my file every every one second. So going to this file which isn't edited yet, if I comment something out, now I have it marked modified after a second. But edit again, wait a second, it's now saved. Unfocus change does the same when you switch between tabs. So if you finish your work in one file, switch to another. Now the file is saved as well. If I move to on window change, now if I focus out of VS Code and back in, things are being saved. And back in. So now we have deletions and modifications. I'll say let's revert that, switch back and it's saved. What I recommend is after delay, it's the easiest. Keeps your work saved. You never lose it and it keeps in your changes as you work, which makes me feel productive at least. Next one up is how we actually use the UI. VS Code has this left activity bar and it's great. You have search, you have source control, you have debugging, you can find your extensions. What I don't like, I often, especially on a smaller screen, when I work on my laptop, I want to hide and show the site bar is needed. Because if I have the files open, I don't need to go in there. But that means, I don't probably want a few, who doesn't like that the windows and everything moves around. So there's two cams, site bar on the left and site bar on the right. Now when you close it, my code stays put, which is good. So you can move it anytime back and there's a command going with that, toggle site bar. You can already see site per visibility with I have been using command B and you can see toggle site per position. So let's move it back so you can confuse and you can follow along on your own. VS Code can do a lot more customizations in the UI. Very commonly is dragging these icons around where you need them. So you could move extensions up or down. But let's get a little bit more interesting. So let's open a terminal and what I find a really good way to bring things together where I look at them at the same time is moving, for example, the debug console into the run and debug activity bar view. Now they're in the same spot. I can start debugging. I can see my breakpoints. I can see the debug log output. I might even be able to close this. So I have more room for my code. That's one way. The other way is search. Search is really amazing in this small site bar for some quick searches. You look around, you find your lines you're looking for, but I also like it down here. Now if I go into search, I actually do have a lot more room and can see the longer lines as well. So that's another way. So bring a search back. I can also bring, for example, the problems view over here. So now as I go through my problems, I can again maximize the space I need. So make the best of the room you have on a small screen, on a large screen, adapted to whatever you need. But if you get into a weird spot, you can reset the view locations and bring everything back where it was. What I like to do to extend that, I showed off search in the panel below. Another way to use search is using it within the editor. So we're looking for search mode. It's in your search mode. And we switched that to reuse editor, which means it will only open in the other always using the same window if you already have search open. Now if we hit search command shift F, it opens over here. So we can actually reduce it, remove it here. We don't need anymore. We can always access it with the command if we need to, or a shortcut. If you search now, you'll find that it's okay. You keep losing your search results. So now as we go back, search go. There over here. So the other setting I recommend with that is search double click behavior. In this case it's go to location, which is default. And open location to the side is what brings the magic. So now we give this search some space. I can now actually browse through my search results, which get a lot of space in the editor with all lines presented. And they open on the right side to let me use the code. So this is my favorite style of searching. And gives me this really nice overview of the code. So let's look at WordWrap. Because you can see there's a lot of things missing if you use VS Code in small space or with many split editors. Going back to settings, WordWrap is default off in VS Code. If you switch it on, that's the first option. And on the easiest, VS Code will break lines whenever they hit the borders of the editor, which is really nice for smaller screens just to make things fit, especially if you're used to writing longer lines like documentation or markdown. The other way is WordWrap column, which then uses the WordWrap column setting, which is set to 80. And it will just break on that. So the editor window doesn't do anything anymore. But it's just breaking on the 80 characters limit. The last option is bounded, which is a combination of both. It still uses the 80 character limit to set the limit for each line. But you can also go in and now we'll pick up the editor. So really useful to have. It's my default to have it on so I can see all the code without scrolling left and right. Next up, what's really typical in my flow is creating a lot of files to like to create markdown files. So when you open a VS Code on the file, there's not much there. And then you have to pick the language mode down here. That's markdown. And now I can take my notes. The other way to do this is picking up the default default language mode. Let's go up here, default formator, default language. That's it. So default language mode is assigned to every new file you create that's untitled. So we set that to markdown. Now each file we create will automatically be a markdown file, which is great for taking notes or just scribbling down your to do. The other option is setting it to active editor language, which will pick up the last file you have open in index.js, create a new file, we'll create an index.js file. I've got a function, everything is already set to JavaScript and I can save it wherever I need. If I am in a HTML file, I can continue creating more HTML files. Really useful and feels just right. Next up, you see I already created a lot of different files I'm working on my project. PinTabs was one of the most requested features that we had in our backlog and it finally landed in a recent releases. Let me show you how it works. In this case, I'm working on FJS as my main project and I keep clicking around other parts of the project, but I don't want to lose FJS. I can just hit pin on that file on a tab and now you see a little pin appearing and it will not go away. It will always stay around, can't just close it. Similar to in the browser, these tabs are made to stay. PinTabs has some really cool customizations as well. PinTabs tabs. You can make them a little bit more compact because this file is taking a lot of space in my tab bar all the time now. Compact allows you to just limit it to the file icon and Shrink will still show you the first characters. So as you pin more files, you have still an idea of what's behind them. I like this part especially. This works well for me now. So what else can I do to actually make use of all these tabs I have open to see them? We just recently as well added WrapTabs. If I enable it, finally all the files I have open and the tabs I keep hoarding are at my fingertips. So I can close them, I can clean them up, maybe I want to get my space back, but this really allows you to remove, just need to scroll and go left and right to refine things. So that plus pin tabs allows you to really get on top of your tab hoarding. So we customized the UI, we customized tabs, we really improved our productivity and now I really don't want to lose those changes. The way to do that, to not just back your changes up, but also bring them on all the other BS code machines like your personal one and your work one and your VMs, you can use Settings Sync. It's built into VS Code, so nothing else to install. Just go into the menu here, turn on Settings Sync, it will ask you which pieces of your customizations you want to bring in. I want to bring everything. You sign in, you pick the channel, I'm on Insiders, so I'm not gonna pick that. You can have both installed site by site and sync differently. I'm gonna pick my GitHub account, you can also pick your Microsoft login and now VS Code uploads everything that I customized onto my account and it's turned on. Any changes that I made like the settings, everything else, is now securely backed up and I can bring into the next VS Code instance. This is a fresh VS Code installation that has nothing set up, look at the settings, it's empty, nothing happened here. I want to get my changes in. So in this instance as well, turn on Settings Sync, select everything, pick Insiders, GitHub account is saved to my system. Now it will get everything in, sorry there, what happened? So now if I customize further here, let's pick a color theme. Maybe in today I'm in the mood for some more red and let's keep working over here. Settings, extensions, everything will be synchronized across your VS Code and it's always one step away. Next up, let's look at IntelliSense and JavaScript debugging. One of the most useful things on a day-to-day while using VS Code and how we can make it even easier with the right shortcuts and the right settings. First off, expand and shrink selection. This shortcut and screencast mode is one of the most powerful to navigate your elements quickly. Pressing Ctrl Shift left and right allows you to go from your current selection, expanding it and shrinking it back to the next expression up and down. This works great in HTML to get the whole tag or just a part of the attribute, the whole tag, the parent element and then going up to the whole document and all the way back. In JavaScript, it works the same way. You can select the current word, the current object, the current function call and all the way up and down. One special trick, it works in Markdown. Expanding here, we'll select the current code block, then going up to the next header. This way, you can quickly navigate even within Markdown, giving the VS Code knows a lot about your code. The next trick we have powered up is IntelliSense the insert mode. If I go, for example, in the router, IntelliSense commands base is what powers this autocomplete. If I go back on a router, I will see all the methods on the Express router. If I now go in and hit delete, it will insert the value. Going into settings, searching for, so just insert, so just insert mode. You have the editor, so just insert mode. Let's switch that to replace by default, which I feel more intuitive. It does delete the text, which is why insert is the default, so you don't lose any of your text. Now if I start with the old get, I can now go back, pick this, what about just post. Now this function is replaced. You can do the same in other elements, get element by a D. I could replace it with get elements by tag name and the whole thing. So you can go back and forth and expand and reduce what you're looking for, if it's just a simple rename. Select it. How do you find out that this exists? There's the other suggest status bar, which is a neat addition to the suggestion box that's popping up. Now VS Code will tell you how to do replace, which is the default, and how to toggle over to an insert. Now if I have the get with note, I press command enter, it will actually do the old way of the insert, which I switched off. You can also show more, especially useful for web functionality, control space. You can see the very rich documentation for CSS, HTML, and JavaScript that comes baked in or all the rich typescript annotations that your code has. You can also resize those if you need more space or less space on a small screen. I love to have those. It's a little bigger. The next feature area I like to share some tips and tricks for is the JavaScript debugger that comes built in with VS Code. Last year, the team launched a new version and has a few tricks up its sleeves that make it really easy to set up without doing the whole launch to JSON dance and getting the team on board it. The first way to debug any script that you already have to find in a package or JSON is this code lens that gets added to the file. Hit debug, start. This will launch a JavaScript debug terminal for you with the script executing. Now the script is running and my server is up. I can open a browser that shows the output. My beautiful app. Now that debugging is running, I can go into my server side code, set breakpoints, refresh, and debug everything I like to know about. If I step over this and I have the image path set, I can edit things, which is the amazing part of debugging, and continue. Now when I hit the button, the cat is replaced by a dog, which is how it should be. Refreshing again without the breakpoint. We have the old cat back. This is one way. The other way is launching a JavaScript debug terminal on your own. If you kill this terminal, go into the command palette, search for JavaScript debug terminal, and get this. It opens up in a terminal panel, but now every note script you execute from here will be launched in debug mode. Even just a simple file and script like this, it doesn't even have a package of JSON. I can now launch, set a breakpoint in, hit note, hello.js, and start debugging. While you debug, everything that happens will be printed to the debug console. So I now continue. I will see the world output here. So you get logging and debugging all in one combined within VS Code, so no context switching. The other way to launch, let's use the same, let's use the same debug terminal for our app. We knew we had a breakpoint here before. If we just hit npm start now, same thing will happen. All the note processes are launched for being inspected and running in the debugger. If we now reload the app, we're again paused. We can now, again, just like in a browser, go to debug console and inspect the state of the app. Now it's undefined. Stepping one back in. It's again defined. We can poke around at all the little things that are running within the app. We can expand the objects and everything else happening within the debug console. The best rig, what I find, it really connects it all. It's not just going from the server side, but also going to the client side as well. Now that the app is running, it prints out where it's running. So if I launch this link, it will open Chrome with the debugger connected. I'm going to move to breakpoint so the app loads. Now we have the app running in the browser and this file, which is running in the browser, is running in debug mode. If I set a breakpoint here, I can now inspect the state of everything of the world within VS Code. Again, go to debug console, see what is power toggled. I can change power toggled. Really screw up the state of the world. Move to breakpoint, continue. Now, oh, yeah. Not what I wanted, but makes the point. Let's fix it again. Set the breakpoint, hit the button, reset power toggled and continue. The other way to go about it, and this bridges the gap to console logging, is adding logpoints. Power is toggled. Now, if I enter, this is a logpoint and every time again in the browser, when this code runs, it will not break and pause, but actually just print the statement of the expression I entered. I find a new JavaScript debugger amazing. Any app I run, I run it through VS Code. So any time I run into an issue, I have something I need to clarify within the code, I can just add a logpoint or breakpoint, whatever I need to do to get to the root cause of it. For me, that's a lot easier than sprinkling in console logs and occasionally forgetting one when I commit it. So, try it out. Hope you like it too. Now that our app is running and the debugger attached, I can show you the last and probably most amazing part of the new infrastructure. It's really important to make things fast for your app, not just in the back end where you serve the data and serve the pages, but also in the front end where things have to be responsive for the user to actually click on. Looking at my app, I created this slash data endpoint that takes a while to serve this really important business data. Looking at the app, there's the code. Let's find out why is it slow. To start profiling, we have to look at the call stack within the run and debug menu and then see the take performance profile button on the left, little circle with a dot inside. Take performance profile is also the command that you can look up and maybe assign to a hotkey. Let's start profiling this one, the Node.js process, for about 10 seconds. Go back to server, hit it with the quest, refresh a few times. As soon as the 10 seconds are over, VS code will serve us with the profile. Profiles by default, sorted by self-time, which shows you the function first that does the most computing. In this case, it's merge.js. The other aggregate is total time, which also includes all the leave nodes of that function and everything it calls into. So going to merge, we can actually go in, this is called by merge sort and the novice function and doing some more processing. So let's look at the function itself. Within VS code, you will get a code lens that shows the profiling that we collected in the context of the function. For fjs, this also shows forget data with self-time and total time showing here that this function itself was really fast, but overall in total, it calls some really expensive functions. The other way to monitor is using the real time performance. Let's give it some room and we can see this real-time performance graph, which is provided by an extension. Install the VS code.js profile flame extension, which adds this panel to the run and debug panel. Now we see CPU and heap. Let's give it something to do. We can see the CPU usage is going up to 100% and the heap because of GC is also going up and then GC is happening and things are lower again. The same works on the front end. Now if we go into the call stack and select the browser, we'll get even more data. Now we can monitor, going back to our original page, we can monitor DOM nodes and layouts and style recalculations on an ongoing basis, monitoring how fast or front end is and what potentially could cause issues. I'm excited for how easy this makes it to work on performance as you do your day-to-day coding, not just for your back end but also your front end and all in one interface. That was it. Thanks so much for watching. I hope you have a blast adding these tips and tricks to your daily routine with VS code. Follow us on Twitter and TikTok for even more tips and tricks and keep checking out the release notes that we put out on a monthly basis for any new additions that might help you. I'm Herath Kirschner. Thanks so much from the VS code team. Bye!