Osobní preference: mít z toho „klasické“ datové typy (pole dvojic), ne zip objekty, které se konzumují a nedají se proto cyklit opakovaně. (Až to někdo bude zkoušet, tak je imho velká šance, že mu to bude dělat blbosti a nebude chápat proč…)
A neumíme v takovém případě dát rozumnou hlášku na frontend? (Jakože, špatná sada přednášek je asi divný okrajový případ a mám trochu chuť seznamu o kterém se aktuálně hlasuje zakázat změny, ale je otázka, jestli nemůže nastat nějaký jiný divný stav…)
Asi OK. Možná si teoreticky můžeme místo účastníků u všeho držet celý objekt s informacemi o hlasování k celému seznamu, ale to za to nestojí, zvlášť pokud budeme mít ambice zmigrovat to celé na Osoby.
Also: tu Osobu (s null=True) si IMHO chceme ukládat už teď, ať pak můžeme zmigrovat a nechybí nám data… (původní hlasovátko ještě nevědělo nic o účastnických uživatelích/osobách…)
Navrhuji mít kolem každého bloku hlasování aspoň dummy <div>, ať se kdyžtak dají různě popřeskládat (kupř. nějakým flexem na ultraširokém monitoru vedle sebe, idk) a nehrozí někde rozbití CSS. (Případně ať si můžu nahackovat dodatečná CSS :-D)
Hmm, existuje čisté a praktické řešení. To čisté a datazachovávající je mít pro osobu nový FK (s null=True, blank=False) a mít stará řešení se string-účastníkem a nová s Osobou.
Also: tu Osobu (s null=True) si IMHO chceme ukládat už teď, ať pak můžeme zmigrovat a nechybí nám data… (původní hlasovátko ještě nevědělo nic o účastnických uživatelích/osob…
A commit message by příště mohla být lepší, protože po zamergování už nemá jméno větve žádný význam, naopak commit se někde objevit může…
Tohle je úplně jiný vzhled, než máme asi úplně všude…
Mám pocit, že tenhle padding divně odsazuje nadpisy a to nezarovnání se mi subjektivně dost nelíbí.
Tohle strašně moc vypadá jako tabulka, nebylo by lepší to skutečně mít udělané jako tabulku? (Nepamatuji si, co flex umí a tabulka ne, takže je možné, že máme nějaký důvod to tak neudělat…)