Protected
constructorStatic
Readonly
EVENT_Static
Readonly
EVENT_the exported objects sent in the initial message from the server. The client is responsible for closing them when finished using them.
the type of this widget
Listen for events on this object.
the type of the data that the event will provide
the name of the event to listen for
a function to call when the event occurs
Returns a cleanup function.
Sends a string/bytes payload to the server, along with references to objects that exist on the server.
string/buffer/view instance that represents data to send
Optional
references: (Table | WidgetExportedObject | Widget | TotalsTable | PartitionedTable | TreeTable)[]an array of objects that can be safely sent to the server
A Widget represents a server side object that sends one or more responses to the client. The client can then interpret these responses to see what to render, or how to respond.
Most custom object types result in a single response being sent to the client, often with other exported objects, but some will have streamed responses, and allow the client to send follow-up requests of its own. This class's API is backwards compatible, but as such does not offer a way to tell the difference between a streaming or non-streaming object type, the client code that handles the payloads is expected to know what to expect. See WidgetMessageDetails for more information.
When the promise that returns this object resolves, it will have the first response assigned to its fields. Later responses from the server will be emitted as "message" events. When the connection with the server ends, the "close" event will be emitted. In this way, the connection will behave roughly in the same way as a WebSocket - either side can close, and after close no more messages will be processed. There can be some latency in closing locally while remote messages are still pending - it is up to implementations of plugins to handle this case.
Also like WebSockets, the plugin API doesn't define how to serialize messages, and just handles any binary payloads. What it does handle however, is allowing those messages to include references to server-side objects with those payloads. Those server side objects might be tables or other built-in types in the Deephaven JS API, or could be objects usable through their own plugins. They also might have no plugin at all, allowing the client to hold a reference to them and pass them back to the server, either to the current plugin instance, or through another API. The `Widget` type does not specify how those objects should be used or their lifecycle, but leaves that entirely to the plugin. Messages will arrive in the order they were sent.
This can suggest several patterns for how plugins operate:
Handling server objects in messages also has more than one potential pattern that can be used: