-
Notifications
You must be signed in to change notification settings - Fork 506
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: use jupyterlab-manager output widget #46
feat: use jupyterlab-manager output widget #46
Conversation
js/webpack.config.js
Outdated
@@ -9,7 +9,7 @@ var loaders = [ | |||
'babel-preset-stage-0', | |||
].map(require.resolve), | |||
}, | |||
exclude: /node_modules/ | |||
exclude: /node_modules(?!(\/|\\)@jupyter-widgets(\/|\\)jupyterlab-manager)/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I import the jupyterlab-manager WidgetManager class from node-modules it comes as es5 class and cannot be extended using the es6 extends syntax. If instead I add it to our babel transpilation process it is possible to extend it as babel sees it as es6 class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wow, gotcha
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This puzzled me a bit, but it is the other way around. The output was an ES6 class (https://github.com/jupyter-widgets/ipywidgets/blob/2b91eac459bf4929c3b92794bfb0dc7deef2a353/packages/jupyterlab-manager/src/tsconfig.json#L12) which babel then tried to inherit from, and tried to construct without using new.
I've not configured babel 7 using more modern target browsers such that it output es6 classes for voila as well. The bundle size also seems to have halved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies for confusing you, I wrote the comment much after writing the code and I realize now how confusing it can be. Also, I should have suggested a babel upgrade as you did in your commit, as at some point I did it as well while implementing this fix. I preferred not to as I am not a maintainer of this repo and such a change could have raise concerns over the the acceptance of this PR.
js/manager.js
Outdated
if (typeof window !== "undefined" && typeof window.define !== "undefined") { | ||
window.define("@jupyter-widgets/base", base); | ||
window.define("@jupyter-widgets/controls", controls); | ||
window.define("@jupyter-widgets/output", output); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to find a way to get rid of those lines if possible.
If I remove window.define("@jupyter-widgets/base", base);
I cannot load the bqplot example which requires the resource from unpkg and needs an external @jupyter-widgets/base
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, unfortunately this is still required for the bundle-based means of loading custom widgets.
Eventually, we will have voila templates that don't load AMD bundles and will not require this.
Maybe a good way to move towards a cleaner solution would be to move this out of this file and include it into a the nbconvert template.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can do that in a different PR ok?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok
js/manager.js
Outdated
return super.loadClass(className, moduleName, moduleVersion); | ||
} | ||
else { | ||
return htmlManager.loadClass(className, moduleName, moduleVersion); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am using the HTMLManager loadClass because it fallbacks to unpkg when a class is not resolved, and I did not want to replicate the code. The jupyterlab-manager does not fall back.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say, use the original loader idea. Since you already check those 3 modes, I think you could do:
...
else
return this.loader(moduleName, moduleVersion)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure I understand: for the base, controls and output modules I want to use the jupyterlab-manager loadClass, but for the rest of the modules I want to keep using the html-manager loadClass, which internally handles promise rejections and allows me to not replicate such code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I duplicated the code, I think in this case it's cleaner for the moment, so it's safer in case we want to refactor this.
js/manager.js
Outdated
} | ||
} | ||
|
||
_registerWidgets() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method exists because the jupyterlab-manager API does not expose the plugin extension directly. I don't know how keen they are to change their API. Given that I see recurrent names of people in all jupyter related repositories I hope this comment can be picked up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I follow you, this looks fine to me. I guess you see a reason not to have this code, could you explain?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I realize my comment was not clear. This piece of code exists in the jupyterlab-manager package and a slight modification of their API could allow us to fully consume their module without replicating some of the code.
This is still a WIP and needs testing and cleanup. I thought opening this PR would help people playing with this branch. |
@msuperina thanks for your contribution, this is great, and quite a feat! I will put some cycles into this tomorrow! |
@SylvainCorlay thanks for looking into this. I will wait for your feedback before any refactoring. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work Marzio. I plan to take a look tomorrow unless Sylvain beats me to it. Some small comments for now.
js/manager.js
Outdated
return super.loadClass(className, moduleName, moduleVersion); | ||
} | ||
else { | ||
return htmlManager.loadClass(className, moduleName, moduleVersion); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say, use the original loader idea. Since you already check those 3 modes, I think you could do:
...
else
return this.loader(moduleName, moduleVersion)
js/manager.js
Outdated
} | ||
} | ||
|
||
_registerWidgets() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I follow you, this looks fine to me. I guess you see a reason not to have this code, could you explain?
I did not look through this in detail, but in general, I think it would be appropriate to have a look at refactoring the lab manager in order to make it more friendly for library use. If you want to open an issue on the widgets repo outlining some of the current pain-points, that would be an excellent starting point for such a discussion. |
Hey @msuperina quick note on this: your git config email is |
@SylvainCorlay @maartenbreddels I was very busy with work and could not follow up in the past few days. Is there any work you need me to do on this PR at this stage ? |
Thanks for taking this on, I think we're finished, unless Sylvain thinks otherwise. Would be good if you could test it. Also, feel free to change the log so that the email matches the github email address, now you won't get credits. |
@msuperina I am ready to get this in. Do you want to change your committer info so that your github accounts gets the proper credit? |
@SylvainCorlay no please go ahead if this is what is stopping you 😃 |
If you want me to do it, I am fine as well. I am used to doing this sort of changes. Just give me the email address you want to use. |
Most of the widget manager logic is duplicated from the @jupyter-widgets/jupyterlab-manager package. This PR aims at using the package directly. The main benefit of this approach is support for output of "stream" messages. It becomes possible to render and interact with interactive widgets. An example of interactive widget has been added in notebooks/interactive.ipynb Fix #19 Fix #23
I just rebased the PR attributing Marzio's commits to his GitHub account (msuperina at users.noreply.github.com). Will merge when all is green. Thanks @maartenbreddels for doing the work on babel7. |
Most of the widget manager logic is duplicated from the
@jupyter-widgets/jupyterlab-manager package. This PR aims at using the
package directly.
The main benefit of this approach is support for output of "stream" messages.
It becomes possible to render and interact with interactive widgets.
An example of interactive widget has been added in
notebooks/interactive.ipynb
Fix #19
Fix #23