I hope you all had a nice Christmas and also took some time off to relax. I have some free time and want to learn new things. Doing so, i write a lot of buggy code in Observable and i often come to a situation where i want to get some (dynamic) state inside a block.
For example
someBlock = {
while (...) {
const internalState = {};
const res = doThing(internalState);
// i want to check res
}
}
I tend to use console.log in those cases but it forces me to open the dev tools and this feels ânot rightâ. So i was wondering if there is an intended way to debug code in this situation that is easier to use.
I am not entirely sure if those situations could always be resolved with better âcode planningâ.
I hope i am not overseeing something totally obvious and could articulate my problem in a somewhat understandable wayâŚ
P.S. to give a more concrete example
{
// i want to check vec
const geometry = new THREE.ParametricBufferGeometry((u, v, vec) => { }, 20, 20);
....
}
Iâve only ever used a combination of console.log and debugger statements. About debugger: if you have your browserâs dev tools open when a debugger statement is evaluated, the Javascript will pause and you can explore the variables / state in your dev tools.
Adding to what @bgchen wrote, you can wrap debugger; statements in conditions (e.g. to only execute them if a checkbox is checked). Other useful tools are:
logpoints, which are managed like breakpoints, but instead of halting they just dump a value in the logpoint scope to the console
console.assert(), which is like a conditional console.error() and can e.g. be used for sanity checks in calculations (e.g. console.assert(!isNaN(myvalue), 'got a valid number').
If you want something more integrated, my documentation helper signature has some limited support for tests (a few more examples of its application can be found in my work-in-progress Toolbox notebook.
If you want to monitor values in another cell, there are many ways to go about that:
use mutable to update another cell
use DOM events and have a cell listen to them
set your debug value as the value of a viewof cell and trigger an input event
currying a function to perform some logging action before passing parameters on to the original function
âŚ
While console.log may not be ideal, it is often appropriate given the debugging limitations of Observableâs generated code. I would also argue that your notebook is the âpresentation layerâ, and using the dev tools to spot and analyze errors is exactly right.
Thanks for your nice and detailed answer, especially your argument about the notebook as the presentation layer might be right. Never the less I think it might be potentially awesome to have some sort of interaction between the âdev layerâ and the âpresentation layerâ.
This is by no means a feature request but more an inspiration. For example in Matlab there is the concept of a workspace, where you can see the current state.
From what i understand this might be similar to how the debugger statement works. But having it as a separate tool similar to history (which is still awesome by the way) is maybe worth thinking about.
In stead of inserting all those one-line debugging cells: combine them all in one view. Looks like a simple yet powerful solution for medium-sized debugging problems. Thank you @mootari !
Btw: I totally agree with @mootari that the dev tools are legitimate (and often necessary) helpers. I can only guess what does not âfeel rightâ for @tau, and certainly does not feel good for myself:
opening dev tools involves a considerable delay and therefore interrupts my workflow (unless they are open all the time, which they rarely are in my case)
opening dev tools drastically reduces âwidthâ for the HTML page and triggers a new layout. Not only does the new layout deviate from my intended or âproductionâ layout. It also drags my mental focus away from the Notebook, and again interrupts my workflow on the mental level. Unless I am working with a huge screen where I can configure dev tools to open as a separate window.
