For cells whose returns are SVG or HTML, and thus render an image, I would also like a textual representation for debugging purposes. It would be much easier than going to the console to see why it fails and work through debugging.
Hi Karl. If I’m understanding correctly, you can get an inspector in the notebook for an HTML cell by naming the HTML cell and then referring to the name. You can also log things to a mutable cell, so you don’t have to open the console. I’ve demonstrated in the notebook below. Let me know if that’s not what you were looking for!
Toph - Thank you for all that effort. It is a great tutorial on debugging methods.
I think the “name” option may be what I want but there seems to be defect accessing the content.
This discussion has continued in the comments on that notebook, but for the benefit of the forum — the arrow to expand the Inspector wasn’t working because my upstream cell was continuously updating, so the Inspector kept being blown away and re-rendered, which loses its expanded state (issue #12).
The Inspector shows
[forbidden] on prototype properties because, for instance,
throws an error, whereas
works. So you can access those “forbidden” properties by calling them directly on the element.
(Those are just the easy bits to respond to. There’s still the open question of, like, could there be inspector functionality more like DevTools’s Elements tab.)
Yes. The Elements tab, while useful, is very heavy, especially in an Observable page where the user’s content is buried within Observables content. I want to - run a cell, on seeing it fail for whatever reason, switch to view of the code it created/updated, and debug in place.
Then it could become it’s own active debugger with cool interactions like something that highlights rendered code related to user code. ie Hovering over a ‘rect’ statement highlights the 10 rects it created.
Ahh, I agree and I’m sorry I misinterpreted what you were looking for! I agree that an in-notebook “Elements” inspector for the output of a cell would be great. Hm… Chrome DevTools is open-source but overwhelming.
As just a very scrappy barebones first stab at a solution, here’s a custom element inspector that mimics the tree view of the Elements panel. It doesn’t highlight anything (or even track mutation yet) but maybe it can help in simple cases, and inspire something better:
Wow. Super cool. Just got back from a trip. Will try out and see if these help debuggin.