Üks CSS-i muutuja, viis ülevaatusringi ja Swifti tööriistakett, mis valetas

"Tee overlay läbipaistvaks" on selline ülesanne, mis kõlab nagu liugur ja CSS-i opacity-omadus. GeekBye v2.0.7 tõigi täpselt selle kasutaja jaoks nähtava tulemuse — üheainsa reguleeritava "valge režiimi", mis laseb sul näha läbi assistendi paneelide seda, mis nende taga on. Aga selle väljalaske huvitav osa pole see funktsioon. See on viis ülevaatusringi, mida kulus asja korda saamiseks, ja lahingulugu kompileeritud binaarist, mis muutis suurust, sest meie enda dokumentatsioon valetas ülevaatajale.

Õige viis muuta kogu kasutajaliides läbipaistvaks

Naiivne versioon sellest on puistata läbipaistvuse väärtus üle iga paneelikomponendi ja pidada asi tehtuks. See on hoolduslõks: tosin kõvakodeeritud väärtust, mis lähevad omavahel lahku hetkel, mil keegi neist üht puudutab.

Selle asemel kasutab v2.0.7 üht jagatud CSS-utiliiti ja pinnapõhist tokenit. On üksainus overlay-surface klass, mis arvutab paneeli tausta kahest custom property'st: iga pind deklareerib endale ise baas-läbipaistvuse (juhtriba, vestlus, transkriptimullid, koodiblokid ja nii edasi valivad igaüks omaenda), ja globaalne alfakordisti, mis sõidab overlay juurel ja esindab kasutaja liuguri seadet. Iga pind loeb sama kordistit; igaüks säilitab oma iseloomu. Kriitiline on see, et skaleerub ainult paneeli taust — tekst, ikoonid ja backdrop-blur jäävad täielikult renderdatuks, seega "läbipaistev" ei tähenda kunagi "loetamatu".

Selle disaini kaks otsust väärivad esiletõstmist, sest just need eristavad funktsiooni, mis aitab, funktsioonist, mis genereerib tugipäringuid:

• Vaikimisi on kõik täiesti läbipaistmatu. Läbipaistvuse seade tarnitakse 100%-l — nulltoiming. Kellegi overlay ei muutunud uuenduse peale ootamatult läbipaistvaks; läbipaistvus on olemas siis, kui sa selle järele küünitad, ja nähtamatu seni.
• Seade on kaitsvalt valideeritud. Miinimumil, maksimumil, vaikeväärtusel ja sammul on üks tõeallikas, ning normaliseerija, mis kaitseb tühja/puuduva juhtumi eest. See on oluline JavaScripti jalapüssi tõttu: Number(null) on 0, seega naiivselt teisendatud puuduv seade napsaks overlay tema kõige läbipaistvamasse olekusse, mitte vaikeolekusse. Normaliseerija tabab selle enne, kui see juhtuda saab.

Lohista liugurit ja kogu overlay värvub uuesti reaalajas, keset salvestust, sest iga pind on tellitud samale seadele. Ei taaskäivitust ega uuesti laadimist.

Mida ülevaatus tabas (ja mida üheekraaniline test kunagi poleks)

Siin lakkas "üks CSS-i muutuja" olemast lihtne. Ülevaatuses ilmus kolm viga, ja kaks neist on sama õppetund erinevas kübaras.

Paneel, mis ei tahtnud tuhmuda. Klaviatuuri-otseteede overlay jäi kangekaelselt läbipaistmatuks, samal ajal kui kõik muu muutus läbipaistvaks. Põhjus: see renderdatakse väljaspool DOM-i alampuud, mis kannab läbipaistvuse muutujat, seega ei pärinud see kunagi väärtust, mis kaskaadus overlay juurest alla. CSS custom property'd päranduvad läbi DOM-puu — ja kui sõlm pole tegelikult muutuja seadmiskoha järeltulija, saab ta vaikselt eimidagi. Lahendus oli seada muutuja lokaalselt ka sellel paneelil.

Hover-toon, mis kadus. Fn/Assist-nupud kaotasid oma tsüaanse hover-kuma. Läbipaistvuse utiliit seadis tausta !important-iga (see peab võitma pindade vaikeväärtused), ja see sõitis üle sama elemendi hover: tausta tooni. Spetsiifilisuse kokkupõrge. Lahendus oli teha hover-toon võrdselt rõhutatuks, et see saaks hoveri peal tagasi võita.

Mõlemad neist on sama alustõde: CSS-muutuja kaskaad on tõeline korrektsuse piir, mitte stiiliseadete detail. Pärandumine ja spetsiifilisus otsustavad, kas su väärtus elementi üldse jõuab, ja kumbki ei ilmu ekraanipildile enne, kui see on vale.

Sama läbipaistvus, erinev välimus. Kõige peenem: salvestusriba ja jõudeoleku riba olid seatud täpselt samale baas-läbipaistvusele ja nägid ikkagi nähtavalt erinevad välja. Miks? Salvestuspill kasutas tugevamat backdrop-blur'i, ja tugev hägusus tumeda tausta peal keskmistub tumedama tulemuse poole — seega võrdne alfa andis ebavõrdse välimuse. Sellel oli ka nõrk ääris seal, kus jõudeoleku ribal oli ere gradient-rõngaäär. Lahendus ühtlustas hägususe taseme ja rõnga. Õppetund jäi külge: võrdne alfa ei ole võrdne välimus, kui hägusus mängu tuleb. Läbipaistvus on koosmõjuvate efektide süsteem, mitte üksainus arv.

Binaar, mis muutis suurust, sest dokumentatsioon valetas

Nüüd lahingulugu, ja see on mu lemmiktüüpi — see, kus tööriistad ja dokumentatsioon on eriarvamusel ja hoolikas ülevaataja jääb risttule vahele.

GeekBye tarnib mõned eelkompileeritud Swifti binaarid (natiivsed abilised näiteks koosolekute tuvastamiseks). Kuna kompileeritud binaar on repo sisse commitatud, peab iga arendaja selle kompileerima täpselt sama Swifti versiooniga — erinevad tööriistaketid toodavad identsest lähtekoodist erinevad baidid, ja see tähendaks fantoomset git-konflikti iga kord, kui keegi uuesti ehitab. Seega on olemas skript, mis jõustab ühe kindla versiooni: Swift 6.3.x, kontrollitud ehitusajal.

Selle väljalaske ülevaatuse käigus märkis ülevaataja, et binaar tuleks uuesti ehitada, et see vastaks "repo nõutud tööriistaketile". Arendaja tegi täpselt seda — ja binaari suurus muutus 89,184 baidist 88,512-ni. Commiti sõnum isegi ütles, et see "taastas baidistabiilse väljundi", ehitades uuesti Swift 6.2.1-ga, "repo nõutud tööriistaketiga".

Ainult et 6.2.1 oli vale versioon. Ehituse jõustamisskript nõudis 6.3.x-i. Probleem oli selles, et proosaline dokumentatsioon — README ja panustaja juhend — ütles paaris kohas ikka veel 6.2.1. Nii et kohusetundlik ülevaataja ja kohusetundlik arendaja, mõlemad püüdes õiget asja teha, järgisid dokumentatsiooni otse selle artefakti commitimiseni, mille tagasilükkamiseks jõustamisskript üldse olemas on. 6.2.1 binaar 6.3.x repos on täpselt see triiv, mis rikuks iga teise arendaja puhta uuesti-ehituse.

Järgmine commit parandas selle — ja lahendus ongi see, milles asi. See ei ehitanud lihtsalt binaari tagasi tema 6.3.x kujule (suurus taastatud 89,184-ni, täpselt sinna, kust alustati). See ka parandas aegunud "6.2.1" viited dokumentatsioonis, et lõks ei saaks uuesti käivituda. Binaar kõikus kahe commiti jooksul 672 baiti edasi ja tagasi, ja tegelik viga polnud kunagi binaar. See oli, et kaks tõeallikat — jõustamisskript ja kirjalik dokumentatsioon — olid eriarvamusel, ja inimene usaldas valet.

Kolm asja, mida see väljalase õpetas

1. CSS-muutuja kaskaad on korrektsuse piir. Kaks kolmest ülevaatuse veast taandusid muutujale, mis ei pärinud, ja !important-ile, mis lõi hover-oleku. Kui väärtus peab jõudma elemendini pärandumise kaudu või võitma spetsiifilisuse kaudu, on see tee loogika — kontrolli seda nagu loogikat, mitte nagu stiiliseadeid.
2. Võrdsed parameetrid võivad anda ebavõrdseid tulemusi. Salvestusriba ja jõudeoleku riba jagasid läbipaistvust ja nägid ikka erinevad välja, sest teistsugune hägusus muutis tulemust. Kui ühtlustad visuaalse süsteemi ühe arvu peale, kontrolli, et teised muutujad iga pinna ümber ei muuda vaikselt seda, mida see arv tähendab.
3. Kui dokumentatsioon ja jõustamine on eriarvamusel, paranda eriarvamus — mitte ainult sümptom. Viga polnud halb binaar; see oli dokumentatsioon, mis nimetas vale tööriistaketi, ja jõustamisskript, mis ütles vastupidist. Binaari uuesti ehitamine ravib sümptomit. Iga tõeallika nõusse viimine on tegelik lahendus, sest järgmine ülevaataja usaldab samuti dokumentatsiooni.

GeekBye v2.0.7 tõi ühtlase läbipaistvuse, kõik ääre-juhtumid üle vaadatud ja tööriistaketi dokumentatsioon korda tehtud. See on viimane "vaikse käsitöö" väljalasetest enne sellele järgnenud usaldusväärsuse sprinti. Selle all oleva vundamendi kohta vaata mida versioon kaks tegelikult nõuab (v2.0.0); õdeviimistluse väljalaske kohta rahulik tarkvara: virvenduse parandus ja vastuserežiimi märgis (v2.0.3 + v2.0.5); ja selle kohta, kuidas overlay jääb kõne ajal peidetuks, kuidas jääda ekraanijagamise ajal nähtamatuks.