Ref:
Inviting @cleoqc and @mitch.kremm as this might be of interest to them.
One of the issues I encountered while working on this project was trying to debug the JavaScript code running within the browser context as the browser is running full-bore and trying to debug/single-step the script is an exercise in frustration.
Researching this on-line disclosed that Visual Studio Code was working to get debugging support working within VS Code while using Google Chrome. Unfortunately, this appeared to be a “work in progress”, and the implementation appeared to be iffy at best.
Of course nothing ventured, nothing gained - so I tried it for myself and it was a less than stellar solution - so I continued hacking at it with stone tools and flint knives hoping for an eventual solution to show up.
================
I eventually reached the point where flint and bone tools were no longer adequate and I absolutely needed to be able to see what was going on “under the hood”, in real-time, and see what variables and values were actually doing. So! I bit the bullet and kept digging.
I discovered several important facts:
-
It is still a “work in progress”, but it has gotten to the point that it is usable by people who are not full time web engineers with Ph.D’s in Rocket Science.
- A major part of the problem is that the available help spans several different iterations of VS Code as well as updates to Chrome so that one set of articles advise one process and another equally authoritative set of documents advise a different method, with the actual method that works being supplied by an even different set.
- A major part of the problem is that the available help spans several different iterations of VS Code as well as updates to Chrome so that one set of articles advise one process and another equally authoritative set of documents advise a different method, with the actual method that works being supplied by an even different set.
-
The secret is to let Visual Studio Code manage the connection to the browser. That’s done using a particular configuration file, placed in the .vscode directory in the root directory of your project.
Viz.: launch.json
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "pwa-chrome",
"request": "launch",
"name": "Launch Chrome using gopigo3.com",
"url": "https://gopigo3.com/",
// "url": "http://localhost:8080",
"webRoot": "${workspaceFolder}/Joystick_Data_Test.js"
}
]
}
This tells VS Code how to launch the browser and how to bind to the code you want to run.
-
This allows VS Code to open a browser window on your local system, attach to the server on the robot, bind to the JavaScript, and exert enough control to allow you to manipulate things in near real-time.
-
Another important point is that VS Code opens a minimalist browser window session that consists primarily of just the visible
window
context, with no controls. If Chrome is running, doing anything else, it screws everything up.- Supposedly there is a way to tell VS Code to “attach” to an existing session rather than trying to start a new one, but I have not experimented with that yet.
- Supposedly there is a way to tell VS Code to “attach” to an existing session rather than trying to start a new one, but I have not experimented with that yet.
There are some issues:
-
Browser caching is still a big issue.
- VS Code still is not able to exert enough control over the inner workings of the browser to absolutely ensure that the browser cache is cleared and the current instance of your code is running. Sometimes the only way to solve that problem is to stop the debugging session, detach from, (which kills), the “little” browser session that’s running, and then launch the browser itself to clear cache.
- You clear the cache by opening the main instance of Chrome, open the in-browser dev-tools by pressing F12, right-click on the refresh icon in the upper left, and then select “Empty cache and hard reset”.
-
Setting, (and releasing), breakpoints is also still problematic.
- Sometimes this is solved by closing everything, (including VS Code and the running server), and then restarting.
- Other times it’s solved by clearing cache.
- Other times it seems to resolve itself.
I suspect that some of these issues are caused by the relative newness of the code, and others may be due to my own lack of knowledge and skill with the tool.
- You can pick-and-choose things to monitor by using the “watch” window. Though apparently designed for “watching” processes, if you open a “new” watch and manually type in the name of a variable, you can monitor the value of the variable as you step through the code.
I will add to this thread as I learn more about how this works.