-
Notifications
You must be signed in to change notification settings - Fork 363
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
ServerConfig.d.ts: add types for options #7328
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,6 +1,18 @@ | ||
export declare interface ServerConfigOptions { | ||
version: string; | ||
proxyAllDomains: boolean; | ||
allowProxyFor: string[]; | ||
maxConversionSize: number; | ||
newShareUrlPrefix?: string; | ||
shareUrlPrefixes: object; | ||
additionalFeedbackParameters: object[]; | ||
} | ||
|
||
declare class ServerConfig { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What do you think about converting the entire ServerConfig class to typescript? it is relatively small and it would be easier then to have an additional declaration file There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well, I know type systems so I'm happier the more types I get, but #6466 has been sitting for several years by now. I would rather get this PR merged in its current form so we get some improvements than have another "perfect" PR that sits around for 6+ months waiting for someone to look at it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @zoran995 re-reading my comment made me realize that it could be interpreted as criticism against you, and that was absolutely not what I meant, so I apologize for that. I'm grateful for all your help, there's not a chance in a million years I would have found the issue with createRef/useRef that you brought to my attention in #7213. I'm still running with my training wheels with TypeScript/JavaScript, so I TSified something that already had complete type annotations in #7330 instead. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No worries at all - I didn't interpret it as a criticism, don't worry. I also "hate" that PR for staying open for so long and being that big. |
||
config: unknown; | ||
init(serverConfigUrl: string): Promise<unknown>; | ||
config: ServerConfigOptions; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's not for this PR, but I find the ServerConfig design a bit puzzling, the object caches a configuration, but There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This way server endpoint will be called only once, or do you mean about the server config stored in the terria class? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My point is that terria.start() looks like this: this.serverConfig = new ServerConfig();
const serverConfig = this.serverConfig.init(...); so init is only called immediately after new, and the cache will never be used. The ServerConfig object could just as well have been omitted and the code looked like this instead: this.serverConfigOptions = mkServerConfigOptions(...); which would omit one level of indirection (and save a few bytes of object allocation), and otherwise have provided the same performance characteristics. |
||
init( | ||
serverConfigUrl: string | undefined | ||
): Promise<ServerConfigOptions | undefined>; | ||
} | ||
|
||
export default ServerConfig; |
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.
p.s. It might be better to define this interface in
terriajs-server
, but from the top of my head, I am not sure if it is possible.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 have PRs on both terriajs-server and TerriaMap from early May that are still sitting in the queue either approved or without any comments (and some of them are ~one-liners), so I feel that even if you are right on a technical level, it's unlikely to be productive for me to try to migrate existing interfaces between repositories.