Fluid UI | Back Button Considerations

I wrote about the Back button considerations for Fluid development in a previous post.

If we navigate to any component, then by default PeopleTools would track this navigation in the psback cookie which is used by the Back button.

Also, if the component contains multiple pages and if we navigate across pages within the same component, then those navigations are not included by default in the navigation history.

Demo

For the purposes of this demo, I am using the same component which I created for one of my previous posts - Fluid UI - Working with Grids.

Project: https://github.com/SasankVemana/Fluid-UI-Grid-Demos 

As we can see in the example, the Back button does not record any of the internal page navigations within the same component. This is actually the expected/default behavior and should cover most use cases because it is not commonly a requirement to track the internal page navigations.

But what if we want to track the page navigations within the same component in the Back button history?

There is a very simple option to do just that.

Component Properties > Fluid (Tab) > Component Attributes > Page Navigation in History (Property)

Demo

In the above demonstration, we can see that setting the 'Page Navigation in History' component property allows us to track the page navigations within a component (if required). This can also be programmatically achieved using the PeopleTools built-in 'SetTransferAttributes' function as described in my previous post here.

Fluid UI - Custom Development - Back Button History

I recently came across a requirement that made me aware of a new and interesting design consideration for Fluid development. When we design and develop Classic pages, we never had to worry about a 'Back' button and how it behaves in the context of user navigation.

Fluid 'Back' Button:

Let us say that we made a customization to the 'Personal Details' page so that on page load, we redirect/transfer the users to a custom component/page and then once done with custom activity we redirect/transfer them back to the 'Personal Details' page. Now if the user clicks on the 'Back' button on the 'Personal Details' page, we expect them to go back to the Fluid Home Page. But since we had an additional custom navigation, the user navigation 'History' alters the behavior of the 'Back' button. Sometimes, it may be desirable but what if it is not how we wanted the navigation to flow? How do we control the 'Back' button behavior and user navigation 'History'?

In my example, the 'Personal Details' page redirects to 'Custom Activity' page. Once we click 'Continue' (custom activity) the user gets redirected to the 'Personal Details' page.

There is a very simple solution to this problem and it involves just invoking a delivered function. But before I provide that solution, I wanted to share what I learned in the process. It is interesting to know how it works behind the scenes. This is just for informational purposes and it is not recommended unless you have a really complex requirement!

My Initial Approach:

Since, I could tell that there is some javascript that is tracking the user navigation, my first thought was to write some custom javascript to manipulate the 'History'.

Basically, I realized that we had to either prevent or clean up behind this AddToHistory function in the page javascript.

After digging into delivered javascripts, I found the clearHistory() function in the delivered PT_COMMON HTML object.

If we use the delivered clearHistory function, then it would clear the entire 'History' except the last navigation. So, I created a custom function (cskClearHistory) based on the delivered code. My custom function removes everything from the 'pt_history' object except for the first item (which should be the Home Page). I am sure there could be a better way to manipulate the 'History' and make the javascript more efficient but this seems to work for a proof of concept!

Javascript for Reference:

function cskClearHistory() //can be called by app component
{
    var pt_history = getHistoryObject();
    if (!pt_history ||  pt_history.size() <=1) return;

    // Pop everything out except first item (Home Page)   
    while(pt_history.size() > 1) {
       var lastRec = pt_history.pop();
    }
    pt_history.save();
}

I just invoked this javascript on my custom page activate peoplecode event as follows:

Now, when I navigate the same route (Employee Self Service (Home Page) > Personal Details --redirect--> Custom Activity --continue--> Personal Details, the 'Back' button points back to the 'Home Page' as expected/desired.

After writing this javascript and getting this to work as expected, I realized that this is still not a very efficient way of managing the user navigation 'History'. Sure, the javascript manipulation of the 'History' might be useful for some more complex scenarios (which was the purpose of my demonstration above) but definitely not a great idea for simple page transfers. Eventually, after digging into some of the existing Fluid pages, I found that there is a delivered function called SetTransferAttributes that helps us with these sort of transfers.

PeopleBooks Reference

Recommended Approach:

I got rid off all the custom javascript that I injected on page activate peoplecode. I just added this one line of code to my 'Continue' button before the transfer to set the transfer attributes appropriately.

PeopleCode: SetTransferAttributes(False, False);