Open crnkjck opened 1 year ago
Prišiel som na možný scenár skríženia, ale treba ho ešte otestovať:
Predpoklady: V jednom priečinku mám veľký hárok, ktorý sa otvára dlho, a druhý menší, ktorý sa otvorí podstatne rýchlejšie. Nachádzam sa v priečinku, ktorý obsahuje oba hárky
Postup: V rýchlom slede, kratšom ako čas načítania veľkého hárku:
Výsledok: Malý hárok sa načíta, ale po chvíli sa objaví obsah veľkého.
Na živých dátach som nechcel testovať, čo sa stane, keď spravím zmenu, ale domnievam sa, že stav veľkého hárku sa uloží do pracovnej vetvy malého.
Scenár, ktorý ste popísali považujem za možný a môže nastať častejšie pri pomalom internetovom pripojení, keďže vtedy môže čakanie na await v kóde načítavania a ukladania trvať aj niekoľko sekúnd ci desiatok sekúnd.
Myslím, že jednoduché riešenie je použiť v repozitáry klasický <a>...</a>
link namiesto Link komponentu, čo spôsobí refresh stránky pri otvorení hárku a "cancel" všetkých bežiacich promisov súvisiacich s predošlým hárkom.
Možné korektné riešenie by bolo priradiť k hárku id, ktoré sa mení po každom načítaní nového hárku. Asynchrónne volania by si potom na začiatku uložili aktuálne id hárku a po čakaní na await by sa muselo kontrolovať či sa id hárku nezmenilo a ak áno neukladať výsledky volaní. Toto ale vyžaduje rozsiahlejšiu zmenu v kóde načítavania a ukladania do repozitára.
Workaround v PR #43. Undo, keď sa zmergeuje nový workbook s kontextmi a workerom.
Kolegyni sa stalo, že pri merge pracovnej vetvy súboru tu08.workbook sa obsah prepísal obsahom súboru tu08-bonus.workbook, ktorý mala paralelne otvorený v inej karte a tiež mal pracovnú vetvu. Znie to bizardne, nenapadá mi žiadne vysvetlenie. 🛸