Creating a new "model_ready" event in widget.js

[SylvainCorlay]

I encountered the following problem with widgets that create sub-widgets from the JavaScript side in their JavaScript model constructor:

For example the gamepad widget creates subwidgets for the buttons and axes in its constructor. Once the connected trait attribute is set to True, the user may wire things to the gamepad buttons...

However, in the case of a page reload, I would like these widgets not to be replaced by new ones, when the constructor of the JavaScript side is executed. The part of the constructor containing the creation of the children should only occur after the state request resolves.

One way to solve this issue would be to create a model-ready event for that, of have a certain promise that gets resolved right away in the case of a new model, and after the state request resolves in case of page reload.

Suggestions welcome.

@jdfreder @jasongrout

[SylvainCorlay]

I think this is related to the idea of sending the first state at the same time as when we create the widget.

[jdfreder]

Either solution sounds fine to me. Like you mention, moving the initial state push to the comm open event may remedy this.

[SylvainCorlay]

Do you want me to look at this today. (since the widget persistence changes got in)

[jdfreder]

Yeah, if we want to get this in for 4.0, I'd do it ASAP. I don't think we'll hold 4.0 if this isn't ready though.

[jasongrout]

This is related to #112, and probably deserves more than a few minutes discussion and time to test it in practice. So we're pushing this back to 4.1.

[SylvainCorlay]

The fixes to this issue and #112 needed to happen after #62.
It is just too bad it took so much time to get it in.

[jdfreder]

@SylvainCorlay , I forget, was this fixed by all the work you did with create_widget and new_widget?