const useCheckHabit = () => {
const queryClient = useQueryClient();
return useMutation({
mutationFn: async ({ habitId, date }: { habitId: string; date: string }) => {
const { data, error } = await supabase
.from('habit_logs')
.insert([{ habit_id: habitId, date }]);
if (error) throw error;
return data;
},
onMutate: async ({ habitId, date }) => {
await queryClient.cancelQueries({ queryKey: ['habits', date] });
const previousHabits = queryClient.getQueryData(['habits', date]);
queryClient.setQueryData(['habits', date], (old: any) =>
old ? old.map((h: any) => (h.id === habitId ? { ...h, completed: true } : h)) : []
);
return { previousHabits };
},
onError: (err, variables, context) => {
if (context?.previousHabits) {
queryClient.setQueryData(['habits', variables.date], context.previousHabits);
}
},
});
};Luna trecută am urcat pe App Store și Google Play un habit tracker simplu, creat în câteva weekenduri libere. Fără vreun buget de marketing, am strâns 200 de utilizatori activi în primele 30 de zile. Vreau să vă povestesc ce stack am ales, unde am dat gherle și ce aș face diferit dacă m-aș apuca azi de proiect.
Stack-ul tehnic: rapiditate și compromisuri
Am vrut să mișc repede, așa că am mers pe Expo (React Native) cu Expo Router v3, Supabase pentru backend și TanStack Query pentru state management. Pentru persistența datelor pe telefon am folosit react-native-mmkv, care e de vreo 30 de ori mai rapid decât vechiul AsyncStorage.
Arhitectura a fost gândită simplu: Supabase îmi oferă Auth și o bază de date Postgres gata configurată, iar pe mobil păstrez o copie locală scurtă a datelor. Trade-off-ul e evident: Supabase e genial când vrei backend instant, dar devine supărător dacă ai nevoie de logică de business complexă pe server, pe care ajungi să o scrii în Edge Functions pe mediu Deno.
Trei greșeli de care m-am lovit direct
Prima gherlă a fost legată de notificările push locale. Am folosit expo-notifications și am crezut că problema e rezolvată. Pe iOS totul merge brici. Pe Android însă, mai ales pe modele Xiaomi și Samsung, sistemul de operare omoară procesele din fundal fără milă. Am avut utilizatori care se plângeau că nu primesc reminderul de seară. Am rezolvat parțial adăugând instrucțiuni în aplicație pentru dezactivarea optimizării de baterie, dar am pierdut garantat vreo 15-20 de utilizatori din cauza asta.
A doua greșeală a fost structura bazei de date. Am creat o tabelă habit_logs unde salvam fiecare bifare zilnică. La 200 de useri, fiecare având în medie 6 obiceiuri, tabela a ajuns la peste 35.000 de rânduri într-o lună. Nu am pus indecși compuși pe (user_id, date) de la început. Query-ul pentru ecranul principal dura 450ms pe Supabase. Un simplu CREATE INDEX a coborât timpul de răspuns la 12ms.
A treia a fost dependența de Expo Go. M-am încăpățânat să lucrez în Expo Go prea mult timp. Când am avut nevoie de module native custom, tranziția la Development Builds a fost dureroasă pentru că aveam deja dependențe configurate greșit.
Optimistic updates: secretul pentru un UI care zboară
Pentru că e o aplicație unde bifezi sarcini rapide, utilizatorul vrea să apese butonul și să vadă efectul pe ecran instant. Nu poți aștepta răspunsul din rețea. Am folosit onMutate din TanStack Query pentru a actualiza starea locală înainte de confirmarea de la server.
Ce aș schimba dacă aș relua proiectul azi
Aș pleca din start cu o abordare 100% local-first folosind WatermelonDB sau PowerSync. În loc să fac fetch din Supabase la fiecare pornire, aplicația ar trebui să meargă impecabil offline și să facă sync tăcut în fundal când prinzi semnal.
De asemenea, m-aș muta pe Expo Development Builds încă din minutul 1. Economisești ore bune de debug când ai de-a face cu pachete native.
Voi ce folosiți când vreți să scoateți un MVP mobil rapid pe piață? Mergeți pe Flutter sau tot pe ecosistemul React Native?