Skip to content
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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

pjonsson
Copy link
Contributor

What this PR does

Add some types for the options in
ServerConfig. This uncovered a missing
check in sendFeedback.

Test me

Tested by CI.

Checklist

  • There are unit tests to verify my changes are correct or unit tests aren't applicable (if so, write quick reason why unit tests don't exist)
  • I've updated relevant documentation in doc/.
  • I've updated CHANGES.md with what I changed.
  • I've provided instructions in the PR description on how to test this PR.

declare class ServerConfig {
config: unknown;
init(serverConfigUrl: string): Promise<unknown>;
config: ServerConfigOptions;
Copy link
Contributor Author

Choose a reason for hiding this comment

The 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 ServerConfig.init() that uses the cached configuration is only called from Terria.start(), and that call is always done directly after new ServerConfig(). To me, it seems it would have been easier to have ServerConfig.init() be the equivalent of a static function in other languages so ServerConfig object would never have to be allocated at all.

Copy link
Collaborator

Choose a reason for hiding this comment

The 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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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.

newShareUrlPrefix?: string;
shareUrlPrefixes: object;
additionalFeedbackParameters: object[];
}
Copy link
Collaborator

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.

Copy link
Contributor Author

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.

shareUrlPrefixes: object;
additionalFeedbackParameters: object[];
}

declare class ServerConfig {
Copy link
Collaborator

Choose a reason for hiding this comment

The 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

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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.

Copy link
Collaborator

Choose a reason for hiding this comment

The 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.
Thanks for all your work, you are doing an amazing job splitting everything into small PRs

declare class ServerConfig {
config: unknown;
init(serverConfigUrl: string): Promise<unknown>;
config: ServerConfigOptions;
Copy link
Collaborator

Choose a reason for hiding this comment

The 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?

@pjonsson pjonsson force-pushed the type-serverconfig-more branch from 0623159 to 937d4db Compare November 24, 2024 11:13
Add some types for the options in
ServerConfig. This uncovered a missing
check in sendFeedback.
@pjonsson pjonsson force-pushed the type-serverconfig-more branch from 937d4db to 35f9a35 Compare December 9, 2024 09:51
@pjonsson pjonsson mentioned this pull request Dec 25, 2024
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants