Thanks for your answers, but as long as custom JS code resides in html->body
(which is the case for any code loaded through notebooks) there is no
guarenteed loading sequence when using the default HTML outputs of libs like
plotly, which assume that all of the library code is already loaded. Of course
you can add more custom complex JS code (promise etc.) to sort these issues per
notebook, but that is not very enduser friendly.
bokeh loads all of its JS resources in the html->head, which is why things work
there. And this is different to zeppelin, where everything is loaded in the
body.
https://github.com/bokeh/bokeh/blob/master/bokeh/core/_templates/file.html
The point here is, that in zeppelin there is currently no feasible way to add
this kind of central customization to the html->head section, neither for
loading Libs from CDN nor loading JS code asynchronously (like bokeh). (without
rebuilding zeppelin-web.war)
Therefore I'm again suggesting a new configuration property to allow zeppelin
administrators to include any kind of special JS code (most likely referenced
via an URL) to the html->head section. I'm not sure yet, if thats possible at
all, because configuration is some information from the server, that needs to
be loaded very early.
Or can this be achieved via helium (or an extension to helium).
Or any other idea how to solve this centrally and not on a per notebook base?
Regards
Andreas
On 2018/08/14 08:27:16, Jeff Zhang <zjf...@gmail.com> wrote:
> Here's the code of how bokeh loading js asynchronously, hope it is useful
> for you.
>
> https://github.com/bokeh/bokeh/blob/master/bokeh/core/_templates/autoload_js.js
>
>
> Partridge, Lucas (GE Aviation) <lucas.partri...@ge.com>于2018年8月14日周二
> 下午4:21写道：
>
> > I’m pretty rusty on this as it’s several years since I tried it but I
> > remember having a similar problem when trying to use Google Maps inside
> > Zeppelin. Unfortunately I can’t find the code I used but from memory, my
> > solution was to try invoking the library, and if, the library object didn’t
> > exist, load it. In the onload() callback (not sure I’ve remembered the
> > method’s name right) I would then draw my map. I certainly didn’t embed the
> > library in the notebook itself.
> >
> >
> >
> > *From:* Jeff Zhang <zjf...@gmail.com>
> > *Sent:* 14 August 2018 08:11
> > *To:* users@zeppelin.apache.org
> > *Subject:* EXT: Re: Inefficient third party JS library integration, e.g.
> > plotly
> >
> >
> >
> >
> >
> > Do you know how jupyter handle that ? And bokeh would load js from CDN so
> > it doesn't have the issue you mentioned, maybe plotly could use similar
> > approach.
> >
> >
> >
> > https://bokeh.pydata.org/en/latest/
> >
> >
> >
> >
> >
> >
> >
> > andreas.we...@gmail.com <andreas.we...@gmail.com>于2018年8月14日周二 下午2:34写道：
> >
> > We are using plotly for charts quite often (plotly python in conjunction
> > with pyspark) and it reavels a weakness regarding to third party JS library
> > integration.
> >
> > Unfortunately current plotly integration is not very efficient in terms of
> > library integration, which leads to huge notebooks. This is because
> > notebooks that contain plotly will have to output the full js code of
> > plotly. (~3MB). When a Notebook contains several of that integration, the
> > notebook becomes very slow. I think this also applies to other js libraries.
> >
> > E.g. for plotly you can render charts in zeppelin the following way with
> > pyspark (the first print is only for demoing the actual html output in
> > cleartext):
> > ---------------------------------------------
> > %pyspark
> > from plotly import graph_objs as go
> > from plotly.offline import plot
> >
> > out = plot([go.Scatter(x=[1, 2, 3], y=[3, 1, 6])],include_plotlyjs=True,
> > output_type='div')
> >
> > print(out)
> > print('%html', out)
> > ---------------------------------------------
> >
> > An alternative would be, to load plotly.js (or any other third party
> > library) from a CDN, e.g.
> > <script src="https://cdn.plot.ly/plotly-latest.min.js";></script> (and
> > settings include_plotlyjs in the example above to false, which would lead
> > to the bare minimum of code for that specific chart).
> > But this needs to be added to the html->head, otherwise any dependent code
> > using that library might run into 'Uncaught ReferenceError: ... is not
> > defined' issues, due to timing.
> >
> > I found that setup guide for repacking the zeppelin-web archive, to
> > include a custom library in the index.html, but IMHO that seems to be a
> > workaround:
> > https://github.com/beljun/zeppelin-plotly
> >
> > Therefore I would suggest to add some zeppelin server wide configuration
> > to allow zeppelin administrators to include additional <script> directives
> > in the head section.
> >
> > Any other recommendation / ideas to solve the timing issue?
> >
> >
>
