Intrebari development

E la fel si in Python, ai IEE754 si in C++ sau Java cu strictfp. Daca nu precizezi exact ce sa foloseasca pe backend se schimba in functie de compilator si platforma cu Java de exemplu.

In schimb in PHP scrie ca implementeaza IEE754 dar evident nu face asta, sau mai bine zis ascunde acest lucru in functiile de formatare.

Şi apropo de chestia asta cu binary float, am aflat hard-way care este o idee PROASTĂ să compari două variabile de tip float :slight_smile: La un moment dat am căpiat încercând să-mi dau seama de ce naiba “a == 0.” dadea UNEORI false, deşi “a” părea să fie ÎNTOTDEAUNA zero. Atunci am aflat şi eu de “epsilon”.

https://noobtuts.com/cpp/compare-float-values

4 Likes

Dureri de cap, mai ales daca lucrezi cu bani. Calculele se fac server side, cu o librarie care face operatii matematice, eventual la care poti regla/seta precizia.

1 Like

E aceeasi treaba si cu calcule de timezone/local time conversion, mai bine pregatesti totul server side si pastrezi partea de UI/prezentare cat mai simpla.

3 Likes

pretu calculat pe server si trimis ca string pentru afisaj

1 Like

1 + 1 in js e diferit de 1+1 in ts. pt ca ts-ul iti compileaza codul in js si de acceea in final o sa ai 1 + 1 in loc de 1 + 1.

1 Like

Exceptie cand toata aplicatia pe front-end se ocupa cu mai multe servicii (adica nu stii ce o sa chemi pe back-end).

Front end-ul trebuie tratat strict ca o interfață și atât. Singurele calcule ce ar trebui făcute în js ar trebui să fie despre câte câmpuri sau câte butoane să afișezi, atât.

Nici pe vremuri când se făceau aplicații Desktop, nu era good practice ca în codul care îți construia form-ul să ai calcule matematice business related, interfața e doar interfață și atât.

Acuma că ai JS pe backend aia e altceva, sunt sigur că există soluții care să trateze neajunsurile JS la faza cu matematica.

Nici nu a pomenit nimeni de securitate, că e banal să deschizi consola și să modifici valorile din JS.

Și nu, a face de 2 ori același lucru (backend dar și front end) nu e treabă nici aia.

pentru asta exista patternul BFF (= Backend For Frontend)

1 Like

Asta nu inseamna ca nu poti face calculele in browser, sunt total de acord cu segregarea in servicii logica pentru calcule, dar nu trebuie neaparat exclus JS ca si un limbaj care n-ar trebui sa faca acest lucru si browserul ca platforma in care poti face aplicatia de la A-Z (JAMStack). Iar in ziua de azi daca chiar nu iti place JS si trebuie precizie, poti sa faci un service worker cu ce face backend-ul pe front-end cu web assembly.

Am facut o aplicatie/extensie de import/export/sincronizare din Google Sheets cu o platforma si toata logica de formatare la toate tipurile de date posibile si validare e si pe back-end si pe front-end. Nu e best practice, dar e foarte scump si sa tot trimiti date spre back-end cu Google Sheets cand ai 5 milioane de celule (exista un quota pe utilizator/workspace/document). Iar daca esti pe avion si n-ai internet nu inseamna ca nu ar trebui sa poti sa faci contabilitate in aplicatie fiindca n-ai back-end. Avem teste automate si pana trec stim ca totul va fi in ordine cu formatarea. (acum calculele la summary-uri le face backend-ul/Google Sheets in functie de celule)

Poti modifica codul pe front-end, dar e mult mai greu decat crezi sa faci acest lucru daca n-ai control deja asupra codului (devtools nu inseamna ca e usor de editat si de altundeva), nu e o bresa de securitate sa ai logica pe front-end decat daca nu vrei sa o ascunzi dintr-un motiv anume.