pass through gap data (target/met) values with rounding to 4 decimal digits [MRXN23-601]

[hotzevzl]

https://vizzuality.atlassian.net/browse/MRXN23-601

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
marxan	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 20, 2024 1:26pm

[hotzevzl]

@andresgnlez thank you for reviewing the tiny changes in this PR. I have checked the way this works and it all looks ok - one thing I should mention is that because of reasons, the ORM gives us these values as numbers-in-a-string now (basically, because the possible precision of the db types for these values may not "fit" within JS numeric types) -- so while this "works", I wanted to make you aware of this in case you can think of any possible caveats/edge cases with this.

Or maybe I should "just" re-cast these numbers-in-a-string to proper JS numbers in the API, and avoid getting numbers in weird formats to API clients to start with... I'd do this next week

[agnlez]

@hotzevzl happy to test this once is available in m23 instance, AFAIK the change is exclusive of the gap-data endpoint, isn't it? Let me know if you plan to extend this change through the codebase, if so, I might need to take a deeper look as we might be using Number methods straightforward in some cases or just the fact of having arithmetic operations between strings and number (they should work, but in JS world anything could happen 😬 ) scares me.

[hotzevzl]

@hotzevzl happy to test this once is available in m23 instance, AFAIK the change is exclusive of the gap-data endpoint, isn't it? Let me know if you plan to extend this change through the codebase, if so, I might need to take a deeper look as we might be using Number methods straightforward in some cases or just the fact of having arithmetic operations between strings and number (they should work, but in JS world anything could happen 😬 ) scares me

@andresgnlez I have just added a cast back from number-as-string to actual JS number via parseFloat() - so this should not cause unexpected new oddities. The cast to float should be fairly safe as we are already rounding the values to 4 decimal digits in the SQL view, so there's no chance we get values from db that cannot be held in a JS number without rounding. We should never get nulls or other funky (Infinity and beyond) values from the db either, but I'm handling these cases anyway.