Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Well you can't because now you declaratively represent the execution flow, and the actual execution is implicit. If you put any breakpoint in there it will break during the declaration of the execution flow rather than when the corresponding logic actually gets executed:

  Http.request.get(`/todos/${id}`).pipe(
      Http.client.fetchOk,
      Http.response.json,
    )


You put the breakpoint where you run it with Effect.runX then.


Yeah, and then it won't step you through your code but through unintelligible abstractions and Effect internals. Good luck debugging.


Plus if you are able to debug it somehow, and discover the bug in your code, can you fix it right there in your debugger?

Or do you need to figure out what is the place in your original unprocessed source-code that corresponds to the code you see in the debugger, and then switch from the debugger to edit the original file and then rebuild and rerun everything and see if that fixes the problem?

I wonder if that is a solved problem in plain TypeScript either?


That's a typical issue when debugging the JS ecosystem, it's not really an effect problem per se, albeit since Effect comes with a runtime there's way more noise as you noticed. It doesn't help your example has only library code to test.


It is actually Effect-specific, because Effect modifies control flow in JS. For instance, if you pipe 3 functions in Effect, you'll have to step through the pipe function to get from the execution of the first to the execution of the next. Working around this adds overhead every time you debug your application. In vanilla JS, `a = foo(); b = bar(a); c = baz(b)` might not be as pretty, but it is trivial to step through.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: