Comments (8)
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.
from lemmy-js-client.
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.
from lemmy-js-client.
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.
from lemmy-js-client.
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?
from lemmy-js-client.
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.
from lemmy-js-client.
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.
from lemmy-js-client.
I'm willing to do this, but I have a feeling we'll run into problems with lemmy-ui again.
from lemmy-js-client.
? How would the comments affect lemmy-ui ?
from lemmy-js-client.
Related Issues (20)
- `/* integer */` comments seemingly aren't applied accurately HOT 15
- Add new TOTP functions
- Missing deleteImage endpoint HOT 2
- Issue with `getSite` and `auth` HOT 2
- Could you do merge squashes instead of merges HOT 1
- Missing 0.19.X endpoints: user export and import
- Add auth indication HOT 8
- Exports types that aren't used HOT 2
- Add user import / export HOT 1
- Missing /user/logout endpoint
- Generate changelogs/releases automatically HOT 1
- Warning: punycode module is deprecated HOT 1
- Datatype `ImageUpload` is exported but not used HOT 2
- getSite() not returning user info HOT 1
- `exportSettings()` returns `any` instead of a concrete type HOT 2
- "uploadImage" method fails in Node.js HOT 3
- Remove `form-data` and `cross-fetch` dependencies
- Datatype OpenGraphData is exported but not used HOT 1
- Dependency Dashboard
- Missing endpoint `PUT user/change_password`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lemmy-js-client.