[LS] Standardize API for WebView configuration and communication
Objective: ensure reliable and type-safe interactions across services and webview applications
Standardize API for WebView Configuration and Communication
In order to best accommodate changing requirements and/or infrastructure, it is essential to abstract and standardize the API for managing WebView configuration and communication. The following is a proposed type that WebView would conform to for registration and interaction by additional services further up the stack.
export type WebViewId = string & { __type: 'WebViewId' };
export type WebViewTitle = string;
export type WebViewMetadata = {
id: WebViewId;
title: WebViewTitle;
};
export type WebViewDefinition<
TWebViewMessages extends MessageBusMessages = MessageBusMessages,
TExtensionMessages extends MessageBusMessages = MessageBusMessages,
> = WebViewMetadata & {
onWebviewInitialized?: (context: ExtensionContext<TExtensionMessages>) => void;
setupWebViewInstance?: (context: SetupContext<TWebViewMessages, TExtensionMessages>) => void;
};
A few things to note:
Identifiers and Message Types
WebViews should be uniquely identified, and this identifier is crucial for:
- Routing in HTTP servers via middleware.
- Generating socket URIs in WebSocket servers.
- Routing messages to the correct WebView message bus.
Also, the system emphasizes explicitly defined message types to ensure type safety and facilitate clear, compile-time communication agreements between frontend and server components.
Lifecycle Functions
- onWebviewInitialized: An optional function called when a WebView is initialized but no instances have been connected, allowing for custom actions based on the extension context. This could be used to setup message handlers for IDE actions/commands.
- setupWebViewInstance: This function is called when a new instance of a WebView is instantiated. It will be used to communicate with and setup message handlers for that instance of the WebView. It uses a context that combines WebView and extension message buses, facilitating communication and interaction setup.
Acceptance Criteria
- Establish a clean monorepo architecture where packages can be created and referenced without the need for relative pathing. For instance a locally shared message bus abstractions package should be able to be referenced like:
@ls/message-bus
. - Shared message bus abstractions package that can be consumed by both our language server project as well as our WebView frontend applications
- Shared WebView abstractions package that can be consumed by both our language server projects as well as our WebView frontend applications