Wire up dart:developer inspect(object) to Dart DevTools

[leonsenft]

Feature request

AngularDart DevTools needs the means to jump to the Dart source for a given class in the Debugger view.

Context

In the JavaScript world, this is easily achieved by passing a function (or class) to the Chrome Console inspect(object) function. This in turn opens the location of the function definition in the Chrome Sources panel.

This approach is undesirable for AngularDart for two reasons:

1. We want to direct users to the Debugger tab in Dart DevTools over Chrome Sources, because ultimately this is where setting breakpoints will be most useful.

2. inspect() is a JavaScript API which requires interacting with the JavaScript representation of a Dart object. The Dart for Web team has explicitly stated that the JavaScript representation of Dart objects is not stable nor intended for use in this manner. Furthermore, the source maps don't accurately map the class definitions and "constructor" functions back to the correct Dart locations.

Implementation

A possible solution–as suggested by the title–is to have Dart DevTools listen for dart:developer inspect() requests on the VM service protocol. I believe the Debug stream emits events with EventKind Inspect whenever inspect() is called. Given a Dart type, it could retrieve the source location from its Class and use that to open the Debugger at that location.

@jacob314 @grouma

[jacob314]

You don't really want the debug console to show the Dart Type object though, do you? That is the default behavior if "inspect" is called. I'm guessing what you really want is a standard VM Service api for dispatching events indicating that IDEs should navigate to specific source location. That way if in the future you wanted to navigate to a specific line in the class you could do it. The Flutter Inspector could also adopt this API which would simplify the implementation in VSCode and IntelliJ for navigating to the selected widget. Currently VSCode has a hard to debug bug related to some rare case where its implementation of finding the creation location of the selected widget goes wrong. Fyi @DanTup

[leonsenft]

You don't really want the debug console to show the Dart Type object though, do you? That is the default behavior if "inspect" is called.

Yeah, I'm not sure Dart types have much to inspect do they since they're just nominal? It's not like an instance where you can expand and inspect its properties.

I'm guessing what you really want is a standard VM Service api for dispatching events indicating that IDEs should navigate to specific source location.

Exactly. In Chrome DevTools this is accomplished for functions by calling inspect(aFunction) to jump to the function's definition in sources. In our case, we want to jump to the source location of a class definition instead. A more general purpose mechanism for jumping to source location is probably best, but I was willing to settle for inspect(aType) to jump to the class definition.

[DanTup]

In VS Code, calling inspect() will first try to get the location of a Widget using the VM Service, and then fall back to printing the Dart instance to the console in a way that's expandable (the same as if the user had typed an expression that evaluated to it in the Debug Console). This was was added in https://github.com/Dart-Code/Dart-Code/issues/2137 based on a (fairly vague) description in the docs:

Debuggers may open an inspector on the object. Returns the argument.

For non-Flutter widgets it would previously just do nothing (so seemed a little broken), although the new behaviour can lead to some confusion (like https://github.com/flutter/devtools/issues/2522) because VS Code doesn't really know whether the user called inspect or just clicked on something in the Widget Inspector.

Perhaps this function should be more specifically defined (or split) - is its intention to "inspect an object", or "jump to the source defining an object"?

[elliette]

@leonsenft is this feature still needed?

[leonsenft]

It would be nice, however I don't think our tools are getting much engagement so I'd say this is pretty low priority for the time being.