Debugging help: stack tracing with an eye to the Ember run loop and source code


#1

I’m running an Ember CLI project, I’ve got Ember inspector, I’m running Ember debug. Despite this, and perhaps partly because each element of this tool chain ultimately adds to the volume of indirection, tying unexpected outcomes back to my mental model of the source at runtime is extremely difficult. I can black-box ember.debug in Chrome dev tools to remove 100s of stack frames, but linking a helper invocation back to its call site in a template, and then back to the property computations which provided the operands… Is a seemingly obvious debug exercise which remains borderline impossible.

Does anyone have any tips for tracing logical flow in a way that relates to application source code and the Ember run loop?