Skip to content
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

Merged
merged 6 commits into from
Feb 19, 2019
Merged

feat: use jupyterlab-manager output widget #46

merged 6 commits into from
Feb 19, 2019

Conversation

msuperina
Copy link
Contributor

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

@@ -9,7 +9,7 @@ var loaders = [
'babel-preset-stage-0',
].map(require.resolve),
},
exclude: /node_modules/
exclude: /node_modules(?!(\/|\\)@jupyter-widgets(\/|\\)jupyterlab-manager)/
Copy link
Contributor Author

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wow, gotcha

Copy link
Member

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.

Copy link
Contributor Author

@msuperina msuperina Feb 15, 2019

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);
Copy link
Contributor Author

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

Copy link
Member

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.

Copy link
Member

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?

Copy link
Member

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);
Copy link
Contributor Author

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.

Copy link
Member

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)

Copy link
Contributor Author

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.

Copy link
Member

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() {
Copy link
Contributor Author

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.

Copy link
Member

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?

Copy link
Contributor Author

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.

@msuperina
Copy link
Contributor Author

This is still a WIP and needs testing and cleanup. I thought opening this PR would help people playing with this branch.

@msuperina msuperina mentioned this pull request Jan 22, 2019
@SylvainCorlay
Copy link
Member

@msuperina thanks for your contribution, this is great, and quite a feat!

I will put some cycles into this tomorrow!

@msuperina
Copy link
Contributor Author

@SylvainCorlay thanks for looking into this. I will wait for your feedback before any refactoring.

Copy link
Member

@maartenbreddels maartenbreddels left a 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);
Copy link
Member

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() {
Copy link
Member

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?

@vidartf
Copy link
Contributor

vidartf commented Feb 5, 2019

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.

@SylvainCorlay
Copy link
Member

Hey @msuperina quick note on this: your git config email is [email protected] which does not match your GitHub email. You may want to change this so that github credits you for this work.

@msuperina
Copy link
Contributor Author

@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 ?

@maartenbreddels
Copy link
Member

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.

@SylvainCorlay
Copy link
Member

@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?

@msuperina
Copy link
Contributor Author

@SylvainCorlay no please go ahead if this is what is stopping you 😃

@SylvainCorlay
Copy link
Member

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.

msuperina and others added 6 commits February 18, 2019 14:05
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
@SylvainCorlay
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants