Cum duci o bibliotecă de componente în producție

Să construiești o bibliotecă de componente e ușor. Alegi o problemă, o rezolvi izolat, scrii o aplicație demonstrativă care arată că merge și totul se poartă frumos, pentru că nimic nu-i cere nimic dificil.

Să-ți folosești propria bibliotecă într-o aplicație pe care se bazează oameni reali e locul în care afli ce e de fapt în neregulă cu ea. Liquid Glass a intrat în TeamTipOut la vreo patru săptămâni după ce am început-o. Prima săptămână a stricat două lucruri pe care nu le-aș fi găsit niciodată într-o previzualizare.

Bugurile pe care nu le poți găsi singur

Primul a fost un crash pe New Architecture. Un slider a trimis o valoare fracționară peste punte ca double, acolo unde partea de Swift aștepta un pas cuantificat. În aplicația demonstrativă sliderul se mișca doar între opriri curate, pentru că eram singurul om care îl atinsese vreodată.

“O aplicație de previzualizare nu ține niciodată o valoare venită de la un utilizator real și nu randează niciodată sub presiune reală de layout.”

Al doilea a fost un control segmentat care își măsura lățimea la prima desenare, înainte să se încarce fontul și să se așeze etichetele. Pe un simulator cald, cu fontul deja în cache, nu s-a întâmplat nici măcar o dată. Pe un telefon real pornit de la rece, se întâmpla de cele mai multe ori.

Opțional din oficiu

Ambele corecturi au fost mici. Lecția structurală nu. Dacă o bibliotecă livrează module native, fiecare dintre ele trebuie să fie o dependență opțională, pentru că defecțiunea pentru care proiectezi nu e un bug în codul tău. E un consumator care a instalat pachetul JavaScript și n-a legat niciodată partea nativă.

// never let a missing peer throw at importexport function optionalRequire(id: string) {  try { return require(id) }  catch { return null }} const Native = optionalRequire('…/glass-native')const tier   = Native ? 'native' : 'fallback'

Decizia aia a transformat o categorie de erori la import într-o categorie de degradări tăcute. Componenta tot se randează. Doar că randează nivelul de dedesubt, iar autorul aplicației nu trebuie să se gândească la asta niciodată.

Ce aș face altfel

Aș pune-o într-o aplicație reală mult mai devreme: în prima săptămână, nu în a patra. Aplicația demonstrativă era liniștitoare și aproape complet inutilă. Singurul test onest al unei unelte e ceva care se strică atunci când se strică unealta.