-
Notifications
You must be signed in to change notification settings - Fork 29.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for breakpoint dependencies #166202
Conversation
4f30831
to
cf759e5
Compare
Thanks for the PR, and sorry it took so long to get to. This is something I personally would find useful and would like to get in :) however, I think we may want something a little different than this PR:
This month is housekeep for us, but this feature is on my radar for the next few iterations. I'll leave the PR open for now -- if you're still interested in doing work on this, we would welcome the contribution. Otherwise, I may or may not end up building on it to implement the feature, depending on where things stand. Thanks again for your contribution! |
Thanks for the feedback @connor4312 . I will start working on the first point which I do agree with you. For the second suggestion on the UI part, Are you thinking of a new icon ? |
Yea, I think they should show in an "unverified" state until triggered, maybe reuse the issue-draft codicon? |
62f7ecc
to
6c4ef9f
Compare
@connor4312 I did the changes you suggested, please check and let me know what you think. Also I still in doubt of the namings I used for this new feature. Using |
Yes the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments, excited to see this happening :)
Co-authored-by: Connor Peet <connor@peet.io>
0ddcf25
to
2f5c1bd
Compare
2f5c1bd
to
37070e9
Compare
I pushed a few changes. I think the last pending things for me are those in the Breakpoints view to reflect state better... |
- change feature name to triggeredBy - add close button - add actions - add confirmation on toggle
d60e245
to
8b30e7b
Compare
Ops, I did few changes during last few days and just pushed them, I think I might have overwritten your changes, sorry, I should have checked the MR before force pushing into my branch. But please feel free to push your changes over mine, I can then have a look at the remaining. Only thing that was pending in my changes was the path and button label and icon to be decided. |
No worries, I still have them locally, will push |
Re-applied, and I fixed up some of the styling on the widget too |
Thanks, and I started to add icons and I will use a mix of default breakpoint icons and issue-draft to see how it comes out. Then we can decide if we want new icons or if we can change the icons in the code to something else. |
@connor4312 I tried to see if we can improve the icons than how it look like now. But I cannot see a better way than using
If we use these icons, we will be able to expand this feature later into other type of breakpoints easily. I also tried to treat this pending state as a separate breakpoint state like the unsupported breakpoint state by using I would like to get some hints over here. |
- Referencing the breakpoint location got tricky when breakpoints resolve to different locations than they were initially set at, and also as breakpoints change when files change. Instead, use the breakpoint UUID. - Newly-enabled breakpoints were sent for a URI when hit, but in DAP sending breakpoints for a URI replaces all the breakpoints in it, so this was problematic. Instead track on the breakpoint whether it's been triggered for a session.
The icons look good! I pushed a few more changes from my testing with it. There were some more involved changes I made in my last commit after struggling with some edge cases the way we were doing things. But I think this is about good to merge. @roblourens can you give this a spin as well? |
If we are going with "Add Wait For Breakpoint" as the name of the feature, should it be "Add Wait-For Breakpoint"? I wouldn't mind "Add Triggerpoint" personally |
I think that hiding the breakpoint widget after I pick a breakpoint in the dropdown is odd, if the OK button is there I should have to click it |
I can have a look at it now |
In this case, should add a cancel button as well ? Or should we let cancellation be handled by escape in editor ? |
Cancel by escape is fine, same as for other types of breakpoints. |
I think this is good to go, thank you for all your work on this @gayanper! 👏 The final vocabulary for this is "triggered breakpoint" and "triggering breakpoint" The command name to create a new breakpoint is Debug: Add Triggered Breakpoint.... I kept "Wait for Breakpoint" in the dropdown of the breakpoint widget, since to me that's describing what the input for the breakpoint is, and "wait for breakpoint... foo.js: 12" reads very nicely. It's also a good hint for users who see that new breakpoint type but don't immediately know what a "Triggered Breakpoint" is. |
Thanks a lot @connor4312 for the support to get this feature in. 👍 |
Thanks for the contribution, this is cool! Re: the name "triggered breakpoint", it doesn't quite roll off the tongue, I will see if I get used to it. |
This change introduce a new breakpoint configuration to configure another breakpoint as a dependency
The breakpoint use the same icon as conditional breakpoint.
Until the dependent breakpoint is hit, the configured breakpoint is skipped from the client side. More information #152428