Method.ts addContextListener signature was not updated for 1.2 and it overrides types for Desktop Agent

[kriswest]

Minor Issue

We noticed that Methods.ts hasn't been updated for the revised signature for addContextListener. The Methods.ts exports also override the DesktopAgent exports.

Desktop agent:

• v1.2.0 tag:

  FDC3/src/api/DesktopAgent.ts

  Line 151 in 4cef6a7

  addContextListener(contextType: string | null, handler: ContextHandler): Listener;

• master:

  FDC3/src/api/DesktopAgent.ts

  Line 151 in 0f240e8

  addContextListener(contextType: string | null, handler: ContextHandler): Listener;

Methods.ts:

• v1.2.0 tag:

  FDC3/src/api/Methods.ts

  Lines 70 to 78 in 4cef6a7

  	export function addContextListener(contextTypeOrHandler: string | ContextHandler, handler?: ContextHandler): Listener {
  	if (typeof contextTypeOrHandler !== 'function') {
  	return throwIfNoGlobal(() =>
  	window.fdc3.addContextListener(contextTypeOrHandler as string, handler as ContextHandler)
  	);
  	} else {
  	return throwIfNoGlobal(() => window.fdc3.addContextListener(contextTypeOrHandler as ContextHandler));
  	}
  	}

• master:

  FDC3/src/api/Methods.ts

  Lines 70 to 78 in 0f240e8

  	export function addContextListener(contextTypeOrHandler: string | ContextHandler, handler?: ContextHandler): Listener {
  	if (typeof contextTypeOrHandler !== 'function') {
  	return throwIfNoGlobal(() =>
  	window.fdc3.addContextListener(contextTypeOrHandler as string, handler as ContextHandler)
  	);
  	} else {
  	return throwIfNoGlobal(() => window.fdc3.addContextListener(contextTypeOrHandler as ContextHandler));
  	}
  	}

Further, we're finding that if you import FDC3 from the NPM module like so:
import * as fdc3 from "@finos/fdc3";
Then the Methods.ts exports take precedence and if you try and use fdc3.addContextListener(null, listener) you'll get a typescript error (however window.fdc3.addContextListener(null, listener) does pick up the right type.

We may need to reconsider how (or even if) these are exported in the index.ts file. I believe they take precedence as they are exported later than the DesktopAgent with the same function names. Some sort of namespacing maybe needed...

Area of Issue

[ ] App Directory
[x] API
[ ] Context Data
[ ] Intents
[ ] Use Cases
[ ] Other

[kriswest]

@mattjamieson Any chance you could take a look at/have a think about this one?

[kriswest]

Fix should be backported into NPM module for 1.2

[kriswest]

@mattjamieson @rikoe
Did you get a chance to think about the export issue (Methods.ts exports override DesktopAgent exports)? I think all that stems from the fact that you'll often import fdc3 like so:
import * as fdc3 from "@finos/fdc3";
which will overwrite the DesktopAgent type assigned to window.fdc3 (which is also in scope as fdc3) assigned here:

FDC3/src/index.ts

Lines 24 to 28 in 4cef6a7

	declare global {
	interface Window {
	fdc3: DesktopAgent;
	}
	}

It may not matter all that much when all the function signatures are in sync and a container provides the API at window.fdc3 (where Methods.ts references it from), but it did in this case.

The solution may be to move the export of Methods.ts under a namespace, e.g.
export * as es6 from './api/Methods';
that would be a breaking change as it would change how you do a restructured import, I'm not sure exactly what to however, perhaps:

import { es6 } from '@finos/fdc3'
const { getOrCreateChannel } = es6;

[mattjamieson]

Hey @kriswest, yes I've been playing with a couple of options. Should get the PR updated tomorrow.