Sorry if this has been asked before, but I didn’t find an open issue or topic. What do you think about providing access to sessionStorage and/or localStorage as a fundamental data source for Hugo? This could look like a natural generalization of the “remote resource” interface.
{{ with try (resources.GetSession $key) }} # or GetLocal
{{ with .None }}
<div>Nothing!</div>
{{ else with .Value }}
{{ $data = . | transform.Unmarshal }}
{{ else }}
{{ errorf "Unable to get remote resource %q" $key }}
{{ end }}
{{ end }}
the main advantage being uniform / reusable templates across various data sources, without the need to involve some JS templating system for these values.
or maybe there’s a way to shim this in as a Hugo data module? I’m new to the system so I don’t know what seems natural.
i think our web jargon wires are crossed here. I’m referring specifically to the in-browser javascript sessionStorage and localStorage API:
the data is inserted via javascript code. in terms of scope, almost all of Hugo’s data scopes which you list are static / compile-time. the exception is Remote resource, which is runtime. sessionStorage and localStorage are additional runtime scopes, controlled and maintained by javascript.
ah! yeah, like i said, i’m new. my assumption for resource.Remote from the docs was that hugo renders a mostly-static template which gets composed with the server-side data at runtime, via script. i understand that hugo is a static site generator, but “remote” looked intentionally client-side dynamic to me. so i understand that the actual behavior is that the remote fetch happens once at build time to produce a static page.
in which case this feature is not a simple generalization of remote resources as i thought. i guess the idea is re-stated as “some kind of client-side, runtime deferred rendering, with the same syntax as build-time Data”. again, with the intent being to avoid using one templating language for compile time, and a different templating language for dynamic features, especially since you might want to present the same data in both settings.
with the intent being to avoid using one templating language for compile time, and a different templating language for dynamic features, especially since you might want to present the same data in both settings.
localStorage and sessionStorage are managed by the browser, and Hugo has no access to that data. Nor should any other software, btw.
and as @jmooring pointed out, remote resource is not runtime.
as nothing with Hugo is “runtime”. Ever.
When Hugo runs, it creates your static website. Which you then serve with Apache/nginx/whatever – Hugo is not involved in that. Hugo doesn’t talk to your web server. Hugo doesn’t talk to your browser.
If you want dynamic behavior, you must use JavaScript and possibly do something server-side. Hugo is not server-side.
Again: That makes no sense. “Both settings” being
development, i.e. no server running except hugo server for testing purposes. localStorage/globalStorage referring to the current user in their current browser.
run time, i.e. hugo not running at all. Web server running and serving your static site. Browser managing localStorage/globalStorage for each user in their browser.
How do you envisage a not running Hugo to access localStorage/globalStorage on a remote machine, where they are managed by a user’s brwoser?
How do you envisage a not running Hugo to access localStorage /globalStorage on a remote machine, where they are managed by a user’s brwoser?
by emitting a combination of partially-rendered HTML templates and build-time-generated script tags (or maybe better, WebAssembly). Those things do run in the user’s browser. It is not hard to imagine Hugo’s template engine generating ES or WebAssembly snippets as part of the static build. Ultimately Hugo generates code (HTML, CSS, scripts), and the generated code must be responsible for any runtime features.
With that said, my idea stemmed from my own basic misunderstanding of remote resources, which @jmooring already explained. What I thought I saw in the docs was a system that already had a deferred and relocatable rendering capability; but I understand that doesn’t actually exist. So the suggestion is a significant architectural change after all, which was not my intention. A prototype on a fork is probably the right way to drive any more discussion.
for each user in their browser .
Yes. Deferred rendering is still useful in this case. In my specific case, I was looking at adding some minimal OIDC features. For example, the user logs in to an OIDC provider and then is redirected back to the hugo site. The hugo site might present a view of the user’s OIDC profile, or compose in some other web resource obtained with the resulting access token.
I can obviously write all of that as a pile of script. But the basic appeal is
use the build-time system to generate the script instead of hand-coding it, so i don’t have to look at or maintain it
use the same template language for the account view page as i do every other page, instead of one template language for build-time and one template language for runtime
all of the dynamic behavior is produced in the browser, so i only have to manage static site hosting.
If that doesn’t appeal to you, then we simply disagree.
I know what I’m describing sounds more like a React framework site. But frankly I find React kind of distasteful. So I was trying to figure out how to shoehorn a 95% static site with a little dynamic flavor onto Hugo. Hugo makes simple things simple and the development-time experience is excellent, which seems to get lost in the current landscape of site design frameworks.