FR Allow breakpoints in arrow functions that have implicit return
Reported by
timkindb...@gmail.com,
Apr 4 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce the problem: Arrow functions have been around quite some time, they are now a very standard part of the JavaScript language. When used with implicit returns they are elegant and terse, however I cannot debug them. It's laborious converting arrow functions with implicit returns to have explicit return keywords and function brackets during debugging, only to have to remove them afterward. It's to the point where I have to consider if the elegance of the implicit return is worth the hassle during debugging. Can't I have both? In Intellij's built-in Java debugger it has a graceful method of dealing with lambda breakpoints. When you click a line that has an expression that also contains a lambda (maybe more than one), it detects all of the possible "scopes" that are candidates for a breakpoint, it then shows a little dropdown menu. So if, for example I clicked on the gutter next to a line of code that looked like this: ``` const prices = items.filter((item) => item.hasPrice).map((item) => item.price); ``` I'd see a dropdown menu with these choices: - Line - (item) => item.hasPrice - (item) => item.price - All We always have 'Line' as a choice. Selecting 'Line' will always just put the breakpoint on the line itself, outside the arrow function scope. This is how things work today. Following we have each arrow function as it's own selection choice. Selecting on will cause the breakpoint to only stop when the selected arrow function is executed. Last we always have 'All' as a choice. Selecting this is quite a nice feature as it puts a breakpoint on the Line itself and in all arrow functions on the Line. What is the expected behavior? What went wrong? I cannot debug arrow functions with implicit returns Did this work before? N/A Chrome version: 56.0.2924.87 Channel: stable OS Version: OS X 10.11.5 Flash Version:
,
Apr 6 2017
timkindberg@ could you please provide a sample test file to triage the issue further from TE end. Thanks.
,
Apr 6 2017
,
Apr 7 2017
So it's so interesting. I was creating my sample file and I opened it in chrome on my macbook (Version 57.0.2987.133 (64-bit)) and what do you know there are BREAKPOINTS IN MY ARROW FUNCTIONS!!! (see attachment) I was ecstatic! That is what I am asking for in this very feature request. Is this available on linux? Because that is the OS I use at work. Lastly, I'll admit the implementation was totally confusing at first, but I figured it out. Though there seems to be no way to breakpoint actual line now (I'm probably missing something). So it still might be worthwhile to consider my implementation suggestions or other approaches. But I'd be fine leaving it as is, as long as it's there.
,
Apr 7 2017
How long has this been around? Perhaps my actual problem is not being able to debug TRANSPILED code. I wonder if that has something to do with it.
,
May 19 2017
It works for non transpiled JS, for transpiled - it depends on provided source map and we've issue here on bug tracker about making debugging with source map better. |
||||
►
Sign in to add a comment |
||||
Comment 1 by ranjitkan@chromium.org
, Apr 4 2017