Questions about "intersect" function

I’ve been banging my head into the “intersect” function and can’t seem to figure out why it’s not working. According to the documentation (https://gohugo.io/templates/functions/#intersect), I should be able to pass two arrays as parameters to the function and have it return any elements that are in common. Here’s what I’m seeing:

The two arrays I have are both being pulled from .json files. Both are arrays of strings.

One is pulled from a page-specific data file:
{ “docTypes”: [“DT3”] }

The other is pulled from a global data file common/available to the whole site:
{ “techDocsGroup”: [“DT3”, “DT7”, “DT11”] }

Those are, of course, excerpts from larger .json files, but those are the only relevant json nodes.

In the code on my template page, where I’m trying to get this to work, I have the following lines:

{{ $dt := .docTypes }}
{{ $tdg := $.Site.Data.global.docTypeGroups.techDocsGroup }}

{{ $dt }} / {{ $tdg }} : {{ intersect .docTypes $.Site.Data.global.docTypeGroups.techDocsGroup }}

And the output I see on the page is as follows:

[DT3] / [DT3 DT7 DT11] : []

From the first part of the output line, I can see that the arrays are there and have data in them - but I can’t understand why the final “array” is showing as empty instead of showing “DT3” as it should. For what it’s worth, I also tried using the assigned/declared variables in the intersect function, instead of going back to the source, and had the same result.

Any suggestions/help/guidance would be greatly appreciated…

1 Like

I’m not able to reproduce this with Hugo 0.16-DEV. What version of Hugo are you using?

Here’s what I did in a page front matter:

dt = ["DT3"]
dtg = ["DT3", "DT7", "DT11"]

Layout:

dt: {{ .Params.dt }}<br>
dtg: {{ .Params.dtg }}<br>
intersect: {{ intersect .Params.dt .Params.dtg }}<br>

Output:

dt: [DT3]<br>
dtg: [DT3 DT7 DT11]<br>
intersect: [DT3]<br>
1 Like

Thanks for your input. The version I’m using is v0.15.

I wonder if there is a difference in how Hugo handles front matter from how it handles other types of data. As I mentioned, both of the arrays I’m testing are being pulled/loaded from .json files in the data directory… could that make a difference? Also, and I’m not sure how this could matter but I’ll put it out there, one of the .json data files is being loaded from the theme data directory, and one is from the root data directory.

I don’t think I’ll be able to set things up so that both arrays (or maybe even either) are in the front matter instead, but I’ll look into that. In any case, if anyone knows if json loaded data arrays are handled differently from front matter arrays please feel free to chime in…

There is an open bug about JSON that relates to this. Use the search function on GitHub.

I found an issue regarding the in function not working with json files (https://github.com/spf13/hugo/issues/1468) - is that the one you meant? That does look similar and could be related, but the core problem with that issue seems to be that the json array of numbers is not consistently being converted into the same format - so when comparing values there is a mismatch between int and int64/float64. In my case I’m looking at String values… so I’m not sure that the same thing is going on.

That was the closest issue I could find to what I’m seeing using the search feature - but if you know of an issue that’s a closer match, I would be very interested to check it out.

No, that was the issue I thought of.

This issue is different from #1468. Here the issue is that the JSON object returned by the data files code is returning an array of interfaces, not an array of strings.

For example, I created a data/test.json file with these contents:

{ "docTypes": ["DT3"] }

The outer type is accurately seen as an array, but the elements are of type reflect.Interface, which is not handled by the inner switch statements of intersect.

The following test case should demonstrate the issue:

{[]interface{}{"a", "b", "c"}, []interface{}{"a", "b"}, []interface{}{"a", "b"}},

I’m not real familiar with the json marshaling. Should it be converting those to Strings or do we need to handle the Interface case?

/cc @tatsushid

I can understand that the array values are not being parsed as strings by the intersect function when the array is loaded from a json data file… beyond that I’m afraid you’ve lost me. I do appreciate your help, though. :slight_smile:

In a roundabout way he said that “this is a bug in Hugo, we will fix it”.

1 Like