You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to mirror this API in JupyterLab's EventManager to make it easier to register callbacks to the Stream interface.
Currently, the pattern for listening to events is to connect a callback to the Stream signal. Adding multiple listeners requires either 1) multiple connections to a signal that check the income event's ID to see if you should fire your callback, or 2) make one connection to the stream signal and maintain your own hashtable for listener lookup. I find myself doing (2) for each plugin I create that listens to events. I think offering a single API—like we did in the server—in JupyterLab core would make it easier for folks to hook into the event stream.
Proposed Solution
Add a addListener and removeListener APIs to the EventManager.
The EventManager would maintain a map of {schemaID: set(listeners)}, offering a hash table to easily fire listener methods attached to specific event types.
Instead of folks adding their own connections to the Stream signal, they could just add listeners using this API.
The text was updated successfully, but these errors were encountered:
Problem
The server-side event system includes an API for registering "listeners"—callbacks attached to specific events schema IDs—to the
EventLogger
in Python.I'd like to mirror this API in JupyterLab's
EventManager
to make it easier to register callbacks to theStream
interface.Currently, the pattern for listening to events is to connect a callback to the
Stream
signal. Adding multiple listeners requires either 1) multiple connections to a signal that check the income event's ID to see if you should fire your callback, or 2) make one connection to the stream signal and maintain your own hashtable for listener lookup. I find myself doing (2) for each plugin I create that listens to events. I think offering a single API—like we did in the server—in JupyterLab core would make it easier for folks to hook into the event stream.Proposed Solution
Add a
addListener
andremoveListener
APIs to the EventManager.The EventManager would maintain a map of {schemaID: set(listeners)}, offering a hash table to easily fire listener methods attached to specific event types.
Instead of folks adding their own connections to the Stream signal, they could just add listeners using this API.
The text was updated successfully, but these errors were encountered: