Én CSS-variabel, fem review-runder og en Swift-værktøjskæde, der løj

"Gør overlay-laget gennemsigtigt" er den slags opgave, der lyder som en skyder og en CSS-opacity-egenskab. GeekBye v2.0.7 leverede præcis det resultat for brugeren — én enkelt justerbar "light mode", der lader dig se igennem assistentens paneler ned på det, der er bagved. Men den interessante del af denne udgivelse er ikke selve funktionen. Det er de fem review-runder, det tog at få den rigtig, og en krigshistorie om en kompileret binær, der ændrede størrelse, fordi vores egen dokumentation løj for en reviewer.

Den rigtige måde at gøre en hel UI gennemsigtig på

Den naive version af det her er at drysse en opacitets-værdi ud over hver eneste panel-komponent og kalde det færdigt. Det er en vedligeholdelsesfælde: et dusin hardkodede værdier, der driver fra hinanden i samme øjeblik nogen rører ved én af dem.

I stedet bruger v2.0.7 én delt CSS-utility og et token pr. flade. Der er én enkelt overlay-surface-klasse, som beregner et panels baggrund ud fra to custom properties: en basis-opacitet, som hver flade selv erklærer (kontrollinjen, chatten, transskriptionsboblerne, kodeblokke og så videre vælger hver især deres egen), og en global alpha-multiplikator, som ligger på overlay-roden og repræsenterer brugerens skyder-indstilling. Hver flade læser den samme multiplikator; hver beholder sin egen karakter. Afgørende er det, at kun panel-baggrunden skaleres — tekst, ikoner og backdrop-blur forbliver fuldt renderet, så "gennemsigtig" aldrig betyder "ulæselig".

To beslutninger i det design er værd at fremhæve, fordi de er forskellen på en funktion, der hjælper, og en, der genererer supportsager:

• Standardindstillingen er fuldt uigennemsigtig. Opacitets-indstillingen leveres ved 100 % — en no-op. Ingens overlay blev pludselig gennemsigtigt ved opdatering; gennemsigtigheden er der, når du rækker ud efter den, og usynlig indtil da.
• Indstillingen valideres defensivt. Der er én kilde til sandhed for minimum, maksimum, standard og trin, samt en normalizer, der beskytter mod det tomme/manglende tilfælde. Det betyder noget på grund af en JavaScript-fælde: Number(null) er 0, så en manglende indstilling, der naivt blev tvunget, ville snappe overlay-laget til dets mest gennemsigtige tilstand i stedet for standarden. Normalizeren fanger det, før det kan ske.

Træk i skyderen, og hele overlay-laget farves om live, midt i en optagelse, fordi hver flade abonnerer på den samme indstilling. Ingen genstart, ingen genindlæsning.

Hvad review fangede (og hvad en test på én skærm aldrig ville have gjort)

Her holdt "én CSS-variabel" op med at være simpelt. Tre fejl dukkede op i review, og to af dem er den samme lektie med forskellige hatte på.

Et panel, der ikke ville fade. Overlay-laget med tastaturgenveje blev stædigt ved med at være massivt, mens alt andet blev gennemsigtigt. Årsagen: det renderes uden for det DOM-undertræ, der bærer opacitets-variablen, så det arvede aldrig værdien, der kaskaderede ned fra overlay-roden. CSS custom properties arves gennem DOM-træet — og hvis en node ikke reelt er en efterkommer af det sted, hvor du sætter variablen, får den lydløst intet. Løsningen var at sætte variablen lokalt på det panel også.

En hover-tone, der forsvandt. Fn/Assist-knapperne mistede deres cyanfarvede hover-glød. Gennemsigtigheds-utilityen satte baggrunden med !important (den bliver nødt til at vinde over flade-standarderne), og det valsede hen over hover:-baggrundstonen på det samme element. Specificitets-sammenstød. Løsningen var at gøre hover-tonen lige så eftertrykkelig, så den kunne vinde tilbage ved hover.

Begge de to er den samme underliggende sandhed: en CSS-variabel-kaskade er en reel korrekthedsgrænse, ikke en styling-detalje. Arv og specificitet afgør, om din værdi overhovedet når frem til elementet, og ingen af dem viser sig i et skærmbillede, før det er galt.

Samme opacitet, forskelligt udseende. Den mest subtile: optagelseslinjen og hvilelinjen var sat til identisk basis-opacitet og så alligevel synligt forskellige ud. Hvorfor? Optagelses-pillen brugte et kraftigere backdrop-blur, og et stærkt blur over en mørk baggrund midler mod et mørkere resultat — så ens alpha gav uens udseende. Den havde også en svag kant, hvor hvilelinjen havde en lysende gradient-ring-kant. Løsningen matchede blur-niveauet og ringen. Lektien sad fast: ens alpha er ikke ens udseende, når blur kommer ind i billedet. Gennemsigtighed er et system af effekter, der vekselvirker, ikke et enkelt tal.

Binæren, der ændrede størrelse, fordi dokumentationen løj

Nu til krigshistorien, og det er min yndlingstype — den, hvor værktøjerne og dokumentationen er uenige, og en omhyggelig reviewer bliver fanget i krydsilden.

GeekBye leverer nogle forudkompilerede Swift-binærer (native hjælpere til ting som mødedetektering). Fordi en kompileret binær er committet ind i repoet, skal hver udvikler kompilere den med præcis den samme Swift-version — forskellige værktøjskæder producerer forskellige bytes ud af identisk kildekode, og det ville betyde en spøgelses-git-konflikt, hver gang nogen genbygger. Så der er et script, der håndhæver én specifik version: Swift 6.3.x, tjekket på build-tidspunktet.

Under review af denne udgivelse markerede en reviewer, at en binær burde genbygges, så den matchede "den repo-påkrævede værktøjskæde". Udvikleren gjorde præcis det — og binærens størrelse ændrede sig fra 89,184 bytes til 88,512. Commit-beskeden sagde endda, at den "genoprettede byte-stabilt output" ved at genbygge med Swift 6.2.1, "den repo-påkrævede værktøjskæde".

Bortset fra at 6.2.1 var den forkerte version. Build-håndhævelses-scriptet krævede 6.3.x. Problemet var, at prosa-dokumentationen — README-filen og bidragyder-guiden — stadig sagde 6.2.1 et par steder. Så en samvittighedsfuld reviewer og en samvittighedsfuld udvikler, der begge forsøgte at gøre det rigtige, fulgte dokumentationen lige ind i at committe præcis det artefakt, som håndhævelses-scriptet findes for at afvise. En 6.2.1-binær i et 6.3.x-repo er præcis den drift, der ville ødelægge alle andre udvikleres rene genbygning.

Den næste commit rettede det — og rettelsen er pointen. Den genbyggede ikke bare binæren tilbage til dens 6.3.x-form (størrelsen genoprettet til 89,184, lige tilbage hvor den startede). Den rettede også de forældede "6.2.1"-referencer i dokumentationen, så fælden ikke kunne udløses igen. Binæren vippede 672 bytes frem og tilbage over to commits, og den egentlige fejl var aldrig binæren. Det var, at to kilder til sandhed — håndhævelses-scriptet og den skrevne dokumentation — var uenige, og et menneske stolede på den forkerte.

Tre ting denne udgivelse lærte os

1. En CSS-variabel-kaskade er en korrekthedsgrænse. To af tre review-fejl kom ned til en variabel, der ikke blev arvet, og en !important, der valsede hen over en hover-tilstand. Hvis en værdi skal nå frem til et element gennem arv eller vinde gennem specificitet, er den sti logik — verificér den som logik, ikke som styling.
2. Ens parametre kan give uens resultater. Optagelseslinjen og hvilelinjen delte en opacitet og så alligevel forskellige ud, fordi et andet blur ændrede udfaldet. Når du forener et visuelt system om ét tal, så tjek, at de andre variabler omkring hver flade ikke stille ændrer, hvad det tal betyder.
3. Når dokumentation og håndhævelse er uenige, så ret uenigheden — ikke bare symptomet. Fejlen var ikke en dårlig binær; det var en dokumentation, der nævnte den forkerte værktøjskæde, og et håndhævelses-script, der sagde noget andet. At genbygge binæren behandler symptomet. At få hver kilde til sandhed til at stemme overens er den egentlige rettelse, for den næste reviewer vil også stole på dokumentationen.

GeekBye v2.0.7 leverede den ensartede gennemsigtighed, alle grænsetilfælde gennemgået og værktøjskæde-dokumentationen rettet op. Det er den sidste af "stille håndværk"-udgivelserne før den reliability-sprint, der fulgte efter. For fundamentet under den, se hvad en version 2 faktisk kræver (v2.0.0); for søster-poleringsudgivelsen, rolig software: flimmer-fixet og answer-mode-chippen (v2.0.3 + v2.0.5); og for hvordan overlay-laget forbliver skjult under et opkald, sådan forbliver du usynlig under skærmdeling.