-
Notifications
You must be signed in to change notification settings - Fork 5.1k
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
Update Notebook API docs #4637
Conversation
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
No description provided.