I’m attempting to send a widget created in Typescript back to Python, but I’m running into issues that I thought I had solved in the past and now seem to have un-solved. In Python, I have a class that subclasses
view_module_version, and a handful of other attributes. On the Typescript side, both the
view_name classes are implemented and exported.
I’ve created a new model with
const manager: ManagerBase<any> = this.model.widget_manager (the template argument doesn’t seem to matter for these purposes) and then called
await manager.new_widget, supplying the config with the appropriate
model_name etc and the full state of the model in the second argument.
The trouble seems to be when I attempt to send it back to Python. I’ve got a container class, also registered as
@ipywidgets.register and subclassing
ipywidgets.DOMWidget. Two of the attributes are
￼nodes = traitlets.List( traitlets.Instance(NodeInstanceModel), default_value=, ).tag(sync=True, **ipywidgets.widget_serialization) selected_node = traitlets.Instance(NodeInstanceMode).tag(sync=True, **ipywidgets.widget_serialization)
In typescript, after I create the new widget with
await manager.new_widget(), I set the
nodes attribute to be a typescript array of the appropriate
NodeInstanceModel counterparts in typescript (in this case,
ReteNodeModel) and I save it.
What happens on the Python side is that an error is thrown, saying that the
nodes trait expects a
NodeInstanceModel, but it gets the string
u_u_i_d really is a UUID.) I’ve checked and it is indeed the case that the newly created model always matches the UUID – so it seems the widget isn’t getting unpacked properly. To be sure, I’ve also checked and the
selected_node shows the same issue.
(Here’s where I note that I have run into this before, and as near as I can tell, I’m not doing anything different this time!)
One strange thing that I did notice is that in the Python error output, the very first error, before the trait validation throws an error about the string instead of an instance, is that a
comm does not exist for the same UUID that is in the
IPY_MODEL name. I’m not entirely sure how to interpret that, since I thought that the
new_widget call was supposed to create a new
comm as well, so perhaps it’s a red herring?
Does anyone have any insight? It feels like I’ve overlooked something trivial, but I cannot seem to figure out what it is. I’ve tried to keep the code short, but I’m happy to provide more here or point to the original repo.