Intrebari development

Workflow & Best Practices
1

M-am decis sa deschid acest topic ca sa caut raspunsuri la intrebarile mele sau confirmari / best practices la solutiile pe care le am deja sau o sa le am.

Si de ce nu acest topic sa fie folosit de fiecare persoana care are intrebari legate de development.

Prima mea intrebare este cum calculez CORECT pretul total al produselor in JavaScript:

const pretProdus = Number(599.99);
const costulTotal = pretProdus * 13

output JS: 7799.869999999998

expected output: 7799.87

Vreau sa stiu cum se face asta intr-o aplicatie reala care foloseste JS, fara costuri extra sau fara pierderi la calcularea pretului.

2

https://0.30000000000000004.com/

Cand este vorba de operatii floaring point, calculatorele o cam iau razna.

Si in general, Javascript nu este cel mai bun limbaj pt operatii matematice, din ce stiu

http://adripofjavascript.com/blog/drips/avoiding-problems-with-decimal-math-in-javascript.html

1 Like
3

Stiu si eu treaba cu floting point de asta m-am descis sa aflu de la cat mai multe persoane cum sa fac acest lucru pentru ca nu stiu ce stiu cum se foloseste in aplicatii reale.

vad ca cei din site-ul de mai sus recomanda decimal.js API
as vrea sa stiu daca se foloseste si in aplicatii reale gen magazine online.

Sau de exemplu ce folosesc mazaginele online sa calculeze pretul fara erori.

Si cat despre cel de-al doilea link asta inseamna ca trebuie sa transform prima data preturile de la float la integer sa calculez si dupa sa transform iar to float …

4

nu stiu ce folosesc, dar in consola browser-ului, arata rezultatul corect
image

2 Likes
5

Solutia asta merge si primesc rezultatul dorit.

6

Da
Aia era si prin al doilea link.

Si ceva imi spune ca pretul vine deja calculat corect din backend.

2 Likes
7

Asta e o treabă pentru backend.

Dar dacă și în backend ai tot javascript…

1 Like
8

Da, sa zicem ca pe partea de backend este to JS.

9

Cum am mai zis, operatiile matematice nu se fac in javascript. Indiferent ca e client-side sau server-side.
Si ca regula, clientul e bine sa fie “dumb” exact din cauza asta, nu pt ca nu se pot face aplicatii super faine cu “fat” clients.

Lucrurile serioase (de ex sa afisezi corect preturi si sume cos) le faci pe server, cu exactitatea dorita.
Sfatul e sa nu mergi pe nodejs serverside doar pt ca ti se pare mai usor de tranzitionat, mai sunt si alte argumente pt care nu e cea mai nimerita alegere.

5 Likes
10

Cred ca ar fi interesant pentru posteritate daca ai mentiona cateva dintre ele.

1 Like
11

Eu sunt la inceput, nu ma priecep, nu am lucrat niciodata in domeniu si invat singur. Din cate am citit node.js este destul de folosit si in aplicatii mari/foarte mari. De exemplu pentru un magazin online sa zicem ce ar trebui sa implementez pentru backend? Si aici ma refer mai mult la un starter project nu ceva corporate.

12

E destul sa fii consistent si aici e important sa scrii teste, poti face foarte bine calculele pe front-end daca e doar pentru previzualizare, dar mereu va confirma si backend-ul calculele la o comanda. Iar aici e mai dificil sa sincronizezi si e utila o librarie care e si pe backend si pe front-end. Problema e ca majoritatea librariilor vor merge incet si e aiurea sa folosesti functii in loc de operatori, deci nu le folosi pentru calcule care nu necesita precizie. Eventual lodash poate fi de ajutor daca vrei sa faci currying cu fiecare operator.

In general toFixed e de ajuns, JS by default face calculele destul de bine.

1 Like
13

Oarecum relevant:

https://news.ycombinator.com/item?id=28085642

1 Like
14

pretul oricum trebuie calculat 100% din timp pe server

preferabil nu in javascript. e importanta precizia sa nu faci salami slicing

15

Exista situatii in care nu ai nevoie de server, de exemplu afisarea pretului in alta moneda. Tot ce trebuie sa faci e sa te asiguri ca ai calcule consistente si pe front-end si pe back-end. Cateodata ai noroc, adica toFixed poate functioneaza exact la fel ca si in limbajul de pe back-end.

La o comanda trebuie sa confirmi comanda, dar daca faci o aplicatie de contabilitate pe front-end atunci e ok sa faci calculele cu JS, dar trebuie sa te asiguri ca poti sa explici de ce iti da o anumita valoare.

16

Nu asa functioneaza contabilitatea. Nu explicam de ce codul nostru a dat rezultatul gresit, ci folosim the right tool for the job ca sa ne asiguram ca obtinem rezultatul corect.

Este exemplul clasic de domeniu care nu se preteaza la a fi codat in js. Sunt limbaje mult mai bune si acelea trebuiesc utilizate.

1 Like
17

Nu exista rezultat corect, exista standarde si in contabilitate (care permit erori de rotunjire), care din cate imi amintesc se muleaza perfect pe tipurile din JS (am studiat o data problema asta, JS e ciudat si greu de inteles, dar face ce trebuie), exista inclusiv tipul de BigInt. Problemele apar cand se afiseaza ceva, dar s-a calculat altceva in spate si trebuie explicat de ce s-a facut asta. Asta ar interveni si de ai face calculele pe back-end.

Acum normal ca nu e vorba de contabilitate in productie ci de ceva aplicatie ca sa arati ca ai facut un program de contabilitate. Daca e sa ne ducem aici da, corect e sa ai un back-end spre care trimiti toate datele, ti le confirma si le trimite inapoi pentru afisare la fiecare operatie.

Majoritatea exemplelor horror cu JS sunt fara TypeScript, adica ajunge sa faca ceva ce n-ar fi trebuit din cauza diferentelor de tip. Orice aplicatie de front-end in 2021 trebuie sa fie cu TypeScript daca e scris de cineva cu ceva experienta. Mai bine zis, calculele se fac corect, dar daca nu ai TypeScript e foarte usor sa faci coercing de la un tip la altul fara sa observi cu functii precum Math.max/Math.min…

Ar mai fi bine de mentionat si sa aibe grija mare cu string si JSON.stringify/parse. JSON.parse va pierde din zecimale daca nu e string, daca vrei sa fii 100% sigur ca va fi parsat ca string adaugi ceva prefix la numar. (dar asta conteaza doar daca iti trebuie o anumita precizie, in multe locuri e de ajuns sa ai 3-4 zecimale si nimeni nu comenteaza)

18

Pentru că de ce să întreții și testezi 1 singur sistem când poți face asta cu 2 :slight_smile:

Cea mai proastă idee, 2 chestii paralele care să facă același lucru, când ai un bug, devii Indiana Jones :slight_smile:

3 Likes
19

Zici tu că dacă aș folosi TS nu ar mai exista problema asta?

image

2 Likes
20

N-are limbajul nicio treabă, e strict vorba de modul în care float/double este reprezentat (sau mai degrabă aproximat) in sistemul binar.

Pentru limbajele care nu au tipul “decimal” pur şi simplu pastrezi valorile ca integers, iar la afişare strecori separatorul zecimal la locul potrivit. Şi să nu uiţi că atunci când faci înmulţiri/împărţiri, separatorul zecimal se va deplasa la stânga sau la dreapta, astfel că rezultatul trebuie ajustat corespunzător.

2 Likes