Mi se pare foarte curajos si foarte interesant din partea lui Razvan Dragomir sa scrie acel post.
Nu cred ca se putea o conjuctura mai nefericita in tot mix-ul ala de tehnologii, skill-uri, echipe si in special, mentalitati.
5 Likes
Iti trebuie experienta pe react ca sa folosesti React pe enterprise, sunt multe prostii in care să își prindă urechile echipa.
De la testare pana la CI/CD sunt lucruri pe care nu le vei vedea la niciun curs. Un monorepo cere și mai multă experiență. Dacă nu ai un monorepo poți să ai 10 sub aplicații în care s-au ales standarde/librării/soluții diferite. La testare e mai special, ai multe lucruri la care să fii atent. E.g. nu îți cad testele dacă ai erori în TypeScript sau warning-uri in test, poți avea foarte ușor memory leak-uri ori în test ori în componenta testata și vezi că îți cade testul fără memorie/cpu dedicat pe runner.
Mock-urile trebuie făcute cu Mock Service Worker (sau similar) altfel testezi implementarea și e o problemă mare. În special dacă ți se cere coverage mare, am vazut cod testat pe implementare cu enzyme in trecut și era cancer să modifici orice fiindcă trebuia rescris testul dacă s-a schimbat implementarea. Cu react-testing-library ai alte probleme precum teste care cad din cauza lipsei unui spinner, nu se trateaza erorile, iar dacă testezi componente mari in paralel 16Gb ram sunt un nimic și dacă nu ai resursele dedicate cad testele. In special hook-urile sunt testate cu un timer, iar dacă procesorul nu e destul de rapid îți va cadea testul aleator… Mulți nu înțeleg și e greu de probat că tu ca FE developer trebuie să setezi ditamai platforma de tracing și logging pentru teste în CI/CD…
Acum dacă cumva cineva mai foloseste shallow rendering și enzyme de exemplu si-a legat tot codul de implementare fiindcă enzyme e implementat specific pe o versiune de react. Cum apare altă versiune trebuie rescris de la 0… Am avut manageri care erau puși pe shallow rendering, cred că încă au o versiune de react antică din cauza asta.
După pe React nu te apuci să folosești OOP cu clase, o să ai multe probleme cu pattern-urile și desigur, nici un front-end dev normal la cap nu se va atinge de clase în 2023. React trebuie folosit cum e în documentație, cu hooks, HOC-uri, librării precum react-query, redux toolkit/zustand…, MUI…
Redux nu merită, cu React query și zustand nu i-am simțit lipsa. De fapt nici zustand nu trebuie, doar hash cu state in path sau nested routes.
În nici un caz nu trebuie luata structura specifica .NET/Java fiindcă va fi mult prea stufos și greu de înțeles. Nu ai dependency injection și sunt total alte pattern-uri. În react e foarte important să poți vedea cand e mai bine să dai un prop, cand e mai bine să dai toata componenta, cand e mai bine sa nu faci prop drilling. Iar cel mai important, trebuie sa înțelegi rapid ce se intampla de la fiecare parinte până la ultimul copil, altfel nu înțelegi ce rerandeaza/re-monteaza ce. Abstracțiile trebuie făcute cu componente și hook-uri care chain-uiesc alte hook-uri. Dacă le faci declarativ din cod e cancer.
In absolut nici un caz nu ai nevoie de inversifyJS, ai alte pattern-uri pentru SOLID in react sau pe front-end precum HOC-uri, generatoare/factory functions, dumb components, fatade și compoziție. ES modules sunt deja o bază de date, poți avea alias-uri/namespace in pnpm/yarn/npm… ceea ce e de ajuns.
Componentele trebuie gândite bine, iese un spaghetti code foarte frumos dacă nu înțelegi react, JS (la baza tot ce faci e de fapt JS…) După trebuie să înțelegi de exemplu librăriile, react-query, redux, hook-urile nu sunt așa simple precum par. Un simplu formular scris frumos cu accesibilitate, validari (inclusiv pe response), autocomplete/dropdown-uri poate fi ridicol de complex dacă nu alegi pattern-urile bune.
Sunt de acord total cu concluzia ca dacă ai deaface cu Enterprise devs (.NET/Java) pe front-end iesi mult mai bine cu Angular, Vue sau chiar Svelte. (Dar la svelte tot vei avea problema de decision log și alegerea librăriilor, Angular e cel mai simplu)
As putea menționa si ember ca si framework-ul enterprise perfect, dar nu găsești un singur dev pe ember in toată România.
Pe Java am vazut de exemplu Vaadin care ar fi de 100x de ori mai ok pentru cineva hardcore pe Java, dar mult noroc să găsești un front-end bun care să lucreze cu el.
1 Like