A quirk of using page scoped Stacks controls
While working on the development of a new feature for Alloy a beta tester came across a strange quirk in the way Stacks handles page wide variables, and I'd like to go over just what this behavior is and how you might be affected.
Stacks introduced page scoped controls a while back for developers. With this added feature it meant that different stacks could be written to share variables.
For instance one stack might have an input control to allow you to set the text for a label. That stack would provide you a control in its settings and then whatever you type into that input would be stored in a variable and the stack could use your text to populate a label in that particular stack.
Normally the stored data would only be accessible to that stack, which is a good thing. But as a developer we now have the ability to choose to allow that variable to be shared across different stacks, or even page scoped files within a stack. This means that text you enter into the input control can be used to populate a label in a totally different stack for example. This is super powerful stuff.
Alloy’s Page Scoped Controls
Alloy has been using this feature for its Posts Folder, RSS settings, etc. for a while now, allowing me to use the values of these controls on a page-wide basis. You’ll notice these controls have a light blue background behind them to indicate that they are page scoped controls. Here’s a look at the controls for the Alloy stack:
These page scoped controls are amazing and work wonderfully as a part of the Stacks API. I flat out could not do some of what I do inside of Alloy without these controls. That said though, there is a small quirk with how they work at the moment when it comes to using them inside of Partials.
When added to a Stacks Partial these page scoped controls act differently than you might expect. If you place the main Alloy Control Center stack in a Partial and add that Partial to a different page, and then change one of these page scoped controls’ settings, that change will not be propagated over to the other instances of the Partial as you’d normally expect. Each page scoped control, those with the blue backgrounds, within each instance of the Partial, will retain their value until it is changed manually in each Partial.
Let’s take the new Time Zone control for example, which comes as a part of the free Alloy v2 upgrade. If I were to change the Time Zone setting in our partial example from above, it would change only in the specific instance of the partial where we make the change. The Time Zone would remain set to its original setting in all other instances of the partial. You would need to go and change that setting in each of the Partials to ensure they all match. This is how we found out about this quirk related to page scoped controls during our beta testing.
Is this a bug?
Let me be clear, this is not a bug. I don’t want anyone thinking it is. I have spoken to the Stacks developer, Isaiah and it definitely works this way right now for a reason. So why do I bring it up then? Because I think it could lead to confusion or problems for users if you don’t know about how it currently works.
So what do we do about this?
Since the Alloy Control Center is not a stack that really needs to be made into a Partial I think we’re ok for now. At most you’ll only be using the Alloy Control Center stack on a few pages, so it makes keeping the settings between the instances of the stack pretty easy through just copy and paste for now. If you make a change in the Alloy Control Center stack on one page you can simply copy and paste that stack on to the other pages where it exists in your project, or manually update the settings in those instances.
Also, the Alloy Control Center stack is the only stack in the bundle that uses these page scoped controls. This means you can still make stacks like the Recent Posts, Categories List, and Blog Entries stacks into Partials with no problem whatsoever.