Currently stumbled on this thread solution by @jmooring and realized I had never seen this page variable: .Store. Is it a Scratch alias or a shortcode-only storing scratch-like feature I completely missed?
Oh yes and I can see I engaged in the issue behind its implementation. I think I never got the subtlety of it. By what I can grasp, it’s only relevant in server mode.
I still don’t really understand this. I have a helper partial that just increments a number so I can have unique IDs throughout my page. Should it be using .Scratch or .Store? Does it matter?
I would use .Store for that. For regular hugo it doesn’t matter. .Store was added to primarily solve the use case of
A shortcode is using the .Page.Scratch to pass up some value to the calling template.
It works fine on first render.
Then, on change, we reset all the Scratch pads, but the shortcode is not re-evaluated, so templates depending on the value from the Shortcode now misbehaves.
.Store will never be reset, so it survives rebuilds.
so it is only reset/recalculated on production builds ?
Is there a way to reevaluate those objects only if a page has been changed since last build, as is done for processed image assets ?
I have development branch that solves/improves most of these issues, but it’s incredibly complex when you consider 1. The very open ended API and the amount of stuff that Hugo integrates with and 2. You want to do as little as possible on server reloads. I have slowly introduced the building blocks for the above.