Ready Event before FDC3 API can be called

[sgd2z]

Enhancement Request

We would like to propose adding a ready event before FDC3 API can be called and a ready state global.

function fdc3stuff() {
  // Make some fdc3 API calls here
}

if (window.fdc3Ready) {
  fdc3stuff();
} else {
  window.addEventListener("fdc3Ready", fdc3stuff);
}

Use Case:

Calling the DesktopAgent API generally requires that the Desktop Agent is ready to broadcast/receive data which generally relies on some underlying infrastructure to be ready.

For example:
In a Desktop Integration Platform like Finsemble where communication happens between different components, it is necessary for the communication channels of the platform to be ready before fdc3 API can be called. Also, the fdc3 API itself relies on a a service or other infrastructure outside the component, which needs to be ready before it can be used. So calling any fdc3 API as soon as a component starts up might fail.

Just adding a ready event however is not enough because sometimes, the ready event has already occurred before any checks are made. So we would like to propose adding a global ready state that can be checked in addition to the ready event.

[rikoe]

I would prefer:

await window.fdc3.onReady()

to adding another top-level global primitive - this is already a smell so let's not make it worse.

In addition, an async function feels more like modern JS as opposed to a window-level event.

[sgd2z]

@rikoe while that is simple, in real life use cases does not work. You cannot ensure that window.fdc3 even exists, which is why it must be window event based. Also I'm not sure top level await is even a thing yet so your await must go into an async function anyway.

[rikoe]

@sgd2z Fair enough - I think we should discuss this during the WG meeting. I don't understand the implications of this fully. But it would be great if we can find another way to do it. We have a request to port the API to .NET etc., so we don't want to rely on the window object too much. According to the spec, window.fdc3 is a SHOULD not a MUST.

When we discussed this in the past, people were in favour of an import pattern is opposed to a global object pattern, perhaps we should revisit this.

Just so I understand fully, why can't you ensure window.fdc3 exists, is it about the delay in getting services ready until the object can be created? I am probably showing my ignorance here, but couldn't you create a lightweight proxy object that is available pretty much immediately?

[sgd2z]

Using an import pattern might not work for desktop integrators like us because we preload all the default functionality into the browser as part of the platform and we use a similar pattern for our own ready event. And there is no guarantee that the preload finishes execution before your own code uses it, which is why an event is needed. However to make sure that you didn't miss the event, you need to also check state. I think the same pattern would apply to .NET

if (FDC3.ready) { fn() } else FDC3.addEventListener("ready", fn)

However, in the browser world, we likely need an event on window as opposed to an event on the fdc3 object.

[kriswest]

@rikoe FYI we've seen other implementations of the desktop agent with similar issues (resulting in nasty hacks like checking for window.fdc3 in setTimeout loop for X iterations then giving up). I believe Johan @ Factset can corroborate that.

[rikoe]

@kriswest @sgd2z I am in agreement that a readiness check is needed (it has come up before), I am just questioning the mechanism. We already had a lot of opposition to adding fdc3 as a global object to window during the 1.1 timeframe, which is understandable, as it is an anti-pattern in modern JavaScript. (Which is incidentally one of the reasons it is a SHOULD in the spec, and not a MUST.)

Adding two extra global elements (event+flag) just for readiness seems to make an already bad situation quite a bit worse. I realise this is what you found you need to do for your implementation, but the implementation of a particular desktop agent shouldn't leak into the standard, unless it is unavoidable.

I think we should investigate whether there is a technically feasible way to hang everything off the global fdc3 object, if there is not, I am happy to defer to the JavaScript experts on this (I am not one...).

[sgd2z]

@rikoe

function fdc3stuff() {
  // Make some fdc3 API calls here
}

if (window.fdc3 && window.fdc3.ready) {
  fdc3stuff();
} else {
  window.addEventListener("fdc3Ready", fdc3stuff);
}

How about that for a minor change to the initial code so everything hangs off the global fdc3 object.

[nkolba]

I could see having a standard fdc3Ready event that fired on the window object when in a browser context. However, having the ready flag on the FDC3 object itself seems overly complicated - the fdc3 global should only exist when it's ready.

[sgd2z]

@nkolba that sounds good. So the end user code would be

function fdc3stuff() {
  // Make some fdc3 API calls here
}

if (window.fdc3) {
  fdc3stuff();
} else {
  window.addEventListener("fdc3Ready", fdc3stuff);
}