Native Notebooks - Shared Variable Explorer for Partners

[claudiaregio]

Today in VS Code, the Jupyter, Julia, and .NET extensions are all building notebook experiences. In an effort to have consistent notebook experiences for users regardless of the language they use and to reduce duplication efforts moving forward for any other language partners, it would be great if all partners could leverage the same variable explorer.

After meeting with the Julia team (@davidanthoff and @pfitzseb) and .NET Interactive (@LadyNaggaga) below is a summary of the current state of the variable explorer experiences and what each extension enables for their users.

Jupyter:

• Variable Explorer is a table rendered as a webview that is shown in the bottom panel by default. This panel can be moved to the side panel but this is not a great experience as it was designed in a "horizontal" orientation. In order for users to see the entire table they would have to enlarge the side panel a lot and then would end up covering the majority of the notebook which would defeat the purpose of opening the variable explorer and looking at their code.

• Displays:
  • Name
  • Type
  • Size
  • Value
• Functionality;
  • Sort by name
  • Sort by type
  • Entry point for data viewer

Julia:

• Variable Explorer shown as tree view (copied from debugger view) in side panel
• Displays:
  • Name
  • Icons (same that autocompletion uses) to represent type
  • Value
• Functionality:
  • Entry point to table viewer (similar to Jupyter data viewer)
  • Entry point to plot navigator (similar to Jupyter plot viewer)
  • Can drill down into the variable and see the internal structure
  • Kernel Management: Since all notebooks share the same tree view, top level nodes are what help users differentiate what notebook the variables are coming from. Because of that, Julia ext allows users to kill/restart kernels from these top level nodes. (To be kept in mind when exploring the kernel management tab in the notebook panel)

• Special Notes:
  • Thinks the variable viewer works well in the bottom panel for notebooks but tree view is crucial for their customers. Julia team brought up the table/tree view in Visual Studio and thought that could be an ideal solution UI wise that would work well for both their REPL and notebook story.
  • Asked about potentially running an A/B test to understand what would be best for users here
  • Mentioned that since size does not apply to all variables, this information could potentially be shown on hover?

.NET:

• ✋ Variable Explorer not functional today
• Would require same functionality as Julia team
• Since the .NET Interactive kernel supports multiple languages, it would be critical for users to see also have a 'Language' column.

Summary/Pending Questions:

• Jupyter, Julia and .NET need the surfacing of the variable name, type, value. What is best way to do this given today's UI differences?
• .NET needs ability to surface 'Language' as well.
• How important is size given that it doesn't apply to all variables? Does it make sense to show on hover?
• How can we support drill down and sorting capabilities?
• Can we support the table/tree view similar to what Visual Studio has to have the best of both worlds?
• If not, should we run an A/B test on different versions to understand whether a tree view/horizontally orientated table is best for users?
• How do other requests we have gotten for variable explorer fit into this? (Pinning variables, change variable values inline, etc)
• Given Julia uses this area to surface kernel management, we should see how this fits with our exploration of the kernel management panel

[jonsequitur]

Since the .NET Interactive kernel supports multiple languages, it would be critical for users to see also have a 'Language' column.

The subkernels in .NET Interactive aren't necessarily just languages. For example, you can have two different SQL kernels loaded that represent different connections, and showing the connection name would be useful as well, e.g. SQL - AdventureWorks and SQL - Northwind. So a more accurate name might be "kernel" but that would also be a little ambiguous.

[roblourens]

Didn't realize we had this issue already. We can continue in #165445 and #166296