You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Does GenericChart.toChartHTML work in version 4.0? #373
I cannot get GenericChart.toChartHTML to render in fsdocs generated pages with Plotly.NET 4.0. I think it's because 4.0 is not producing the fsharpPlotlyRequire javascript in the output.
Repro steps
If I do this in a blank docs folder index.fsx I get a nice plot produced in the html
Comparing the html output vs. 3.0, I think 4.0 missing the fsharpPlotlyRequire ... code?
see that in 4.0 there is no fsharpPlotlyRequire code before the data declaration in the output:
#r "nuget: Plotly.NET, 4.*"openPlotly.NET
Chart.Line([1,2;3,4])|> GenericChart.toChartHTML
>valit:string ="<div><div id="0acfb4b0-43b3-421f-adaf-849ee352d955"><!-- Plotly chart will be drawn inside this DIV --></div><script type="text/javascript">var renderPlotly_0acfb4b043b3421fadaf849ee352d955 = function() { var data = [{"type":"scatter","mode":"lines","x":[1,3],"y":[2,4],"marker":{},"line":{}}]
There is an fsharpPlotlyRequire function in the 3.0 output:
#r "nuget: Plotly.NET, 3.*"openPlotly.NET
Chart.Line([1,2;3,4])|> GenericChart.toChartHTML
>valit:string ="<div id="5347e62f-9fc9-4c6e-88f1-c3d40ad1f5d8"><!-- Plotly chart will be drawn inside this DIV --></div><script type="text/javascript"> var renderPlotly_5347e62f9fc94c6e88f1c3d40ad1f5d8 = function() { var fsharpPlotlyRequire = requirejs.config({context:'fsharp-plotly',paths:{plotly:'https://cdn.plot.ly/plotly-2.6.3.min'}}) || require; fsharpPlotlyRequire(['plotly'], function(Plotly) { var data = [{"type":"scatter","mode":"lines","x":[1,3],"y":[2,4],"marker":{},"line":{}}];
Related information
Operating system: Windows
fsdocs: tried 16.1.1 and 17.3.0
.NET Runtime, CoreCLR or Mono Version: dotnet --version = 7.0.100
I understand why you'd want that as the default given that you reference plotly explicitly in your _template.html for fsdocs. Was this an intentional global change for all users?
Was this an intentional global change for all users?
Changing the way the html output is rendered in general was intentional, especially getting rid of the require code that spams the head tags of pages with references once you have more than one chart per page. The previous template used both cdn and require at once, which was unnecessary.
However, the default plotly reference should be always set to CDN here:
Although that still will not fix your issue, as the cdn is referenced in the document head, which is only present in toEmbeddedHTML.
You can either use a global reference in the template header or change the global default DisplayOptions to use require again. For fsdocs, i'd recommend the former, as you load the reference only once across the page.
fsdocs, i'd recommend [global reference in the template header], as you load the reference only once across the page.
I prefer using the default fsdocs template when possible; creating a custom _template.html just to use Plotly.NET adds some friction.
Is there a simpler way to add the CDN script reference to an fsdocs page than what I have below? If not, would it make sense to add something like DisplayOptions.getPlotlyReferenceCDNScriptString() so that adding Plotly.NET CDN to an fsdocs page becomes a simple one-liner?
I guess another simple alternative is to just use GenericChart.toEmbeddedHTML for at least the first chart on a page. Once toEmbeddHTML is called the page is referencing the CDN, so later toChartHTML will load correctly as far as I can tell from my testing.
Given option 2. using toEmbeddedHTML, it's probably not worth adding something like DisplayOptions.getPlotlyReferenceCDNScriptString().
I guess I'll close this, with the suggestions being either:
To use GenericChart.toChartHTML with fsdocs, create a custom _template.html file that explicitly references the CDN.
Or, use GenericChart.toEmbeddedHTML everywhere you used to use GenericChart.toChartHTML; it'll just work and be strictly better than v3.0 of Plotly.NET.
Or, use GenericChart.toEmbeddedHTML for the first chart on a page, then GenericChart.toChartHTML for any subsequent charts on the same page. This will replicate the efficiency of using a custom _template.html file that has an explicit CDN reference.
Global defaults should persist across fsdocs files IIRC, otherwise you can do it in every file just to be safe, that's how i do it, but the other way around to make sure we use NoReference everywhere:
This will add the require part to the scripts, and is also how charts are rendered in Plotly.NET.IOnteractive.
Activity
nhirschey commentedon Mar 8, 2023
The cause seems to be that
toChartHTMLcallstoChartHTMLNodes, andtoChartHTMLNodescallsgetPlotlyReferencePlotly.NET/src/Plotly.NET/ChartAPI/GenericChart.fs
Line 262 in 1e5fec1
getPlotlyReferenceusesPlotlyJSReference.NoReferenceas the default.Plotly.NET/src/Plotly.NET/DisplayOptions/DisplayOptions.fs
Line 143 in 1e5fec1
I understand why you'd want that as the default given that you reference plotly explicitly in your
_template.htmlfor fsdocs. Was this an intentional global change for all users?kMutagene commentedon Mar 9, 2023
Changing the way the html output is rendered in general was intentional, especially getting rid of the require code that spams the head tags of pages with references once you have more than one chart per page. The previous template used both cdn and require at once, which was unnecessary.
However, the default plotly reference should be always set to CDN here:
Plotly.NET/src/Plotly.NET/Defaults.fs
Lines 27 to 47 in 1e5fec1
Although that still will not fix your issue, as the cdn is referenced in the document head, which is only present in
toEmbeddedHTML.You can either use a global reference in the template header or change the global default DisplayOptions to use require again. For fsdocs, i'd recommend the former, as you load the reference only once across the page.
kMutagene commentedon Mar 17, 2023
@nhirschey do the proposed methods work for you?
nhirschey commentedon Mar 17, 2023
Hi @kMutagene, thanks for the context.
I prefer using the default fsdocs template when possible; creating a custom
_template.htmljust to use Plotly.NET adds some friction.Is there a simpler way to add the CDN script reference to an fsdocs page than what I have below? If not, would it make sense to add something like
DisplayOptions.getPlotlyReferenceCDNScriptString()so that adding Plotly.NET CDN to an fsdocs page becomes a simple one-liner?I guess another simple alternative is to just use
GenericChart.toEmbeddedHTMLfor at least the first chart on a page. OncetoEmbeddHTMLis called the page is referencing the CDN, so latertoChartHTMLwill load correctly as far as I can tell from my testing.Given option 2. using
toEmbeddedHTML, it's probably not worth adding something likeDisplayOptions.getPlotlyReferenceCDNScriptString().nhirschey commentedon Mar 17, 2023
I guess I'll close this, with the suggestions being either:
GenericChart.toChartHTMLwith fsdocs, create a custom_template.htmlfile that explicitly references the CDN.GenericChart.toEmbeddedHTMLeverywhere you used to useGenericChart.toChartHTML; it'll just work and be strictly better than v3.0 of Plotly.NET.GenericChart.toEmbeddedHTMLfor the first chart on a page, thenGenericChart.toChartHTMLfor any subsequent charts on the same page. This will replicate the efficiency of using a custom_template.htmlfile that has an explicit CDN reference.kMutagene commentedon Mar 17, 2023
I think we can try another solution:
One suggestion could be doing this in the first rendered document.
Plotly.NET/docs/00_2_display-options.fsx
Lines 18 to 19 in 8ec8c3c
(or this if you want to preserve the other defaults):
Global defaults should persist across fsdocs files IIRC, otherwise you can do it in every file just to be safe, that's how i do it, but the other way around to make sure we use
NoReferenceeverywhere:This will add the require part to the scripts, and is also how charts are rendered in Plotly.NET.IOnteractive.
nhirschey commentedon Mar 17, 2023
Ok, that's a good option too. Thank you!