Fire function only on the intial load of profound app

[JayGoo83]

Is there a way to call a js function only once when the page loads initially?
I have a function that is currently being called on my main screen onload field in visual designer.

This function makes an ajax request with a setTimeout of 6000 and then the function calls itself. This is to keep the data real time.

Code: Select all

function makeRequest(){
  var program = pui.get('PROGRAM');
  if(program !== 'CL5001RP'){
    return;
  }
  
  var url = pui.get("envURL");
  $.ajax({
    url: url,
    method: "get",
    dataType: "html"
  })
  .done(function(resp){
    var json = JSON.parse(resp);
    if(json !=''){
      pui.set("data1",json.data.data1);
    }
    setTimeout(makeRequest, 6000);
  })
}

What i'm noticing is that when the main screen reloads, which is what happens when i click on something on the screen, a new sequence of timeouts is started. What i mean is that the stack is backloaded with all of these requests and i'm making my ajax call every second. This is not the desired behavior.
I tried doing something like

Code: Select all

window.onload = function(){makeRequest()}

but this breaks profound, meaning i cannot even start a new session. So what I would like to do is call a function one time when the app loads

[Scott Klement]

Jay,

Can I assume you are coding for Profound UI? (As opposed to Profound.js, RPGsp or another tool that we offer.)

It's important to understand that Profound UI is a Single-Page Application (SPA). That means that when you begin your Profound UI session, a web page is loaded, and kept active throughout the entire session, no matter how many different screens you visit or programs you run during the session, it continues to use that single page.

If I take your question 100% literally, you want to run the makeRequest() immediately when the page is loaded, and then never again. Honestly, though, this doesn't make sense since you're expecting specific widgets (id=PROGRAM, envURL) to be on the screen already. If you did this when the page first loads, there would be no screens displayed, yet. So, I'm assuming that I shouldn't take it 100% literally :-)

But, with that in mind, what do you mean, exactly? When precisely do you want your timeout to begin, and when do you want it to end?

A few ideas come to mind:

IDEA 1: If the only problem is that the timeouts are building up, save the timer object from the onload event, and cancel the timer during the onsubmit event. You can save it by attaching the timer to the built-in window object, which will remain in memory until the browser tab/window is closed. Customers do this frequently using code like this:

Code: Select all

(onload)
window.JayGoo83_Timer = setTimeout( makeRequest, 6000);

Code: Select all

(onsubmit)
if (window.JayGoo83) {
  window.cancelTimeout(JayGoo83_Timer);
  window.JayGoo83_Timer = null;
}

You would also want to set the JayGoo83_Timer object=null at the start of the makeRequest() function. And set it to the new timer when the setTimeout() is run during the .done() portion.

This would be very simple to code -- but, the 6 second delay will be reset every time the screen is submitted to the server, which may not be what you want? But, this is the most common thing that customers do because its difficult to deal with things if the screen could potentially change in between the setTimeout() and the makeRequest() running.

IDEA 2: Instead of submitting the screen, use AJAX for all communications with the back-end during the life of this screen. That way, you can still cancel the timer during the onsubmit event, but there'd be no screen submissions except when you exited the screen...

IDEA 3: Depending on what you're trying to achieve, you could actually do what you asked for and start the timer when the page initially loads. You'd do that by coding the initial setTimeout() as part of your start.html file. The way you've written makeRequest() would need to be very different, though, as the screens in the session could change to just about anything -- so you'd have to write it in a way that it could handle any sort of screen, or detect that the proper screen isn't there and simply not update, or whatever seems appropriate to you.

CAUTION: Another important note (which is also causing headaches for us with our applications here at Profound) is that Google recently changed the behavior of the Chrome web browser. The new behavior is that when the browser has been in the background for a certain length of time, it will only fire the setTimeout() or setInterval() events once per minute. Since you mentioned that you want to keep your data "real time", this may be problematic for you. More info here: https://developer.chrome.com/blog/timer ... chrome-88/

[JayGoo83]

Thanks for the thorough response. I did a variant of Idea 1, although I think your approach is much cleaner. I didn't think about using the other end of the process, the onsubmit, to end the timeout.
Thank you so much.