Test finalized renderer messaging API

[connor4312]

Refs: #123601

• anyOS @roblourens
• anyOS @isidorn

Complexity 4

Create Issue

Create Issue

---

Renderers do not use standard webview messaging, so we created a new messaging channel for them to talk to the extension. Messaging must be requested statically and is opt-in, since renderers which have a hard dependency on messaging will not be usable in aznb.

• Issue with design and information: requiresMessaging flag on renderer and corresponding communication #123601
• Permalink to API:

  vscode/src/vs/vscode.d.ts

  Line 12329 in d611085

  export function createRendererMessaging(rendererId: string): NotebookRendererMessaging;

Note that, since the editor is still proposed, an empty object is given and accepted in this API when enableProposedApi is not turned on.

You can test this functionality with an existing renderer-bearing extension, like github-issues-notebooks, or create your own notebook renderer via npm install -g generator-code && yo code

[isidorn]

Works fine, I just find it weird that this is finalized API but if I do not have enableProposedApi I will get an empty object.

[roblourens]

Yeah, we are sure we want to finalize an API that depends on proposed API? Are we confident enough in the proposed API?

[connor4312]

I think we're confident that there will be something named a NotebookEditor and that we want it passed when doing messaging. Stable vscode.d.ts types it as an empty interface, so an empty object is passed to ensure that non-proposed consumers don't accidentally depend on any of its properties.

[rzhao271]

Isi took care of Paula's slot. Closing the TPI