[INQUIRY] Should we let the BigInts stay, instead of transforming them to number about lemmy-js-client

[dessalines]

Using BigInts caused a ton of issues in lemmy-ui, because javascript doesn't consider it a native number format, so we had to add a ton of hacks all around the codebase. Finally we realized it wasn't worth it, and we should just treat numbers from the back end as if they're numbers.

There are floats now, the ranks are now floats, and for some reason ts-rs used the javascript type number for them, so it should be okay.

We can re-evaluate this if it becomes a problem, but so far it hasn't been an issue.

(This came up during my Lemmy_openapi_spec which generated now with all the id as number instead of ints, which is problematic for the consumers of this spec)

In that case we could change the copy_generated_types script to replace all the ID columns with bigint, but leave everything else alone. But it doesn't seem too worth it IMO, these aren't columns that you ever alter in any way.

[MV-GH]

For Lemmy_openapi_spec we can get around this by generating our own types in which we keep the bigInts. For that it isn't a problem. Atm I am more worried about Jerboa, I am not sure how Retrofit2 handles float to int conversion. And the consequences if we ever use those float as int attributes in the Jerboa. Maybe we should keep a manual list of floats to override it. But that does mean that Lemmy-js-client is not a ideal source for types. Maybe it is possible to annotate or comment the original type for numbers so that consumers of those can appropriately use the right type.

[dessalines]

Atm I am more worried about Jerboa, I am not sure how Retrofit2 handles float to int conversion.

oohh yeah. That means the jerboa ts -> kotlin script will need to be fixed. Javascript number is actually not an int, but a float. javascript didn't even have an integer type until bigint a few years ago.

[RonSijm]

Chiming in because I initially opened this issue on MV-GHs Repo:
MV-GH/lemmy_openapi_spec#15

For context: The specs library uses this lemmy-js-client repo as source to generate specs. Because of this, the conversion from bigInts to floats in this project causes the int parameters to be floats in the openapi too.

My idea to solve transcribing would be to disable the transform from BigInt to number line

(Would that work, disabling that line?)

Obviously doing that inside the specs library would increase complexity, since the pipeline is no longer just pulling it lemmy-js-client - but first pulling in Lemmy-rust itself, and then custom generating a new client without type conversion

So that's the context for this issue, and what we're trying to solve, and why the int to float conversion messes with the api-spec.

Maybe someone has an idea how to best approach this?

[dessalines]

Why can't the ts -> openAPI generator handle this? javascript doesn't have a native integer type (except bigint, but it's got issues) . The type in javascript is Number, and that is a float.

I'm remembering now a bit about why we moved away from bigints: they had major issues with serialization.

[MV-GH]

because the type is number, we don't have the information to know if it should be float or a integer. (We can get around this like I said before by manually generating the custom types that do keep bigInt) Or we can use the solution in the PR. This also makes it so Jerboa and probably other consumers can easily make a distinction between floats and integers.

[dessalines]

I'm willing to do this, but I have a feeling we'll run into problems with lemmy-ui again.

[MV-GH]

? How would the comments affect lemmy-ui ?