>> Hello there, I'm Chris Heilman.
I'm a product manager at Microsoft Edge and I want to
show you a great way to debug SWS.
This is my app, it's running as you can see in
the terminal and I normally go to the browser to try it out,
but I also go to the browser to
change it because the developer tools
allow me to visually see what's happening with my CSS.
In this case, I now changed the color around to green.
I like that green better,
the problem is it's not
persistent because the files didn't change on the hard drive.
If I reload the app,
everything is back to square one.
If I use the Microsoft Edge tools for VS code extension I get
a browser inside my editor and it works around that problem.
Once you install the extension, you get
a little icon on the left hand side here and you can click
that one and generate a
launch.Json telling Visual Studio code what to run.
In this case, it points to the localhost
4280 and then I launch the project.
This one runs a browser in the background and I can turn on
the developer tools and the browser
here and I have it inside Visual Studio Code.
This means two things,
I don't have to change the context all the time,
but it also means that all the changes I do in
the developer tools get replicated in my source files.
If I now click on a color here,
it also opens to CSS file where that color came from and changes
the value of that primary CSS variable
up there when I change it around.
Once I like it, I can save
it and then when you reload the application,
it's persistent and the color has been there.
This is called CSS mirror
editing and you can turn it off if you want to.
Now us JavaScript developers we love our console log
and you can see it on the web how full the console is.
I put two console log messages in there as well,
one console info and one console log and if
you see the console here you can see that it logged already.
This a JavaScript console you can try out JavaScript,
you've got access to the Window,
everything you expect from a console.
If you interact with the application you see
your log messages and you also see that
when I add a new transaction here
that I will have one more line in my console log.
Console log is great, but it doesn't give
me the granular control I want,
and that's why it's also possible to do
breakpoint debugging in your applications.
For this, you just basically go to your source code,
you set a breakpoint and then you interact with your application.
The great thing about breakpoint debugging is that
it's not only giving you the information after it
execute it, but it stops
the execution of JavaScript so you can go through it step
by step and each step on the way you
get the information what's happening right now.
You're in full control of your debugging.
Talking about control,
everybody makes mistakes,
so it's great that developer tools have
this Issues panel that tells you when something is going wrong.
In this case it showed me there's a compatibility and
a performance issue, but it's
even better in this environment because it's life.
If I go for example to
the HTML here and I take away that language,
I get a little red underline on the HTML element.
If I roll over that it explains to me that
it needs a language attribute because of accessibility.
This is life while I'm coding my changes.
If I put that back in the little red line goes away.
If I put an image in there and I don't give it an alternative text
it also gets that red line and
it explains to me why that is a problem.
Yellow lines are compatibility issues so
template is not supported by Internet Explorer,
well, we don't need that anymore.
You can also open the Problems pane
and then you get all the information of
all the problems of all the open files in your project right now.
The great thing about the browser is that it's
not only a browser window, but also an emulator.
You can, for example, create different devices,
in this case, a Pixel 3 XL and that is now
a mobile phone emulation complete with touch interface.
You can rotate it around as well and you can
see what your app looks like on a mobile device.
You can also do other things like testing different modes,
for example, a Print mode,
would it be possible to print out?
You could see that the heading's,
so missing so something's going wrong there.
You can also see forced colors mode
which is something a lot of users
need and that one means no background colors and more contrast.
Talking about accessibility issues, you
can also see what your app looks like,
blurred or if somebody has
color deficiency like you can't see colors,
then you will see what that looks like as well.
You can simulate all environments directly in the browser.
If you close the browser window and
you close the developer tools at the same time,
you'll also end the debugging session.
This means you totally cleaned
up and nothing is left that is problematic.
If you want to learn more about this,
we're on GitHub and please file some issues there.
[MUSIC]