Best practices for workshop navigation || variable-backed page changing not updating the variable on switch page event?

[Phil-M]

In our engineering organization we are formulating best practices. One goes in the direction of how to keep sanity to workshop modules (don’t deny it, you have all been there with 500+ variables ). So we are thinking through how to organize an application by embedding sub modules in a more structured way. I am seeking your opinion on two approaches (or if you have other ideas, please also share!)

See belows screenshot that describes two different scenarios. Both have in common that they have one main module acting as the landing page. In both scenarios the main module also has individual pages, however, they differ on how these sub-pages use sub-modules and how the general navigation is done.

The fist approach (screenshot → page 2 ) is to spare some precious real estate on main-module - page 2 (purple) simply for the Button that performs “switch page to landing” event. The actual content is embedded in a section “Sub module Page 1” on this page.
Works and is easy, but I dislike two things:

• we always have to spare real estate for the back to landing button
• In most cases we also use the left section with sub-page navigator (tabs) and have specific filter list just for that page. So in this approach the main module actually needs to hold these sub-page navigators and OTs just to show the different filter-list (which also need to be passed in as Interface variable)

(I hope you can follow so far)

The second approach (Screenshot → page 1) is to embedd the submodule on main - page 1 at full screen. So once you go from main to page 1, you will actually only see the content of the sub-module. This has the benefit, that we can really limit the OTs, etc. to what is necessary on sub module page 1.

Now the question with approach 2 is: how do you I best do the navigation back the main landing page? From the sub-module, I can’t trigger the switch page event at (parent) main module nor is there a “close self” event at the sub-module.

What is possible is to use variable-backed paging on the main module. The variable backing this is passed into the sub-module of page 1 as Interface. By clicking “back to landing” in the sub-module, we set the variable to the static page-id “landing” that switches the main module back to landing
What is not working is: When using the switch page event from main - landing to main - page 1 it will actually not automatically update the current-page variable to “page 1”. Since the current-page variable is still set to “landing”, clicking on the “back to landing” button in sub-module 1 will not trigger anything since there is no change in that variable.
Although I like this approach more, the only way to get this working, would be to always and exclusively use set variable to change the current_page variable instead of actual switch page events - also when i.e. just going from main - landing to main - page 1.

Long post, I hope you were able to follow, happy to hear your thoughts!

[evanj]

Hey, thanks for the detailed question!

We are internally tracking a feature request to be able to pass events on the module interface, but for now communicating with variables backing layout state is an endorsed pattern.

The Switch to page event docs do mention that it (for historical reasons) does not update the backing variable value, so yes in your case you should always use set variable value events to update the selected page.

---

I don’t know if I can give a fully informed read on if that makes this approach better, but there is something nice about encapsulating Workshop logic for a full page inside an embedded module.

---

don’t deny it, you have all been there with 500+ variables

I hear you on this one! Hopefully we will have some more tools to help address this in the near future, for now, using embedded modules to split up implementation of a larger module is a good pattern.

[Phil-M]

Thanks @evanj!

I actually figured out a convenient way to use both, the native navigation through switch page from main → sub-page and back from sub-page → main with variable backed state change.

The trick consists of two steps:

1. initialzie the current_page variable as null (not the page-id of your actual “landing” page). Since the landing page is configured as default, it will still start on this page, although the backing current_page string is not matching.
   

   
   
   
   

2. In the sub-module when clicking back home, reset first the current_page interface variable (will set to null) and then set it again.
   

   

Et violà

[evanj]

Ah nice - I guess the double variable setting is tricking our system into always picking up the variable update. That may work for now but I am a bit concerned that may have higher chance than normal of regressing with some future change. There’s probably a chance that the code to update the selected page does not run soon enough and both variable updates are processed before that codes gets a chance to run and we miss that the page variable updated.

I really would recommend following the docs recommendation to fully use the variable to control selected page state if you need the variable to stay in sync!

We may offer an option in the future to opt into updating the variable value on page change events similar to what we do for tab switch events.