flushSync il folosesti daca vrei sa afisezi ceva in sincron cu ceva cand ai alte hook-uri/efecte care ruleaza in paralel. De exemplu dai click pe un buton si deschizi ceva in paralel dar vrei sa fie sincron dupa la urmatoarea linie de cod, la urmatorul hook, e.g. se dechide un modal nativ de upload si vrei sa stii ca e deschis instant ca sa afisezi instructiuni, tot timpul cat e deschis sau cat printezi (in exemplu) altfel poate un hook nu afla ca s-a deschis si nu salveaza in state sau mai rau face ceva cleanup. Eventual cand iti vin date din mai multe locuri si vrei sa fii sigur ca daca iti vin date dintr-un anumit loc este prioritar si nu te mai intereseaza ce ar rula de fapt dupa ce ai date noi (e.g. feature flags, autentificare (logout de la server), date care vin de la ceva nativ), ceva colaborativ (e.g. cineva inchide documentul in timp ce tu scrii/incarci o imagine).
Nu am incercat RTK Query, dar am folosit redux toolkit si il recomand, dar nu l-as alege in prima instanta decat daca toti ar dori sa il foloseasca si inteleg ce se face automatizat cu redux. Mi-a placut devtools de la redux, deci poate fi foarte util din acest motiv. Partea proasta cu redux la un proiect mare e ca trebuie sa testezi si reducerii pentru coverage si astfel testezi implementarea.
Prima problema daca iei React 18 e ca useEffect va randa de 2 ori in development mode cu StrictMode (cam obligatoriu), fun stuff. In teorie daca asta iti strica aplicatia faci ceva gresit, In practica iti ies fire albe daca vrei sa faci ceva mai complicat. A doua problema e ca render este inlocuit cu createRoot, se schimba modul in care scrii testele.
“With Strict Mode in React 18, React will simulate unmounting and remounting the component in development mode”
Asta inseamna ca practic orice cod mai complex scris de un incepator in React 18 il face sa dea cu capul de pereti. Acum nu trebuie sa fii incepator, e destul sa faci ceva mai complex si ai aceeasi problema. Faci ceva si primesti warning-uri, codul aparent nu face ce trebuie, dar verifici inca o data si face ce trebuie… E.g. e un truc sa pui display: none la componente care nu vrei sa se rerandeze, acum react e super-smart si iti rerandeaza tot in development ca sa verifice ca merge doar din state/props si asa si ti se duce tot state-ul pe care l-ai tine cu display:none/display:block si te-ar salva de la a muta tot state-ul un nivel mai sus. (nu e good practice, dar era folosit de multi)
Daca faci ceva cu cleanup la useEffect, iti aminteste dureros ca cleanup-ul ala ruleaza mereu la fiecare render 
Daca ai de exemplu un toggle in useEffect trebuie sa il faci idempotent cumva, sa verifici ca nu s-a rulat deja. Practici bune, dar devine mai urat de scris cod de react. Ei fac asta ca sa functioneze mai bine de exemplu hot reload sau sincronizarea state-ului din server/alta aplicatie cu snapshot-uri.
Hook-urile erau clar sincron, acum depinde si de ce dependente ai si daca sunt comune intra intr-un queue si se face batch. Acum sincron se ruleaza in batch, nu dupa ordinea in cod. (poti teoretic sa pui hook-uri intr-o ordine in care sa te uiti de 10 ori ce se intampla)
Basically, React 18 e foarte complex, React 17 era relativ usor fiindca nu te obliga sa scrii cod 100% corect, la React 18 la interviu stai ca prostul la probleme simple. Un exemplu e tranzitia, ca să nu mai apelezi la onBlur sau debounce cand scrii sau primesti multe date acum ai startTransition.
