What is `.Page.Store`?

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?

The only mention I found is in the Diagram doc.

2 Likes

That’s true.

1 Like

There’s an open docs issue:
https://github.com/gohugoio/hugoDocs/issues/1668

1 Like

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.

1 Like

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.
4 Likes

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 ?

The short answer is no.

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.

1 Like

from my experience …

if you can program in any language you know the scope of a variable.

.Scratch has a scrope, ex. in a range, in an IF expression etc.
.Store is valid in the whole page, why it should not change with hugo server …

hope. I’m correct