-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updates from impl review #1424
Updates from impl review #1424
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a solid set of changes that will reduce the number of warnings from linting through better typing. I'll make a couple of quick changes to deal with some of my comments.
@robmoffat once done, I think you should merge this. I'll need to deal with some conflicts in my branch thereafter.
@@ -1,6 +1,6 @@ | |||
import { Connectable, AppIdentifier, ImplementationMetadata } from "@kite9/fdc3-standard"; | |||
import { RegisterableListener } from "./listeners/RegisterableListener"; | |||
import { AddContextListenerRequest, AddContextListenerRequestMeta } from "@kite9/fdc3-schema/generated/api/BrowserTypes"; | |||
import { AddContextListenerRequestMeta } from "@kite9/fdc3-schema/generated/api/BrowserTypes"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only top-level types should be imported from BrowserTypes (as the naming of the lower-level types can be unstable),. Hence, I'd import AppRequestMessage
and then extract the type for its meta element:
import { AppRequestMessage} from "@kite9/fdc3-schema/generated/api/BrowserTypes";
type RequestMetadata = AppRequestMessage["meta"];
then use that down on line 33.
(m.type == expectedTypeName) | ||
&& (m.meta.requestUuid == message.meta.requestUuid), errorMessage) | ||
this.post(message) | ||
const out: any = await prom | ||
const out = await messageResponseWaiter | ||
// @ts-expect-error: TODO: We should make a list of all of the possible messages that can be called through this, and make that list the generic. This will ensure better type safety. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty sure that relevant types already exist for that: AppRequestMessage, AgentResponseMessage, AgentEventMessage were intended for such usage and contain unions of the relvant type strings for messages in their set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those types can't be easily applied yet due to these functions serving both WCP and DACP - I'll fix this in my branch where I've unpicked that already
getImplementationMetadata(): Promise<ImplementationMetadata> { | ||
return Promise.resolve(this.implementationMetadata!!) | ||
async getImplementationMetadata(): Promise<ImplementationMetadata> { | ||
if(this.implementationMetadata === null){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reasonable to throw an error - where I hit this in another branch I generated impl metadata with "unknown" values. It shouldn't happen, but it pays to be defensive and to handle the error if it ever comes up.
if(this.implementationMetadata === null){ | ||
throw new Error("Unconnected. No metadata available.") | ||
} | ||
return this.implementationMetadata | ||
} | ||
|
||
private async exchangeValidationWithId<X>(message: any, connectionAttemptUuid: string): Promise<X> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm moving the identity validation into the Loaders and out of here in another branch. Its part of the connection flow for Web and should be separated from messaging (that could be used with a different connection).
@@ -26,9 +26,9 @@ export class TimeoutLoader implements Loader { | |||
this.done = true; | |||
} | |||
|
|||
get(params: GetAgentParams): Promise<DesktopAgent | void> { | |||
get({timeoutMs = 0}: GetAgentParams): Promise<DesktopAgent | void> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a constant for the default timeout elsewhere - but I'm also eliminating the timeoutLoader in another branch (with id validation moving into the loader, loaders can do some ops outside of the timeout so they need to manage the timeouts themselves
packages/fdc3-get-agent/src/ui/DefaultDesktopAgentChannelSelector.ts
Outdated
Show resolved
Hide resolved
packages/fdc3-get-agent/test/step-definitions/intent-resolver.steps.ts
Outdated
Show resolved
Hide resolved
Resovled conflicts @robmoffat - this should be ready for you. One thing to watch out for: don't import the various generated types in BrowserTypes other than the top-level message types, as the naming of the autogenerated types may be unstable. That also goes for constants used for message
|
TypeError: Class extends value undefined is not a constructor or null at Object.<anonymous> (/home/runner/work/FDC3/FDC3/packages/fdc3-get-agent/src/ui/DefaultDesktopAgentIntentResolver.ts:11:1)
Have you tried running the tests on this @kriswest? I get this error (consistent with the coverage run):
This might be fixable by merging main back into the branch, perhaps? |
Yes, I don't know why thats happening. I merged main into this branch a couple of days ago which is actually when this started. Its an issues with a class trying to extend something that it can't find (which is therefore undefined). That could be an error in the codebase - but it probably should blow up on compile if thats the case (although the current build is not bundling as its just using tsc), or it could be an issue with a dependency... |
@robmoffat found it! It was the import of FDC3_VERSION in packages/fdc3-get-agent/src/ui/AbstractUIComponent.ts. The PR fixes an incorrect payload in an I've corrected the dependency by moving the FDC3 version into its own file - although that should probably be moved to the top of the dependency chain (fdc3-standard package)? That then revelaed some other issues (unused imports in tests). I've corrected those and now it runs, but seems to get stuck, its also timing out in a few tests - I'm not sure why. Could you run the tests and see if you can replicate? I may be on a different node version to you (20.11.1) which might make a difference |
P.S. It gets stuck at the end of the tests (for the fdc3-get-agent package) I believe. Its just not exiting. Its already printed the summary. |
No description provided.