Weird Type Definition in Browsers.ts

[robmoffat]

Minor Issue

This is probably not wrong, but kinda weird:

export interface FindInstancesRequest {
    /**
     * Metadata for a request message sent by an FDC3-enabled app to a Desktop Agent.
     */
    meta: AddContextListenerRequestMeta;
    /**
     * The message payload typically contains the arguments to FDC3 API functions.
     */
    payload: FindInstancesRequestPayload;
    /**
     * Identifies the type of the message and it is typically set to the FDC3 function name that
     * the message relates to, e.g. 'findIntent', with 'Request' appended.
     */
    type: "findInstancesRequest";
}

why is meta specified as AddContextListenerRequestMeta?

[kriswest]

This is probably one of Quick types annoying type merges... The order that things are generated in affects which name is used. I may be able to work around that way... Alternatively, we really need the --no-combine-classes arg to quick type fixed.

If you see these check if they have the right properties. Also, bear in mind that you usually wouldn't import the oddly named type directly, rather just the top level type

[kriswest]

@robmoffat @Lecss @Roaders @Davidhanson90 I took a brief look at this again - the problem is that QuickType won't guarantee the naming of any sub-types it generates, only of the top-level types that we are generating (e.g. FindIntentsRequest, rather than FindIntentsRequestMetadata) and only where they have a unique title. There are some fudges possible that can guide it to a better name but they depend on the order that files are processed in and are fragile.

The top-level types are those listed at the top of the BrowserTypes.ts file in the sample import statement/Convert class code.

If we wanted to enable stable naming for the subtypes we might have to go as far as fixing quicktype (so the --co-combine-classes parameter actually works) as I think that, even if we change some of the metadata it will still try to combine some of the types where they overlap on 90% of properties. Hence, for now I would stick to trying to use the top-level types only and consider the rest to be an implementation detail you shouldn't interact directly with. Once I get ahead of the FDC3 for Web standard docs PR (no small task) I can try to circle around to quicktype...

Note AppRequest, AgentResponse, AgentEvent, IframeMessage and WebConnectionProtocolMessage should all be structurally compatible with all derived types and are top-level types, so you can use those as utility types in code that will apply to a wide range of messages.

P.S. I've just updated the generated BrowserTypes.ts file after a few corrections. Please pull the new copy and use that and let me know about any unexpected differences.

[kriswest]

P.S. we could/should control what you can import by re-exporting through index.ts as we do for everything else: https://github.com/finos/FDC3/blob/main/src/index.ts

I've yet to add exports for BrowserTypes to it... That could be done soon, at which point you'd be able to use npm pack to create a sample npm module to work against, simulating what you'd do when this is released (for anything other than the getAgent implementation itself).

[kriswest]

closing as complete - will revisit in review of FDC3 for the Web PR