Срещи, които наистина можеш да намериш отново: изданието с timeline

Към януари 2026 потребителите на GeekBye имаха проблем с историята. Приложението записваше и анализираше срещите им безупречно — и после ги подреждаше в падащо меню. Падащото меню е наред за три елемента. Около среща номер петнадесет „онова интервю от миналия вторник" се беше превърнало в археологическа експедиция през еднакво изглеждащи редове. v1.7.3 — 64 комита между средата на декември и 16 януари — е изданието, в което срещите станаха нещо, което наистина можеш да намериш отново.

(Една счетоводна бележка, защото git историята е честна дори когато номерата на версиите не са: няма release таг v1.7.2. Версията беше вдигната, но следващият доставен таг беше v1.7.3, така че Windows поправките от ерата на v1.7.2 пътуваха в това издание.)

От падащо меню към timeline

Основната промяна е един pull request: 12 файла, +640 реда, повечето от тях нов компонент MeetingsTimeline от 381 реда. Падащото меню се превърна в превъртаем timeline от карти на срещи, групирани в четири кофи — Today, Yesterday, This Week, Older (днес, вчера, тази седмица, по-стари) — с дати, изписани така, както би ги казал човек: Today, 2:30 PM, Yesterday, 2:30 PM, Mon, 2:30 PM за текущата седмица и Jan 5, 2:30 PM отвъд нея. Cmd/Ctrl+K фокусира поле за търсене, което филтрира по заглавие. Изгледът с детайлите на срещата стана истинска навигационна страница, така че бутоните назад и напред в navbar-а най-после означават нещо, а breadcrumb-ът спря да показва „Meetings / Meeting" и започна да показва „Meetings / Interview with John" (съкратен с многоточие, защото винаги ще има някой, който кръщава срещата си като роман).

С него дойдоха и две малки удобства: бутон за изтриване вътре в изгледа на срещата (който след изтриване те връща обратно в timeline-а, вместо да те изостави на мъртва страница), и автоматична навигация — когато сесия на слушане приключи с реално съдържание в транскрипта, дашбордът се отваря директно на детайлната страница на тази среща. Затваряш разговора, виждаш срещата. Сесиите, които приключват празни, тихо се изтриват, вместо да задръстват timeline-а.

Надпреварата, която създаваш, подобрявайки навигацията

Ето частта, която changelog-ът не ти казва. Старият списък със срещи имаше навик: при всяко зареждане автоматично избираше най-новата сесия. Безобидно, докато списъкът беше падащо меню, което рядко докосваш. Фатално в мига, в който срещите станаха страница, из която навигираш: кликваш среща №5, фоново презареждане приключва и списъкът услужливо избира най-новата среща — презаписвайки избора, който направи преди две секунди. Поправката не беше по-хитра защитна проверка; беше пълното изтриване на автоматичния избор. Всеки списък, който избира неща от името на потребителя, рано или късно ще започне да се бори с потребителя.

Премахването му разкри втората надпревара. Автоматичната навигация скача към среща в мига, в който сесията ѝ приключи — което може да е преди тази сесия да е приключила записа си в локалната SQLite база данни. Навигирай твърде бързо и пристигаш при среща, която още не съществува. Доставената поправка е закъснение от 500 милисекунди преди зареждането на сесиите при пристигане в детайлния изглед, а навигационният handler носи собствените си застраховки — изчакай did-finish-load на прозореца плюс 100ms, ако дашбордът току-що е бил създаден, 50ms, ако вече е бил отворен. Нашият прочит: навигацията в края на сесията пресича три времеви домейна — записа в базата данни, зареждането на прозореца и React mount-а — и всеки от тях получи собствено малко закъснение. Работи, и ще кажем направо: купчина магически числа е честно признат дълг, а не победа.

Скрийншотът, който предхожда собствената си среща

Още едно предположение умря в това издание: „скрийншотите принадлежат на сесия тогава и само тогава, когато са направени по време на нея." Напълно логично. Грешно. Реалните потребители натискат Cmd+H върху обявата за работа, дневния ред, кода, който ще обсъждат — преди да натиснат Start. Табът Report съпоставяше скрийншотите с времевия диапазон на сесията стриктно, така че тези подготвителни скрийншоти изчезваха от доклада, за който бяха направени. Поправката разшири прозореца на съпоставяне с 60 секунди преди старта на сесията. (Самата машинария за времеви диапазони е по-стара — тя беше тихо доставена във v1.6.15; приносът на v1.7.3 е, че я научи, че срещите започват малко преди да започнат.)

Пет поправки за двадесет и осем минути

Историята от фронта на това издание изобщо не е в timeline-а — тя е в overlay-а на онбординга под Windows, и е христоматийна верига „поправи поправката": пет комита между 10:50 и 11:18 в една и съща сутрин.

Главният прозорец на GeekBye използва mouse passthrough — hook, който превключва setIgnoreMouseEvents на Electron при всяко движение на мишката, така че кликовете да пропадат през прозрачните зони. По време на онбординга под Windows този hook се биеше с overlay-а на урока и на стъпката, в която се появява прозорецът на дашборда, приложението замръзваше. Поправка едно: направи hook-а да не прави нищо, докато онбордингът е активен. Мир чрез разоръжаване.

Само че сега бутоните на онбординга не реагираха, защото препращането на събития доставяше кликовете на прозореца на дашборда под overlay-а. Поправки две и три въртяха forward: false за всеки wizard поотделно. После дойде комитът, който намери истинската първопричина: когато прозорецът на дашборда се отвори, неговият drag handler връща главния прозорец в режим click-through — а първата поправка беше направила passthrough hook-а пасивен, което означаваше, че не беше останало нищо, което да коригира намесата. Истинската поправка обърна стратегията: hook-ът сега активно препотвърждава setIgnoreMouseEvents(false) при всяко движение на мишката по време на онбординга, точно защото външен код може да го нулира по всяко време. Освен това изтри 75 реда от по-ранните заобикалки за всеки wizard.

И дори тогава имаше пети комит, защото да спечелиш войната за входа не значи да спечелиш войната за z-order-а: overlay-ът и дашбордът седяха на едно и също always-on-top ниво, а Windows издига нагоре който прозорец получи фокус. Overlay-ът се премести на по-високо ниво на прозорец и сам се издига отново със закъснение, след като дашбордът се появи. Дъгата си струва да се запомни: пасивна поправка, която обезоръжава единствения ти защитник, е по-лоша от първоначалната битка.

Три неща, на които ни научи това издание

1. Подобренията в навигацията изкарват наяве бъгове в състоянието. Надпреварата с автоматичния избор съществуваше преди v1.7.3; падащото меню просто никога не ти позволяваше да я усетиш. В мига, в който срещите станаха страница, из която съзнателно навигираш, всяко парче код, което избираше неща вместо теб, стана бъг.
2. Времевите граници около намерението на потребителя се нуждаят от луфт. Сесии, записи, доклади — потребителите действат малко преди и малко след официалния прозорец на машината. Буферът от 60 секунди за скрийншотите е един ред, който отразява как хората наистина се държат.
3. Никога не прави коригиращия си код пасивен. Замръзването под Windows отне пет поправки, защото поправка едно изключи единствения механизъм, който можеше да противодейства на външната намеса. Ако някакъв друг код може да счупи инварианта ти по всяко време, работата ти е да го препотвърждаваш непрекъснато, а не да сваляш оръжието.

За предишната глава от историята на v1 — изграждането на две брандирани приложения от тази една кодова база — виж една кодова база, две приложения: как да направиш white-label без fork (v1.7.1); а за цялата дъга — анатомията на доставянето на софтуер до съвършенство.