Now that we target es2017 in core packages, custom widget libraries that subclass WidgetModel with the es5 syntax don't work anymore.
The issue is that static properties from the es6 bases are not visible to the derived classes.
Two approach are possible:
Backbone.Model.extend in the base WidgetModel to properly polyfill the es6 extends including the behavior with respect to static properties.@vidartf @jasongrout @maartenbreddels
Another solution may be to call this version of ipywidgets 8.0. If so, it is also a good occasion to remove some deprecated things.
Note that the tutorials where we advertize backbone.Model.extend are all wrong now.
The master version of bqplot which uses es6 classes works perfectly.
The way to get bqplot working on Jupyterlab-1.0.0rc1 is a little unclear to me.
Could we have a bqplot release from Master ? Shall we use jupyter labextension install bqplot@next ?
I can't apparently get to work pythreejs and ipyleaflet either, lost in thoughts
donwgrading to ipywidgets-7.4.2 makes pythreejs-2.1.0 works on legacy notebook, apparently
The way to get bqplot working on Jupyterlab-1.0.0rc1 is a little unclear to me.
It is not possible at the moment.
When we release ipywidgets 7.5 (after we fix this backward incompatibility issue) it will work.
This is why the compile target change required a major version bump of base/controls. I didn't really think of this at the time, but I guess base getting a major version bump would require a major version bump of the Python package as well (since the JS comes bundled with the Python package). I don't think we want to delay getting 7.5 out the door, so I vote for reverting the compile target for now, and then aim for a 8.0 in the not too distant future.
Xref to PR that bumped the compile target: https://github.com/jupyter-widgets/ipywidgets/pull/2456
- override Backbone.Model.extend in the base WidgetModel to properly polyfill the es6 extends including the behavior with respect to static properties.
PS: I don't think this is a viable option, because (AFAIK) there are a bunch of other things that can go wrong as well.
PS: I don't think this is a viable option, because (AFAIK) there are a bunch of other things that can go wrong as well.
I tend to agree. I have made things work by manually adding static methods in the new extend but I am worried more would break later.
I am working on a PR reverting the move to es2017.
I am working on a PR reverting the move to es2017.
+1 for the base and controls package. I think it's probably not necessary to move the jlab manager back to es5.
Most helpful comment
+1 for the base and controls package. I think it's probably not necessary to move the jlab manager back to es5.