phosphor.js was archived: https://github.com/phosphorjs/phosphor#phosphorjs
We don't really use much from there except widgets. Also it's causing issues since phosphor.js comes with own concepts for events (signals), does not support disposables and does not live in DI context.
Instead of maintaining our own fork, it would be better to copy relevant bits, refactor them to use our events, clean up its dependencies, put in DI context and then clean up the shell. It would reduce amount of dependencies and size of bundled code as well.
akosyakov
All 6 comments
It would reduce amount of dependencies and size of bundled code as well.
It sounds great, but would it worth the effort? The @phosphor folder is 1.2 MB compared to the ~500 MB size of the final electron application. Even if we do the refactoring and API adjustments, we still wouldn't be able to use async API for menus, for instance, and factories for DockPanel.
kittaakos
on 6 Nov 2019
The @phosphor folder is 1.2 MB compared to the ~500 MB size of the final electron application.
For the browser context, we don't have electron and there less code we bundle less time a user waits to get an IDE.
Even if we do the refactoring and API adjustments, we still wouldn't be able to use async API for menus, for instance, and factories for DockPanel.
Not sure what you mean. If we own code, we can change it as we like.
akosyakov
on 6 Nov 2019
I totally agree with you that we are much better at events and DI than Phosphor. If we want to achieve a better experience than vscode, we need to make a lot of improvements, such as more flexible split-panel. The existing implementation of Phosphor may become a constraint.
BroKun
on 15 Nov 2019
I think it is also better instead of using https://github.com/jupyterlab/lumino, since it will make it possible to integrate JLab widgets in our widget without version conflicts.
akosyakov
on 15 Apr 2020
Hi
this can be quite an issue at the moment.
Should we go on developing extensions that use the Phosphor lib & API ? or should we add a new library that would provide these features ?
Could you give us some hints on the solution that is the most likely to be followed ?
Regards,
mikael-desharnais
on 23 Apr 2020
@mikael-desharnais you can use phorpshor.js for now, even if we merge it we will keep API the same just change namespaces.
akosyakov
on 23 Apr 2020
Related issues
akosyakov
路
3Comments
jankeromnes
路
3Comments
kpge
路
3Comments
dhananjayharel
路
3Comments
pwFoo
路
3Comments
Most helpful comment
I totally agree with you that we are much better at events and DI than Phosphor. If we want to achieve a better experience than vscode, we need to make a lot of improvements, such as more flexible split-panel. The existing implementation of Phosphor may become a constraint.