search

bmeck / proposal-debugger-operands

Adding an optional operand to the DebuggerStatement production of JS
13 stars 0 forks source link

IDE / DevTools buy in #4

Open bmeck opened 6 years ago

bmeck commented 6 years ago

Need to document DevTools responses from various vendors.

bmeck commented 6 years ago

CC: @codehag

codehag commented 6 years ago

thanks! i am looking into it!

bmeck commented 6 years ago

CC: @eugeneo (sorry if someone else would be more apt)

eugeneo commented 6 years ago

CC: @ak239

alexkozy commented 6 years ago

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?

bmeck commented 6 years ago

@ak239 this is allowing JS code to integrate with debuggers, it isn't meant to be better or worse.

alexkozy commented 6 years ago

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:

In general I am not sure what is value of statically defined conditional breakpoints and would be happy to see some real world examples.

alexkozy commented 6 years ago

CC: @hashseed

hashseed commented 6 years ago

I agree. I currently don't see the added value of this proposal, over simply gating the debugger statement with an if.

bmeck commented 6 years ago

@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?

bmeck commented 6 years ago

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.