Static tweets in Hugo: using resources.​GetRemote

A recommendation in the Hugo Discourse leads me to alter my shortcodes for embedding static tweets.

Last modified 2022-08-03

Update from the future in general (!): I continue to improve upon the Hugo shortcode described herein. Any displayed tweets in this or other posts obviously will be rendered by the most current code available when the site is on Hugo — with the only exception being when it serves a purpose to show a less well-rendered tweet, such as for a comparison between Hugo’s standard tweet shortcode and my own shortcode.
However, in this or any other related post as the actual code changes, I will not change the post’s code sample (for archival purposes) unless there’s an overriding reason to change; e.g., to correct a mistake that slipped past me during the editing process.
Please use the site search page to find related posts.

As I noted in a footnote to a recent post, I really like using Hugo’s getJSON function for grabbing data from a remote API, especially as compared to alternatives for most of Hugo’s JavaScript-based competitors in the world of static site generators (SSGs):

. . . I’ve used both [node-fetch and axios] in both Eleventy and Astro, and sometimes they’ve worked okay for me but other times they’ve constituted a major pain. (Async and I aren’t exactly the best of friends.) I have yet to run into similar agonies with getJSON, which I’ve found far more forgiving than either node-fetch or axios.

I’ve written several times this year (most recently last month) about how to embed fully static tweets on one’s site; and, where Hugo is concerned, getJSON is how I’ve done it and suggested that others do, too.

Then, this morning, when I made my first visit of the day to the Hugo Discourse, I learned I’d likely need to make a change to that.

This realization hit me as I read a comment from Hugo’s chief developer, Bjørn Erik Pedersen, in reply to someone who was having trouble with getJSON:

I would call getJSON a legacy API by [now]. We may eventually hide it from the docs.

I recommend you use resources.GetRemote for [everything].


resources.GetRemote was an addition to Hugo 0.91.0 and, as its name implies, it retrieves files and data from remote locations. While it had occurred to me that this overlapped somewhat with the already-extant getJSON, I hadn’t considered the latter to be a likely candidate for deprecation — at least, not until I read Pedersen’s comment, at which point I knew I’d have some work to do. Namely, I had to fix my stweet.html and stweetv2.html shortcodes so that each used resources.GetRemote rather than getJSON.

Now that I’ve done so, here’s an ultra-simplified depiction of the main differences between the two methods:

{{/* If using `getJSON` ... */}}
{{ $json := getJSON $urlToGet }}
{{ $text := .Page.RenderString $json.text }}
{{/* [etc.] */}}

{{/* If using `resources.GetRemote` ... */}}
{{ $currentPage := .Page }}
{{ with resources.GetRemote $urlToGet }}
	{{ $json := unmarshal .Content }}
	{{ $text := $json.text | $currentPage.RenderString }}
	{{/* [etc.] */}}
{{ end }}

Update, 2022-07-26: Contrary to what I wrote in the original version of this post, you can use .RenderString here, just as long as you establish a context it can “see” within the with loop — in this case, with $currentPage. I am grateful to Daniel F. Dickinson and @gaetawoo for setting me straight on that!1

  1. But could you use simply .Page, rather than having to create $currentPage as an equivalent of .Page? Usually, yes. However, the latter is safer. As Dickinson explained in the linked Discourse thread, “I tend to use the [$currentPage] method because I am frequently in a partial from a shortcode and other contexts where $. doesn’t work as expected, and it is easier for me to . . . use something that works consistently . . .” ↩︎

View/hide comments

Commenting by giscus.