Skip to content

Update Notebook API docs #4637

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Jun 29, 2021
Merged

Update Notebook API docs #4637

merged 5 commits into from
Jun 29, 2021

Conversation

tanhakabir
Copy link
Contributor

No description provided.

@gregvanl gregvanl added the extensibility extension author content under /api label Jun 28, 2021
It's important to bear in mind that all outputs for a notebook are rendered in different elements in the same iframe. If you use functions like `document.querySelector`, make sure to scope it to the specific output you're interested in to avoid conflicting with other outputs. In this example, we use `evt.element.querySelector` to avoid that issue.
It's important to bear in mind that all outputs for a notebook are rendered in different elements in the same iframe. If you use functions like `document.querySelector`, make sure to scope it to the specific output you're interested in to avoid conflicting with other outputs. In this example, we use `element.querySelector` to avoid that issue.

> **Note**: The following parts of Notebook API is still proposed and under development, which means some Notebook functionality, like the following, is only available on VS Code [Insiders](/insiders) and requires adding `vscode.proposed.d.ts` to your extension project. You can learn more in [Using Proposed APIs](/api/advanced-topics/using-proposed-api).

### Interactive Notebooks
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The content you have about the messaging API is useful, but it's actually not the right use case here--the original approach in this file remains the currently recommended way to do things.

The renderer messaging API is useful to allow for interactions between a specific renderer and the machine or filesystem. For example, the renderer might have a button that opens a folder in the file explorer. However, it shouldn't be used to communicate directly to the controller like this, since that creates a hard dependency between the kernel and a specific renderer, and prevents other extension authors from being able to create renderers that work with the controller (or even at all, depending on how tight the coupling is). Instead, the controller preloads should be used to provide a API for all renderer extensions to use.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I've reverted back to preload scripts but let me know if anything looks off!

Copy link
Member

@jrieken jrieken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@tanhakabir tanhakabir merged commit 067e287 into microsoft:main Jun 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
extensibility extension author content under /api
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants