4 ms·

What happens when you need to debug and see how the data looks at each stage of the transformation pipeline? Won't the debugger show this as a single step if yo

• LandR 7y ago
  foo() |> bar |> quax |> hotdog You could always stick a breakpoint at the start of bar, quax or hotdog and see what was passed in?
• WorldMaker 7y ago
  The pipeline is still a set of function calls, despite the syntax sugar. You can think of x |> f |> g as g(f(x)). Even when written as a single line, a good debugger will let step through each function one at a time (as that is effectively how the system operates), and a great debugger will help you set breakpoints even "inside the line" to a specific point. (Many debuggers already support that last bit of inserting breakpoints inside of lines instead of "at" lines, it's just not as obvious as the usual "click the spot to the far left gutter of the line you want". Sometimes it is something like a Right-Click on the specific part of the line and look for a command such as "Insert Breakpoint Here". It's something to learn if your chosen debugger supports today.) The obvious tangent here, of course, is that many times when you might want to heavily use something like a pipeline operator you are likely working with something more abstract between function calls like an Iterator/Generator pattern (or an Observable pattern), and debugging those require different habits/tools as the "intermediate results" aren't directly interesting (an Iterator is "just" an object with a next() function, it's not an array of intermediately processed data). Learning to debug those patterns is its own skillset (whether or not you are using a pipeline function or a pipeline operator or old-fashioned function call syntax), but one common example is a function you'd add inside the pipeline often called something like a "tap". In that case you might "tap" in to the middle of a pipeline to log intermediate results. Something like: x |> f |> tap(y => console.log(y)) |> g