Provide access to template invocation stack in debug builds

[lukemelia]

Rendered

[rwjblue]

Thanks for working on this @lukemelia!

[rwjblue]

Another possible alternative would be to provide a public API to emit the same hierarchical message that is used for the backtracking assertion (which is what the on and fn PR linked to above uses). This doesn’t solve the problem 100% (it wouldn’t directly provide access to the line and column info), but it’s fairly close and the plumbing is already largely available (still requires owner access though that might be mitigated by an argument as suggested in the api section). I think this would likely be much easier to implement and could be improved over time to include line and column info when we have solved question 3 above (and in fact, would mean that all of Embers other template error messages like the backtracking rerender one, or on/fn mentioned above, would get that info also).

[lukemelia]

@rwjblue Thanks for the quick feedback. I incorporated this and the other feedback you left into the text of the RFC. Feel free to suggest changes if your intention can be expressed more clearly than I captured.

[rwjblue]

FYI - I brought this up at todays core team meeting. A few general notes/observations:

• There is brought consensus that we should provide a good solution to the problem described here (addons and app code being able to provide useful + actionable messages for template invocations)
• @pzuraq brought up a concern about the internal API that I was referring to (that is used by on/fn and the backtracking re-render assertion) which leverages the debug render tree. Specifically, that we are likely to move more and more of the underlying logic into glimmer-vm (currently part of it lives in glimmer-vm and part lives in Ember). I think that both @pzuraq and I came to the conclusion that as long as the specifics of the API that we provide aren't super super locked down we shouldn't have an issue.
• @chancancode and @wycats mentioned that this may be a good candidate for nice integration with the ongoing tooling efforts over in https://github.com/emberjs/ember-debug

In the end, the core team decided to defer to a smaller group (the glimmer team) for more detailed feedback. I'll try to remember to chime back in here once we've had that discussion.

[rwjblue]

We discussed this again at the most recent GlimmerVM team meeting, and think we have a viable path forward that we are confident we can support over time. We are thinking something like:

• expose a method that folks can call during rendering that returns a string they can use in their own error messages (e.g. getRenderInvocationInfo())
  • the method returns an "opaque" string (e.g. the exact verbiage / contents can change over time)
  • the intent is that when combined with other error message content, the resulting value will provide context to the developer
  • the method returns '' in some cases (production builds)

This could be used like:

export default class extends Component {
  renderLocation = getRenderInvocationInfo();

  @action doSomething() {
    if (someBadCondition()) {
      throw new Error(`Don't do that! ${this.renderLocation}`);
    }
  }
}

The fact that it returns an opaque string with the "best effort" promise means that it is quite likely that we can maintain this contract over time (vs providing more structured output like in ember-template-invocation-location addon).

We still need to decide exact method names and module paths, but the VM team is generally 👍 to this rough sketch.

@lukemelia - What do you think? Do you think that is "enough" to satisfy the motivation here?

[lukemelia]

@rwjblue I think this sounds like a good approach. I had originally thought of something structured so that the most useful error messages could be crafted, but this has obvious advantages and doesn't preclude exposing more structured detail it proves to be necessary in the future. 👍

[rwjblue]

@lukemelia - Just checking in here, have any time to update the doc? I think @pzuraq has most of the plumbing landed in glimmer-vm, so looking forward moving the API forward...

[sophie-gg]

I would just like to +1 this. I'm learning ember, and this would be extremely useful. Would make debugging and locating errors much faster, and the learning process smoother!

[wagenet]

@lukemelia just a reminder that this could use to be updated.

[achambers]

This seems useful and sounds like it had some interest initially. Does this still make sense in the Polaris world and should we pick it back up?