Add transform.Unmarshal func

[bep]

So we can do:

{{ $mydata := resources.Get "mydata.json" | unmarshal }}

The above will obviously make even more sense/value once we get remote support in Get.

• Use metadecoders.Unmarshal
• Add support for CSV to the above method, as that will make this in line with what we have in getJSON/getCSV.
• Check that we have MIME types for all supported formats.

/cc @regisphilibert

[regisphilibert]

Awesome! This would guess the language ! Even better than GetJSON then.

remote support in Get

Slightly off topic but I’m not sure of what this is referring to as GetJSON already supports remote (http) as I understand it.

[bep]

Awesome! This would guess the language !

It's a fairly educated guess ...

GetJSON already supports remote (http) as I understand it.

It does. But resources.Get does not. This may look like we're doing some double work, but the getJSON API is a little clunky and not very flexible. Having these produce something that has a common known interface (Resource) makes them ... pipe-able. And we get a simpler code. I hope that we eventually can "hide"/retire getJSON.

[regisphilibert]

I may only be asking because of a lack of understanding of the "unmarshaling" process but why not have this available as a resource variable or method, like .Resize for images, rather than a new global .resources transformation function which (I think ?) would only be able to process a few resources (json, csv, yaml, toml) ?

[bep]

Instead of me spending time on the "why", could you elaborate on the "why not"? What is the benefit of your way vs my way?

[regisphilibert]

My way does not introduce a new global transformation resource method.

Mainly because I don't think unmarshaling is going to transform the resource and make available the transformed file on disk like SASS or minify does.
For me, if I understand correctly, its use case sounds more like .Content or .Permalink than resources.Minify or .resources.Concat.
It does not manipulate the resource as much as it interprets its content.

Then again, I may be missing something.

[bep]

You are right in that it doesn't transform the Resource into another Resource -- so it's a function. So, this discussion is: Method vs function.

I would say that my main reasons to prefer the latter is:

• "pipability": {{ $mydata := resources.Get "mydata.json" | unmarshal }} vs {{ $mydata := (resources.Get "mydata.json").Unmarshal }}
• Also the reason .Content is part of the Resource interface is because all resources support it. Unmarshal will be a very special thing for some text resources (it would make no sense for CSS, to take one example, and we can make better error messages if you try to do so).
• You may argue that image Resize is different, but that is a set of very specific image related methods, e.g. an API, so I think that is a little different.

[bep]

@regisphilibert I have changed the title of this issue. We already have transform.Remarshal (which we use in the docs site code selector).

So, adding transform.Unmarshal would fit nicely into that. It could accept both strings and Resource objects.

[regisphilibert]

Awesome! Now everything can be unmarshalled, even front matter params (which could very well hold JSON strings with some remote data sources)!

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.