Website: fix any types

[fengelniederhammer]

#3450 introduced a number of eslint ignore comments for the rule @typescript-eslint/no-explicit-any. any is harmful, because it essentially disables Typescript checks. You can access any method or field without Typescript complaining. In the long term it generates code that is harder to maintain (adding new features and refactoring becomes more dangerous because the type system can't guide you).

All of those should be fixed:

• If the type is really unknown, we should use unknown and make sure that the variable has a certain type before using it.
• If the type can be improved, we should replace any by a concrete type that is more useful.

See TODO comments in the code that reference this issue. Possibly split this issue into smaller subtasks.

[corneliusroemer]

In terms of priority, I think this isn't super high up, while it's nice to have everything fully typed, if it's not easy to fix then I don't think we should invest a lot of time.

I can't think of any bugs/runtime type errors we've had due to use of any.

Good point to consider unknown and narrowing as escape hatch though.

[fhennig]

I had a look at it and saw some things that I touched recently and quickly fixed a few things here: #3464

The remaining things are almost all in the SearchFullUI, and related to the lapisSearchParameters.

I can't think of any bugs/runtime type errors we've had due to use of any.

maybe not, but I think this point is still quite valid:

In the long term it generates code that is harder to maintain (adding new features and refactoring becomes more dangerous because the type system can't guide you).

I find reasoning about the lapisSearchParameters not so easy, because it's not really clear what's happening, there's even this:
https://github.com/loculus-project/loculus/blob/fix-some-any/website/src/utils/search.ts#L253 where the property changes type from string to string[] 😅 So you can't even be sure that a property you thought you knew the type of will have this same type at a different place in the code. I think this is the real, underlying thing to worry about; that missing types (that are not trivial to add) often indicate that the code itself might be difficult to think about, maintain and modify to add features.

I can't speak to the priority of this, just wanted to emphasize the maintainability aspect again (as opposed to a strictly runtime-error-focused PoV).

The unknown type is cool, I didn't know about it before!

[corneliusroemer]

Thanks for fixing some, that's definitely good!

For lapis search parameters, the real issue, I think, is the fact that Zodios spits out opaque types that are hard to work with. It's easy to look at LAPIS docs/swagger and see what the URL should be. It's hard to get a get/post to that URL with Zodios, it's not because of lack of typing, it's often precisely because of typing that it feels hard (at least to me). Zodios seems like a nice experiment but not really something to use in production, we should go with simple react query hooks for which there is plenty of documentation (instead of Zodios which is unmaintained and not too widely used).

Here's an example: Zodios technically just wraps around react query, but in such a weird way that it's easy to forget. Because it's not clear that it's actually react query under the hood we get patterns like this on the left: https://github.com/loculus-project/loculus/pull/3449/files#diff-5c10907a31647a2beff344b171ce8b089c4d29f436e83c764767ae9947d64c93

It's actually strange we need to use useEffect at all here, there shouldn't be any need to do so with react query.