UI Builder Caching On Link To Destination/Redirect

[Kevin Schaub]

I am working on a scoped application in my PDI that is leveraging UI Builder for the front end. When I do a "link to destination", then navigate back to the previous page the page appears immediately (data resources don't appear to refresh), and the values I typed in the inputs and didn't save persist. 

It appears that the UI is caching everything? Anyone else have this issue?

[Brad Tilton]

UIB created experiences have some pretty aggressive caching where navigating to a page that is already in the cache gives you the cached version of the page. There is a hack that some people have had success with, though. When you change or add a url parameter to a page it should cause the page to refresh, so I've heard of people adding the current date/timestamp as an optional parameter for the page you're navigating to and then changing that when you want the page to refresh.

I will admit that I've had pretty limited success making that work.

[SNOLH]

Any update on this? I am using extra parameters in the filters for my data resources, but when I link back to a previous page after changing the extra parameters, it does not refresh the resources using these modified parameters. It only does after i manually refresh the browser. Is there a way to refresh the page automatically after linking to destination? 

[Brad Tilton]

You might also try the record watcher data resource. You can monitor a table and refresh a list based on that.

[John Rissone]

yea, so we've encountered it too and are meeting with the UXR team who owns the page caching logic to and will try to convince them that the URL it navigated to and page the user was taken to, do not match. They pulled up the cached version of that page and then edited the URL params without "hitting enter". The page obviously won't respond as this is a different pipeline than the one that executes on page refresh which I tried explaining. It would be like editing the URL of an amazon page and updating the sku for the product without hitting enter and expecting the page to update. That's not a normal flow. In the first mtg with them, they advised to use the MACROPONENT_PROPERTY_CHANGED event to handle, but I explained that's a lot of work to do for each property that was removed from the URL especially since there are other handlers for that event and discerning the two would be complicated. 

I did look at creating a handler to restore props that were removed since in the event you have access to both the previous value and the new value, but it's just too messy and adds unnecessary complication to the page. 

The temp workaround we used was to use the external URL field to navigate which refreshes the target page, but blows away the cache for other tabs you had open. So not ideal. 

We have another mtg with UXR coming up and will enter a defect for not navigating to the provided URL. The URL is a bare URL without any params, but the page they bring out of cache has a record showing so it doesn't match the URL. At the end of the day UXR is not taking us to the requested URL so it's definitely a bug IMO. I don't sew how they can't fix that. So TBD.

In the meantime, the timestamp workaround idea that is being thrown around is messy, but can get the job done and the way it works is to add a new required param to the page that you pass in each time you navigate. You'll have to use the "script view" of the OOTB "navigate to page" handler so you can call Date.now() for your extra param you'll pass in. Then the idea is that the since the URL is different it'll bust the cache and have to refresh the page. 

Also keep in mind there's no way to refresh the page for the page you're in, inside of UXF/UIB code while maintaining the workspaces cache of other tabs/breadcrumbs. Only option is to navigate back to the same page using the external URL route which is the same as just coming into the target page with external URL route already set. No need to do it from within the page itself.