Page.Store enhancement

feature
1

Hello,

@irkode brought up some ideas about possible enhancements to Page.Store in order to re-introduce possibilities the old Scratch implementation provided. As the issue tracker does not seem the right place, I wanted to chime in here. I hope that’s ok.

I would definitely welcome a volatile store, as I too have some issues during development with the persistent storage.

My idea here would be to add an argument to Page.Store that controls whether it is persistent or not. I would guess most implementation code could be restored from the old implementation and because you have to explicitly enable volatility, the support headache between Store and Scratch should still be avoided. What do you think?

2

to clarify: the ideas did not have the intention to bring that Scratch back.

in production you don’t have these rebuild issues because there’s only one build.

it is merely an advanced development/testing/debugging feature and should imho be part of hugo server only.

implementation of the reset should be quite simple. just throw away the store and create a new one.

Cost comes with the way this would - if found useful - be made configurable.

writing this makes me wonder if a reset on site or global level would make sense anyhow. On page level one has to make sure there are no side effects.

an option for the store methods would just re-introduce the scratch with a new name. with all the problems it had before.

3

When someone runs hugo server, and Page.Store doesn’t do what they want, what are the use cases? I can only remember one: incrementing a counter. And in one of those cases, the site or theme author should have been using Page.HasShortcode instead.

I’m not saying we shouldn’t do something here, but I want to understand why, with succinct description of use cases.

4

@jmooring

I maintain a legacy project with a simple page layout where I faced the requirement to add sections that contrary to the normal flow span the whole width. A CSS solution to break out of the standard flow did not satisfy. Luckily the sections only appear at the top or bottom of a page. The solution was to use shortcodes to inject the content that should use a different flow (basically via something like .Page.Scratch.Add $section (slice .Inner)) that is picked up by the layout. Since the disposal of Scratch, this content is duplicated whenever a shortcode is changed, requiring needless scrolling or restarting the server.

In a similar vein I have a custom Hugo layout for a news section overview where the individual articles are present and a custom table of contents is build from their headings (again .Page.Store.Add is involed). This toc is ever growing as well.

I’m too are bitten by the counter issue. In my case, it’s for a media gallery that can host both audio and video files whose metadata gets stored in a separate .json file and I need a way to associate each generated <audio> and/or <video> element with this data. Right now, the logic fails upon rebuild due to ever increasing indexes, maybe this could be solved on the JavaScript side, I haven’t found the motivation to investigate here.

5

Correct. Therefore it’s certainly not a critical matter.

Ideally, yes. I was more thinking about the implementation cost and that an additional argument and restoring the old code would be easiest. I have to admit that I did not observe the problems behind the change and only picked up that there must have been some confusion between Store and Scratch for quite a few users which I attribute to older documentation and/or examples in the wild, that naturally don’t showcase the newer Store which is what most users actually want.

The addition of a new argument should not yield the same confusion as there are no two storage facilities. You could just configure it to your liking. But I get the reluctance.

6

Only in development when a page is build and I try to find a bug i wouldn’t want to restart every time to check if my last code/content change solved the problem, fe.

  • collecting things for a reference section from render hooks or shortcodes
  • calculating values that is accumulated over the page (a counter is just a special case)

so I assume that is always focused on a specific problem I have to debug.

Time passes and as said before globally cleaning all Stores by param or switch is a bad idea. Too many side effects if Stores get purged unconditionally. And to much effort for the benefit (if any)

  • HasShortcode catches only the shortcode for content what about hooks
  • having two pieces o code contributing to the store adds cleanup complexity
    cleanup code will have to explicit delete each set value and has to know which data has been created.

maybe a low hanging fruit would be a SCOPE.Store.Clear method or to make it more explicit as a debugging feature SCOPE.Store.DebugClear or debug.ClearStore SCOPE…

guess I’m done here