Using cyclic refs in <script> kills hugo

[rauhs]

For instance using {{.Site.Sections}} in a <script> will kill hugo with a stackoverflow. Presumably, golang wants to convert the variable to JSON due to the context and this fails.

What is the best way to pass down Hugo variables to javascript?

[bep]

Not sure what you expected to be rendered from the map {{.Site.Sections}}.

Yes, it looks like Golang's template engine tries to convert data inside <script> to JSON. Any bugs/issues in this area should be reported at https://github.com/golang/go/issues

You can tell it to not touch some value by using the safeHtmlfunc, but in your case it's probably smart to start by pulling the values you need from the container:

<script>
    {{ range $section, $pages := .Site.Sections }}
    {{ $section }}
    {{ end }}
</script>

[rauhs]

Well I certainly wouldn't expect hugo to die :)

But the above code works well enough for my use case so feel free to close this.

Thanks

[bep]

If the Go template handler panics, then it's a bug that should be fixed -- by the Go team. Panic is a good way to signal these issues -- very visible.

It doesn't panic in Go 1.4.2 on Linux, btw.

[bep]

@rauhs I created this issue over at Go:

golang/go#10769

I'll reopen this issue to keep track of that one.

[rauhs]

Thanks for doing the work. I'd certainly make an effort myself usually but I'm swamped with work and not too familiar with go.
Much appreciated.

[adg]

On the Go issue @bep says:

The Go program in question is Hugo, a static site generator. It uses Go templates. In the template context is the Site. Site has a list of Pages; each Page has a reference to the Site it belongs to.
...from Hugo's point of view, to fix this, we must remove the circular reference from Page (and maybe some other), but that would make the software useless.

Why do the Pages have an exported reference to the Site they belong to? Is that actually necessary? You say it would "make the software useless" but I don't follow why this is true.

[bep]

Let me rephrase: This object graph was constructed by @spf13 long before I entered the picture. It may be so (I haven't thought too hard about it) that the software could live well without it -- but removing it would be a major and ground-breaking API change.

I actually like bi-directional object graphs -- and I must admit it, I was surprised to learn that <script>...</script> did automatic JSON-encoding of non-string objects. A JSONEncode template func might have been more transparent. But that would maybe be too big of an API-change ...

[adg]

I like bi-directional object graphs too, but I don't usually use them for display. Generally like to create copies of my data in template-specific data structures when using html/template.

[spf13]

The site is actually a pared down copy of the actual site object used only for display however it does contain references to all of the pages. Hugo needs this as each page needs to be able to access other pages on the site for a variety of features (related pages, menus, etc). We could do this with all copy vs references but it would get exponentially more expensive the larger the site is. I think it's possible that we could create a mostly duplicate but pared down page struct that doesn't include the reference back to the site and embed these within the site, this would solve the circular reference but would create a lot of overhead and complexity. Yes we do this with the site, but we only have 1 site instance vs N page instances.