Open bmeck opened 6 years ago
CC: @codehag
thanks! i am looking into it!
CC: @eugeneo (sorry if someone else would be more apt)
CC: @ak239
V8 allows to add conditional breakpoints. Condition may return boolean value, false forces debugger to skip current breakpoint. So categories can be implemented on top of conditional breakpoints. Could you explain how debugger operands are better?
@ak239 this is allowing JS code to integrate with debuggers, it isn't meant to be better or worse.
Current spec says almost nothing about debugger statement: it exists and debugger may trigger breakpoint. Will addition just say that this statement additionally may have operand or will it spec how debugger should act with different operands?
In comparison with conditional breakpoints this proposal allows to ship conditional breakpoints as part of script source. I am not sure how useful it is but in any case it will make debugger detection much easier: debugger {condition: debuggerIsHere()}
as part of main loop, so we can avoid it as proposed:
if (condition()) debugger
;In general I am not sure what is value of statically defined conditional breakpoints and would be happy to see some real world examples.
CC: @hashseed
I agree. I currently don't see the added value of this proposal, over simply gating the debugger statement with an if
.
@ak239 see https://github.com/bmeck/proposal-debugger-operands#detecting-debugging-facilities on why I don't think we have to mandate the operand to always be evaluated. Also detecting devtools is pretty easy already since npm libraries already expose functionality for this.
Per using static if/else it is a bigger refactoring than an optional operand which could be commented out. It potentially would mean indentation and has both a head and trailing section unlike the debugger statement:
// if (debuggingComponentAttachment) {
code;
// }
vs
debugger // debuggingComponentAttachment;
code;
It also seems to conflate debugging logic with application logic. By moving the condition into the debugger
statement you more clearly show what is being done for debugging purposes.
Per making groups by using if/else, I'm not sure I understand the complaint. The groups are based upon naming of features, not based upon conditions themselves. Even if we make groups visible to the UI with labels like onclick:debugger;
we won't be able to combine groups with conditions. Being able to quickly see potential breakpoints provided by libraries is very different from being able to set conditions that have no clear standard between libraries.
My goal with this proposal is not to mandate features of this operand, but rather to open discussion about how it is more useful to give debugging a first class experience for libraries to enrich their ability to be debugged.
If we try to prevent side effects, we need some kind of spec for this and strong definition what is side effect and what is not.
We could make an issue for this, I'm not sure it is necessary to do this but would be interested in if you have issues and reasons why side effects need to be prevented. https://github.com/bmeck/proposal-debugger-operands/issues/2 was opened up based upon some reentrancy concerns. Feel free to open another issue if you think this is important.
In general I am not sure what is value of statically defined conditional breakpoints and would be happy to see some real world examples.
Is there something specific you are seeking to see so that I can have a bit more direction? Right now almost all of the examples will be the fact that we have to instal custom extensions that are very limited and create an odd multi-debugger experience when trying to debug applications. Would https://github.com/facebook/react-devtools be enough to base talks on?
One nice thing that we have not talked about in this thread is that lots of devtools now also have editors. Being able to serialize things like conditional breakpoints to source text and/or share them across machines would be nice.
Need to document DevTools responses from various vendors.