Bol vydaný Vitest vo verzii 5.0​

• https://vitest.dev/blog/vitest-5.html

• Zámerom tohto vydania bol hlavne vylepšený výkon. Môžete očakávať, že vaše testy budú bežat rýchlejšie aspoň o zopár percent (8% - 53% podľa ich benchmarkov).

• Máme k dispozícii novú pomocnú metódu vi.when, ktorú vyuzijeme v situáciách kde potrebujeme, aby namockovaná funkcia vracala hodnoty na základe daných argumentov.

  const findById = vi.fn();
  
  vi.when(findById)
      .calledWith(1)
      .thenResolve({ id: 1, name: "Ella" })
      .calledWith(2)
      .thenResolve({ id: 2, name: "Gracie" })
      .calledWith(expect.any(Number))
      .thenReject(new Error("not found"));
  

• chyby pochádzajúce z neschopnosti nájsť element budú odteraz vypisovať strom s použitím ARIA rolí a názvov. Mali by sme to zobrať ako príležitosť sa ich naučiť a používať lepšie.

• falošné časovače po novom mockujú aj Temporal API, nie iba Date

• nastavenie clearMocks je teraz predvolene zapnuté (true). Predchádzajúce verzie to mali vypnuté (false).

SVG, React a <defs>​

Vykresľujete na jednej stránke viacero kópií rovnakého SVG obrázku a radi by ste používali <defs>, aby ste sa zbavili duplicitného markupu, ale nemôžete, lebo vám v tom bráni fungovanie React-u? Nuž, tak si prečítajte tieto dva články a naučíte sa, aké máte možnosti:

• https://julesblom.com/writing/colocated-svg-defs
• https://julesblom.com/writing/hoistable-svg-defs-ii

Ako vy osobne môžete ovplyvniť a zmeniť JavaScript?​

Kratučké video o tom, ako sa aj vy môžete stať súčasťou vývoja jazyka a jeho špecifikácie:

https://www.youtube.com/watch?v=OkuNJo9tTtg

Opäť ďalšie riešenie na tvorbu natívnych aplikácií v JavaScript-e​

Ľudia stojaci za editorom Zed vytvorili svoj vlastný v Rust-e napísaný GPU akcelerovaný UI framework nazvaný GPUI. Poskytujú k nemu aj binding-y pre React pod názvom GPUIX. Znamená to, že môžeme písať aplikácie pre počítače, ktoré môžu využívať silu grafických kariet pre vykreslovanie (napriamo cez Metal, DirectX alebo Vulkan) použitím jazyka (JavaScript/TypeScript) a UI frameworku (React), ktoré dobre poznáme.

• GPUIX: https://gpuix.dev/
• GPUI (UI framework): https://github.com/zed-industries/zed/tree/main/crates/gpui
• Zed editor: https://zed.dev/

Umelá inteligencia​

S AI pre nás môže byť lepšie použiť primitívy namiesto abstraktných knižníc​

Žijeme v historických časoch (niekto múdry kedysi povedal, že je oveľa lepšie žiť v pokojných a nudných časoch), kedy musíme prehodnocovať aj dlho-platiace pravdy, zákonitosti a paradigmy okolo programovania.

Robin Wieruch nedávno napísal článok o svojej skúsenosti z jedného projektu. Uvedomil si, že programovanie pomocou AI agentov zmenilo "ekonomiku" výberu medzi použitím knižnice tretej strany poskytujúcej abstrakciu problému (spolu s názormi a pravidlami) na jednej strane. Alebo na druhej strane, vytvorením vlastného riešenia na zelenej lúke pomocou "primitív".

Mne Robinove vysvetlenia dávajú zmysel a jeho argumentáciu si môžete prečítať v nasledovnom článku:

• https://www.robinwieruch.de/agentic-coding-bet-on-primitives/

Apokalyptický pohľad na vývoj AI od bývalého zamestnance Anthropic-u a OpenAI​

Nie som si istý, čo k tomuto dodať a čo si o tom myslieť. Je to síce krátke, ale veľmi smutné čítanie.

• https://x.com/hilbertspaess/status/2097476196791709843

Kopec dokumentárnych filmov o technológiách, ktoré používame a máme radi​

Z nasledovnej štvorice filmov som zatiaľ videl iba ten prvý o Visual Studio Code a môžem ho s kľudným srdcom odporučiť. Hneď zo začiatku ma prekvapilo, že za vývoj VS Code je zodpovedný Erich Gamma, čo je jeden zo štvorice autorov, ktorý spísali knihu o návrhových vzoroch.

The Story of VS Code​

https://www.youtube.com/watch?v=kHL3XzjpT5w

The Java Story​

https://www.youtube.com/watch?v=ZqGSg4b_cZA

Vite: The Documentary​

https://www.youtube.com/watch?v=bmWQqAKLgT4

Node.js: The Documentary | An origin story​

https://www.youtube.com/watch?v=LB8KwiiUGy0

Vytvorte svoje vlastné SSR riešenia s použitím Vite​

Mám rád jednoduché riešenie a takisto ráď zisťujem, ako veci fungujú. Pokiaľ ste v tomto na tom podobne a chceli by ste vedieť, ako si nastaviť server-side rendering pre vašu React stránku s použitím Vite, tak nasledovný článok je pre vás. Ale upozorňujem, v titulku a najmä v druhej polovici článku autor používa termín SSG (Static Site Generation, generovanie statických html stránok), ale v skutočnosti ukazuje SSR (Server-side rendering).

• https://tendto.github.io/en/posts/ssg-for-react-with-vite/

Okrem iných vecí, autor v článku odkazuje aj na plugin vite-react-ssg, čo mne z neznámych príčin pripomenulo niekdajší plugin zvaný vite-plugin-ssr. Po nejakú dobu som ho spokojne používal. Medzičasom sa tento plugin vyvinul v plnohodnotný framework pod názvom Vike. Ak by ste chceli mať pod kontrolou úplne všetko vo vašej aplikácii, tak Vike je presne pre vás.

• https://github.com/Daydreamer-riri/vite-react-ssg
• https://vike.dev/

Zatkli dvoch členov skupiny TeamPCP zodpovednej za niektoré zo Shai-Hulud útokov​

Predpokladám, že si pamätáte nekonečné vlny útokov na supply-chain infraštruktúru z pred pár mesiacov, ktoré sme skrátene volali Shai-Hulud. Už som dnes písal, že žijeme v historických časoch a zdá sa, že s príchodom LLM majú aj script-kiddies k dispozícii oveľa mocnejšie nástroje. Z prvých dojmov sa mi zdá, že TeamPCP nie sú typickými aktérmi s nejakým plánom, agendou (alebo štátom za chrbtom), ale iba zopár mladíkov, ktorí sa chytili príležitosti. To však neznamená, že nie sú nebezpeční. A nielen pre IT infraštruktúru, ale aj fyzicky nebezpeční. Ak chcete vedieť viac, prečítajte si nasledovný článok, ktorý napísal bezpečnostný výskumník Charlie Eriksen:

• https://www.aikido.dev/blog/teampcp-arrested-supply-chain

EVE Online migruje na Python 3​

Táto novinka sa netýka frontendu, ani JavaScriptu. Vyzerá to tak, že s pomocou AI agentov je dnes veľmi jednoduché portovať projekt z jedného frameworku do druhého. Dokonca aj z jedného jazyka do druhého. Ako príklady sme nedávno videli TypeScript alebo Bun. Kedysi nám zvyklo zabrať mesiace a roky vymeniť niečo takéto alebo zorganizovat masívny refaktoring. Dnes sa z toho stáva záležitosť na týždne, dni a občas dokonca hodiny.

Ale stále existujú projekty a firmy, ktoré si zvolili inú cestu a stále vo veľkom spoliehajú na ručný prepis aspoň v kriticky dôležitých častiach ich aplikácie.

Jednou z takých spoločností je Fenris Creations a projekt nie je nič menšie ako EVE Online. Najväčšia online MMORPG hra odohrávajúca sa v jednom sharde (svete). Áno, sú aj väčšie MORPG hry, ale tie majú zväčša množstvo shardov (svetov), v ktorých sa pohybujú ich hráči. V EVE Online hráči zdieľajú jeden svet už vyše 25 rokov. A je to v skutku svet sám o sebe.

Táto hra nie je ľahká (poznáte inú hru, ktoré má oficiálny plugin do MS Office?), ani lacná má vlastnú vyspelú ekonomiku. Čokoľvek v hre viete priamo prerátať na peniaze skutočného sveta. Takže pre tvorcov je veľmi dôležité, aby všetky výpočty prebiehali správne, nech robia akúkoľvek zmenu. Nieto ešte, keď robia kompletný prepis z jedného jazyka do druhého.

A to je presne to, čo práve robia. Prechádzajú z používania Python 2 (už niekoľko rokov sa nevyvíja) na Python 3. Ak vás zaujíma, ako si to naplánovali, aké výzvy musia prekonávať, tak mám pre vás dva zdroje. Jeden článok so všeobecnými informáciami a potom video z konferencie, ktoré ide viac do detailov:

• https://www.eveonline.com/news/view/the-move-to-python-3-begins
• https://www.youtube.com/watch?v=4uaEhx7LNAc

Ak ste EVE Online nepoznali a chcete vedieť viac:

• Zhrnutie na Wikipédii: https://en.wikipedia.org/wiki/Eve_Online
• Jeden z mnohých trailerov (tento má 17 rokov): https://www.youtube.com/watch?v=08hmqyejCYU

• Dokumentárny film "The Making of EVE Online": https://www.youtube.com/watch?v=vnUvuV1QFKk (toto naozaj odporúčam)

Let tak pre zábavu​

Niekto vytvoril Hľadanie mín len v 247 bajtoch JS kódu​

Niekedy len žasnem nad tým, čo niektorí ľudia dokážu a aká je úroveň ich znalostí:

• https://yui.dev/blog/minesweeper-in-247-bytes

Koniec softvérového vývoja 🤣​

Zdroj obrázku: https://www.reddit.com/r/ProgrammerHumor/comments/1wangyc/thelastoreillyjustdropped/

Spojené typy v TypeScript-e​

Článok: https://claritydev.net/blog/typescript-union-types-guide

Alex Khomenko uverejnil 17. marca na svojom blogu článok, kde rýchlo, jasne a jednoducho vysvetľuje, čo sú a ako fungujú spojené typy (union types) v TypeScript-e. Alex ukazuje aj to, akými spôsobmi TypeScript-u pomôžete presnejšie určiť konkrétny typ (type narrowing) a uvidíte aj type guard funkciu, čo je veľmi užitočný konštrukt. Je to fajn čítanie nielen pre učenie sa, ale aj pre osvieženie vedomostí.

Pokiaľ sa učíte TypeScript, tak vám dám tip na celkom dobrú knižku. Napísal ju Josh Goldberg a volá sa Learning TypeScipt.

Návrhový vzor Strategy v React-e​

Článok: https://dev.to/itswillt/applying-design-patterns-in-react-strategy-pattern-enn

Koncom marca sa na dev.to objavilo pokračovanie jedného článku o implementácii návrhového vzoru Strategy v React-e. Odporúčam si prečítať články pekne v poradí, najskôr prvý diel a potom ten druhý.

V prvej časti uvidíte implementáciu Strategy vzoru pomocou tried a v druhej pomocou niečoho, čomu ja hovorím mapovacie objekty. Mapovacie objekty sú fajn, pretože nielenže eliminujú Shotgun Surgery, ale zároveň nám otvárajú možnosti konfigurácie mimo kódu. Pozrite sa napríklad na kód Button.utils.ts z predposledného príkladu. Keby sme mali názvy fieldov a objekty definované mimo funkcie getButtonVariantMapping alebo objektu BUTTON_SIZE_STYLE_MAPPING, tak by sme ich vedeli vyskladať aj dynamicky.

Nie každá situácia a každý projekt však takúto možnosť potrebuje. Je to predsa len komplikácia a ďalšia abstrakcia navyše. Pokiaľ ju však v kóde máme, tak zrazu máme k dispozícii mechanizmus na vytváranie vysoko konfigurovateľných aplikácií.

Tu je približný náčrt, ako by to mohlo fungovať:

const allowedVariants = await loadFromConfiguration();

async function loadFromConfiguration(): Promise<ButtonVariant[]> {
    // tu načítame pole z databázy alebo súboru,
    // vyzerá napríklad takto:
    return ["contained", "outlined", "text"];
}

const getButtonVariantMapping = createButtonVariantMapping(allowedVariants);

function createButtonVariantMapping(allowedVariants: ButtonVariant[]) {
    return function getButtonVariantMapping(color: ButtonColor = "primary") {
        const mapping = {};

        for (const variant of allowedVariants) {
            mapping[variant] = getAvailableButtonVariant(variant, color);
        }

        return mapping;
    };
}

// stále musíme mať miesto, kde sú definované všetky dostupné varianty
function getAvailableButtonVariant(variant: ButtonVariant, color: ButtonColor) {
    const allVariants = {
        contained: {
            backgroundColor: `${color}.main`,
            color: "white",
            "&:hover": {
                backgroundColor: `${color}.dark`,
            },
        },
        outlined: {
            backgroundColor: "transparent",
            color: `${color}.main`,
            border: "1px solid",
            borderColor: `${color}.main`,
            "&:hover": {
                backgroundColor: `${color}.light`,
            },
        },
        // tu budú všetky ostatné varianty
    };

    return allVariants[variant];
}

Ešte si dovolím jednu poslednú poznámku k článku. Pokiaľ sa v kóde snažíte dôsledne dodržiavať SOLID princípy a špeciálne Open-Closed, tak v kóde častokrát dôjdete k implementácii Strategy vzoru úplne prirodzene a možno ani nebudete vedieť, že to nejaký návrhový vzor je. SOLID princípy sú totiž naozaj základným stavebným kameňom dobrej architektúry a všetko ostatné len stavia na nich.

Globálny stav v React-e bez Redux-u a kontextu​

Článok: https://yoavik.com/snippets/use-global-state

Narazil som na článok popisujúci celkom pekné riešenie, ako pomocou základných hookov (useState, useEffect a useSyncExternalStore) dosiahnuť, že v aplikácii budete mať globálny stav bez toho, aby ste použili externý store typu Redux alebo prípadne kontext. Môžete sa z článku inšpirovať pre svoje potreby, prípadne si len pozrieť toto elegantné riešenie.

Nové meta frameworky pre React​

Zistil som, že vznikol nový meta framework Waku. On teda vznikol už v marci 2023, ale v širšom povedomí sa objavil až teraz. Možno sa mýlim, ale predpokladám, že o nových meta frameworkoch založených na React-e budeme v dohľadnej dobe počúvať viac. Jednak príchod React Server Components (RSC) vyslovene láka na to, aby si ich niektorí ľudia vyskúšali naimplementovať po svojom. Zároveň je nie každý spokojný so všetkými aspektami RSC a niektoré ich súčasti chcú robiť po svojom (napríklad namiesto Server Actions používať tRPC alebo niečo podobné). V neposlednom rade nesmieme podceniť ani nespokojnosť veľkej časti vývojárov s tým, ako v Next.js lámu doterajšie paradigmy a s niektorými vecami idú proti štandardom. Myslím si preto, že doba je zrelá a kopa šikovných ľudí už pracuje na vlastných frameworkoch.

Najlepšie spôsoby, ako písať testy s použitím Testing Library​

Článok: https://claritydev.net/blog/improving-react-testing-library-tests

V prípade, že mám medzi čitateľmi niekoho, kto programuje frontend a ešte nepíše testy pomocou Testing Library, tak o veľa prichádza. Naozaj odporúčam sa na knižnicu pozrieť a čo najskôr ju zaradiť medzi svoje používané nástroje.

Testing Library je totiž knižnica, ktorú môžete jednoducho, rýchlo a bez zložitého nastavovania používať vo svojich Jest alebo Vitest testoch (ale aj v iných test runneroch) na overovanie správania vašich komponent. Pokiaľ používate Cypress alebo Playwright, tak vedzte, že Testing Library nie je ich náhradou, ale veľmi vhodným a rýchlejším doplnkom.

A teraz k článku. Alex Khomenko si dal tú prácu a na svojom blogu spísal tipy, ako by sa podľa neho mali písať testy pre Testing Library. Zameral sa síce na jej verziu pre React, ale všetko tam spomenuté platí aj pre iné UI knižnice.

Alex píše o tom, že pokiaľ sa len trochu dá, tak by sme mali elementy v komponente vyhľadávať pomocou *byRole funkcií (v nomenklatúre Testing Library sa týmto funkciám hovorí queries). Vďaka tomu si nepriamo otestujeme, či sú naše komponenty dobre navrhnuté aj z hľadiska prístupnosti a zároveň sa naučíme, ako ich správne vytvárať. A to je veľmi dôležité pre každého návštevníka, ktorý má s používaním nášho webu nejaké problémy (zrakové, ovládacie atď). Alex v článku ukazuje aj nejaké príklady zlých testov, ktoré následne upravuje.

Ďalej v článku rozoberá aj to, prečo by sme mali používať userEvent namiesto fireEvent. Hlavný dôvod je ten, že kým fireEvent len vyvolá udalosť pomocou API prehliadača, tak userEvent simuluje aj ďalšie veci, ktoré by sa udiali, keby udalosť vyvolával skutočný ľudský používateľ.

Pekné príklady Alex vytvoril aj pre návod, ako sa pomocou findBy* vieme zbaviť používania waitFor.

V článku je toho ešte viac, takže pokiaľ Testing Library používate, tak si ho bežte pozrieť a určite sa niečo nové naučíte.

Testing Playground​

Webstránka: https://testing-playground.com/

Z Alexovho článku zmieňovaného vyššie som sa dozvedel o nástroji Testing Playground, ktorý nám pomôže s výberom vhodnej query na nájdenie elementu. Stačí do editora vložiť vygenerované HTML, pobehať myšou po náhľade a sledovať odporúčané query. Nástroj sa snaží preferovať *byRole funkcie, aby sme mali dobrú prístupnosť.

Vike má(?) podporu pre React Server Components​

Stránka v dokumentácii: https://vike.dev/react

Kedysi, keď som potreboval pre svoje SPA aplikácie vo Vue.js alebo React-e pridať aj podporu pre rendrovanie na serveri (SSR) alebo generovať statickú stránku počas buildu (SSG), tak som na to používal plugin pre Vite nazývaný vite-pluggin-ssr. Už vtedy to nebol ani tak plugin, ako skôr nástroj na tvorbu vlastného frameworku pre ľubovoľnú rendrovaciu knižnicu. Medzičasom toho vie tento nástroj ešte viac a autori si to uvedomujú, tak projekt premenovali na Vike.

Keďže som postupne predsa len prešiel na Next.js, tak Vike už tak nesledujem, ale tento týždeň som zistil, že podporujú aj React Server Components. Z troch zložiek RSC majú síce podporu len pre dve: Server Actions a Progressive Rendering a aj z toho pre serverové akcie používajú Telefunc namiesto use server. Niet sa veľmi, čo čudovať. Autorom Telefunc-u je ten istý človek, ktorý stvoril Vike.

Ja som sa na Telefunc len rýchlo pozrel a musím povedať, že to nevyzerá zle. Je to menej magické, ako use server a tak aj jednoduchšie na pochopenie. Možno, keby autori React-u urobili podobné nemagické riešenie, tak by si ušetrili kopu negatívnych komentárov od komunity. Na druhej strane, keď už niekto pochopí, ako serverové akcie fungujú, tak vie, že use server je vlastne len syntax suggar pre niečo také, ako robí Telefunc.

Treťou zložkou RSC sú samotné serverové komponenty a tieto zatiaľ Vike nepodporuje, pretože podľa autorov ešte nie sú vhodné do produkcie (tie v React-e, nie vo Vike). Odporúčajú naďalej používať SSR, SSG a SPA a veria tomu, že malé výkonnostné zisky so serverovými komponentami nestoja za zložitejší programátorský zážitok (DX, Developer eXperience). Nuž, neviem. Mne sa zdá, že programátorský zážitok pred problémami používateľov uprednostňujeme posledných 15 rokov a už je na čase, aby sme hľadali používateľsky vhodnejšie riešenia a to aj za cenu (dočasne) zhoršeného DX.

Vite v Remix-e je stabilná vec​

Oznámenie: https://remix.run/blog/remix-vite-stable

Remix je po Next.js asi druhý najpopulárnejší meta-framework pre React. A na rozdiel od Next.js si v Remix-e dávajú veľmi záležať na tom, aby podporovali štandardné webové API, správanie a štandardy celkovo. Pokiaľ vás štve, že Next.js poslednú dobu na štandardy kašle a niekedy ide vyslovene proti nim a máte slobodu zmeniť framework, tak pouvažujte nad Remix-om.

Remix tím 20. februára oznámil, že sa im podarilo dosiahnuť, aby bolo použite Remix-u spolu s Vite-om stabilné. Je to veľká vec, pretože od tejto chvíle budú všetky nové veci v Remix-e vyvíjané len pre Vite, dokumentácia sa bude postupne upravovať a Remix 3 bude podporovať iba Vite. Je teda čas si naplánovať upgrade.

V oznámení sa píše, že vďaka prechodu na Vite sa v Remix-e urobili nejaké nové architektonické rozhodnutia, alebo sa upravili staré a nevhodné. Menovite to je napríklad nový tzv. SPA mode, ktorý umožňuje vybuildiť celú Remix aplikáciu do statického tvaru, takže nepotrebujete JavaScript na serveri. Upravila sa konfigurácia pre basename, cieľové adresáre pre build a prišli nové spôsoby na oddeľovanie serverového a klientského kódu (.server priečinky, serverOnly$ makro na označovanie kusov kódu).

Noviniek je viac, v oznámení je každej venovaný vlastný priestor aj s linkami na prípadné detailnejšie informácie.

Warp terminál je už aj pre Linux​

Oznámenie: https://www.warp.dev/blog/warp-for-linux

Toto nie je úplne frontendová novinka, ale keďže terminál je nástroj, v ktorom bežne pracujeme, tak som sa rozhodol ju sem zaradiť.

Na Mac-och už programátori mohli nejakú dobu používať terminál Warp, ktorý má príjemný a prívetivejší vizuál a to najmä pre začiatočníkov. Kombinuje terminálové rozhranie s rôznymi menu, dialógmi a comboboxami známymi z bežných aplikácií a tak pôsobí menej nepriateľsky pre "konzolovo-slabých" 😅. Okrem toho má skvelý nápovedný systém (Warp AI) a podporu pre niečo, ako bookmarkovanie príkazov.

Pokiaľ nemáte prácu v termináli radi, alebo chcete krajší zážitok, tak sa na Warp určite pozrite, možno je to niečo, čo hľadáte. Pre niekoho môže byť nevýhodou to, že nejde o open-source projekt.

Koncom februára vyšla verzia Warp-u konečne aj pre Linux, takže keď sa mi jedného dňa znepáči môj aktuálne používaný terminálový emulátor, tak si Warp pridám do kandidátov na preskúmanie.

Keby vás zaujímalo, čo používam ja, tak je to Alacritty. Rýchly terminál s jednoduchou konfigurácou v yaml formáte, rendrujúci cez GPU.

Alacritty však nemá podporu pre taby, čo niekomu môže prekážať. Ja taby nepoužívam a nepotrebujem, pretože namiesto nich mám tmux, čo je oveľa mocnejší nástroj. K tmux-u som napísal aj sériu článkov a natočil videá: predstavenie, moja konfigurácia a návod, ako si pomocou tmux-u viete vytvoriť tzv. štartovacie skripty pre projekty. K videám sa prekliknete priamo z článkov, hneď pod nadpisom je URL na Youtube.

Dám vám tipy aj na ďalšie zaujímavé terminály, na ktoré z času na čas pozriem a chvíľu skúšam:

• kitty - rýchly a pekný terminál pre Linux, macOS a BSD. Má super podporu pre taby, rozdeľovanie okien, skriptovanie a tisíc iných vecí. Škoda, že ich nepotrebujem, lebo mám tmux.

• Terminology - toto je terminál len pre Linux a BSD systémy. Je neuveriteľne rýchly, podporuje taby, rozdeľovanie okien, animované pozadia, prehrávanie videí na pozadí (áno, môžete programovať a za vaším kódom vám beží film). Pre mňa je blbé to, že nespolupracuje dobre s tmux-om, nemá textový konfiguračný súbor (musím používať myš a vyklikávať možnosti!) a jeho stabilita je vecou náhody.

Ešte jeden tip na terminál, ktorý som používal celé roky:

• Terminator je terminál pre Linux, ktorý umožňuje rozdeliť jedno okno na viacero menších a v každom z nich je klasický Gnome Terminal, čo je predvolený terminál v Ubuntu. Používate tak známu klasiku novým spôsobom.

Záver​

Noviniek vo frontende sa udialo samozrejme oveľa viac, než som spomenul. Opäť mám viac novo otvorených tabov v prehliadači čakajúcich na prečítanie, než som ich prečítal a zavrel. Tento týždeň je to o to horšie, že mám novú hračku. Kúpil som si Foundry, čo je pomôcka na hranie dračáku online, tak sa to teraz učím ovládať.

V roku 2023 sme sa v práci rozhodli, že React bude našou knižnicou prvej voľby pre každý nový projekt. A ako odporúčaný framework sme si vybrali Next.js. Rozhodli sme sa tak napriek tomu, že už vtedy bolo vidieť medzi vývojármi rastúcu popularitu signálov a resumability a tieto koncepty nejdú úplne dokopy s filozofiou React-u, kde výzor UI je len jednoduchou funkciou stavu.

React navyše prinášal svoje vlastné riešenie pre problémy s veľkým množstvom JavaScript-u v prehliadači a nabobtnanou hydráciou. Týmto riešením sú React Server Components (RSC) a možno síce nie sú také efektívne, ako resumability v Qwik-u, ale sú v súlade s React filozofiou a tak by mali byť jednoduchšie na pochopenie.

Pre mňa je to dostatočne dobrý dôvod ostať na React-e aj pre firemné, aj pre svoje osobné projekty. Mojou najväčšou výtkou voči RSC je teraz to, že do prehliadača potrebujeme dostať viac JavaScript-u na oživenie stránky, ako by sme potrebovali napríklad v už spomínanom Qwiku. Verím však, že časom prídu optimalizácie a rozdiel nebude taký veľký.

Po tom, čo začal RSC podporovať Next.js (vo verzii 13.4), tak si ich mohlo pomerne jednoducho vyskúšať široké publikum vývojárov. Čo čert nechcel, publikum začalo šomrať.

Posledné týždne sledujem, že k tomuto šomraniu sa pridáva stále viac prominentných vývojárov a komunitných lídrov. Ako príklad uvediem post od Cassidy Williams nazvaný Kind of annoyed at React a ďalší, ktorý napísal Matteo Frana a volá sa React, where are you going?. V tom druhom odporúčam pozrieť sa aj na komentáre, kde Mark Erikson (core vývojár Redux-u a Redux Toolkit-u) prispel svojím názorom.

Človek by ľahko mohol nadobudnúť pocit, že to nevyzerá pre React dobre a možno bude naozaj lepšie sa začať obzerať po nejakej náhrade.

Ja to však až takto čierne nevidím. Prečo? Pretože aj keď problémy, na ktoré ľudia poukazujú, nie sú vymyslené, tak vo svojej podstate pramenia z toho, že React sa mení. A ľudia všeobecne nemajú radi, keď sa ich obľúbené veci menia, ani keby to malo byť k lepšiemu.

Môžeme si to skúsiť len veľmi zrýchlene rozobrať na jednotlivé problémy:

Slabá komunikácia vývojárov React-u s komunitou​

Ľudia sa sťažujú, že React tím slabo komunikuje do sveta svoje zámery a tak nevedia, čo majú čakať. Ja osobne toto nevnímam a môj dojem bol skôr opačný. Mám pocit, že nejaký zástupca hovoril na každej konferencii, ktorú som minulý rok sledoval. Zároveň viem, že som čítal viacero článkov a postov od vývojárov všemožných knižníc o tom, ako teraz intenzívne komunikujú s React tímom ohľadom toho, ako by mohla ich knižnica podporovať RSC.

Treba však povedať, že ja nie som vývojár žiadnej populárnej knižnice a ani žiadna osobnosť v komunite a tak možno len nevidím, že na každého vývojára, s ktorým React tím komunikuje, je 50 ďalších, ktorí na svoje otázky odpovede nedostali.

Otázne podľa mňa je, čím je táto nekomunikácia zo strany React vývojárov spôsobená. Je to odo mňa dosť veľká špekulácia a budúcnosť ukáže, nakoľko sa mýlim, ale podľa mňa môžu byť dôvody aj pomerne prozaické.

React tím teraz vyvíja niekoľko veľkých projektov zároveň, ktoré odčerpávajú energiu. Jednak sú to RSC a veci s nimi súvisiace (actions), potom React compiler (Forget) a totálne prekopanie oficiálnej dokumentácie, ktorá je po novom skôr interaktívnym kurzom.

Vývoj React-u už nezastrešuje len jedna firma (Meta), ale dve (Vercel) a zladiť ich záujmy a komunikačnú stratégiu môže nejaký čas trvať.

Veľa core vývojárov a ešte viac tých ostatných menilo prácu. Meta (a nielen) prepúšťala vývojárov vo veľkom. Títo si museli nájsť nové zamestnanie, ideálne také, aby mohli pokračovať v práci na React-e, uchytiť sa v ňom a prispôsobiť sa novým okolnostiam.

Viem si živo predstaviť, že by mi pri kombinácii takýchto okolností neostávalo veľa času a ani energie na dodatočnú komunikáciu s komunitou. Už len samotná zmena práce vie byť veľmi náročná.

Zložitosť RSC​

Ukazuje sa, že pomerne jednoduchý koncept serverových komponent spôsobuje problémy v detailoch. Musíme zrazu premýšľať, či je možné komponent rendrovať iba na serverovej strane a pokiaľ nie, tak ho označiť ako klientský (use client). Zároveň sa otvára otázka organizácie komponentov v projekte a konkrétne to, či chceme serverové a klientské komponenty držať pokope alebo v oddelených priečinkoch.

Podobne je to s akciami, ktorých kód sa môže nachádzať v súbore s klientským komponentom, ale vykonávajú sa na serveri.

RSC aj pozmenili rovnicu, podľa ktorej bolo vykreslené používateľské rozhranie iba funkciou stavu. Po novom je to už funkcia stavu a dát, pričom dáta sú na serverovej strane a stav na klientskej.

Všetky tieto zmeny vyžadujú iné uvažovanie o aplikácii, o kóde a jeho organizácii. A možno to síce nie je diametrálne iné uvažovanie, ale stále je iné, než na aké sme boli v React aplikácii po celé roky zvyknutí.

Osobne verím tomu, že RSC bol krok správnym smerom a aktuálne sťažnosti na zložitosť odznejú, keď si na nový spôsob premýšľania ľudia viac zvyknú. Nie som ale taký naivný, aby som tvrdil, že všetko okolo RSC bolo navrhnuté dobre. Predsa len ide o veľkú zmenu a očakávam, že o niektorých veciach časom zistíme, že ich treba premyslieť. Nebolo by to prvýkrát (spomeňme si na mixiny alebo triedne komponenty celkovo).

Knižnica alebo framework​

React o sebe doteraz tvrdil, že je iba obyčajnou knižnicou a stále sa toho drží. V čase, keď toto píšem, tak domovská stránka React-u stále definuje React ako "The library for web and native user interfaces".

Knižnice sa vyznačujú tým, že sú iba nástrojom, ktorý môžeme používať tak, ako sa nám hodí a nenútia nás do určitého štýlu alebo architektúry.

Pokiaľ však chceme používať React Server Components, tak nás to tlačí do architektúry, kde nemáme veľa priestoru pre vlastné riešenia.

Mnohých ľudí to hnevá a boli by radšej, keby React rovno priznal, že sa stal frameworkom. Ja si myslím, že React je aktuálne na hrane. Má síce niektoré frameworkové črty, ale nedá sa vyhlásiť za framework. Zo všetkých aktuálne diskutovaných problémov React sveta je tento pre mňa najmenej podstatným.

Nová dokumentácia​

Určitú nevôľu v komunite spôsobuje aj nová dokumentácia k React-u. Konkrétne tá jej časť, ktorá pojednáva o inštalácii. Prečo? Pretože autori v nej odporúčajú používať React spolu s nejakým meta-frameworkom a na výber dávajú Next.js, Remix a Gatsby. Tým trochu nahnevali všetkých, ktorí doteraz používali React bez frameworku a bundlovanie, routing a prípadne aj SSR si riešili takými nástrojmi, aké im vyhovali. Nuž, a keďže Create React App (už nevyvíjaný), Vite a Parcel ponúkajú veľmi jednoduché spôsoby, ako naštartovať nový React projekt, tak takýchto používateľov je väčšina.

Keď sa teda v React dokumentácii zjavilo odporúčanie na používanie frameworku a odhováranie od doterajších metód, tak sa čast ľudí zľakla, či vývoj nesmeruje k tomu, že ich spôsob používania React-u prestane byť podporovaný.

Zdá sa, že toto sa našťastie nedeje a vývojári nám žiadne možnosti nezobrali. Ja situáciu chápem tak, že príchod RSC skomplikuje situáciu všetkým, ktorí používajú vlastnú kombináciu nástrojov a budú chcieť RSC podporovať. Pretože nastaviť si veci správne nemusí byť zrovna triviálne a bude vyžadovať nemalú mieru trpezlivosti. Takže výmena vlastného setupu za nejaký známy framework môže byť pre mnohých ľudí zmysluplnou možnosťou.

Musíme si však priznať aj to, že za týmto odporúčaním je v nemalej miere určite aj snaha viac spropagovať Next.js framework vyvíjaný firmou Vercel.

Monopolizácia používania nových čŕt len pre Vercel a Meta​

Veľkú kritiku od komunity schytáva firma Vercel za to, že vo svojich stabilných verziách frameworku Next.js umožňuje používať vlastnosti z React Canary. Výčitky smerujú k tomu, že pokiaľ sú tieto vlastnosti dostatočne overené a stabilné na to, aby ich Vercel zahrnul do svojho frameworku, tak prečo sa rovno nevydá nová stabilná verzia React-u, kde sa tieto veci sprístupnia všetkým?

Meta a Vercel sú dve firmy, ktoré do vývoja React-u investujú najviac. Dáva tak síce zmysel, pokiaľ nové vlastnosti používajú vo svojich projektoch, ale keďže sa ich Vercel rozhodol použiť nielen v interných nástrojoch, ale priamo v Next.js, tak mu to dáva výhodu oproti iným frameworkom. Vercel má totiž rozhodne lepší vhľad do toho, čo v Canary verzii je vhodné do produkcie, než ostatní. Takže tieto informácie môže použiť a získať tak konkurenčnú výhodu.

Toto správanie od nich nie je pekné, ale kým bude vývoj React-u v rukách veľkých firiem, tak sa to v nejakej miere bude diať stále. Nakoľko je však komunita pobúrená už teraz, tak nie je vylúčené, že sa časom nájde nejaký iný model vývoja a vydávania nových verzií.

Zhrnutie​

Stav okolo React-u a jeho vývoja aktuálne nie je ideálny. Podľa mňa je to však prirodzené, prechádzame veľa zmenami, začíname sa viac sústrediť na server a nejaký čas potrvá, kým sa všetko utrasie. Áno, niektorí používatelia a aj známi ľudia z komunity sa začnú obzerať po alternatívach a viacerí ich aj začnú používať. To je normálne, pretože prebiehajúce zmeny nemusia vyhovovať každému a každého zasiahnu v inej miere.

Myslím si, že aj my by sme sa mali rozhodovať podľa toho, nakoľko nás zmeny ovplyvňujú, koľko problémov riešia a koľko vecí skomplikujú. A nie podľa toho, aké emócie sa aktuálne zdajú byť dominantné na internete.

React from Another Dimension​

Ešte na minuloročnej konferencii RemixConf (Remix je veľmi populárny Reactový framework) mal Dan Abramov, jeden z hlavných vývojárov React-u, veľmi zaujímavú prednášku. Ja som sa k nej dostal len teraz, ale vysoko ju odporúčam. Dan rozpráva veľmi pútavo, odľahčene a dostal tam niekoľko vtípkov. Fakt som sa pri pozeraní bavil a 40 minút ušlo ako voda.

V prednáške sa zamyslel nad tým, ako by vyzeral React, keby sa začal vyvíjať v skorých nultých rokoch (2000-niečo) a keby sme namiesto PHP vtedy na backende používali JavaScript. Vo výsledku nám takto úplne z opačného konca vysvetlil princíp React Server Components (RSC) a ich napojenie na klientskú stranu.

Bola to naozaj dobre pripravená prednáška, z ktorej ide pocit, že RSC sú krok správnym smerom.

Dan v prednáške robí live-coding a všetci vieme, ako to dopadne, keď na prednáške programujete. Preto by som video špeciálne odporúčil každému, kto má impostor syndróm. Uvidíte core vývojára React-u, ako sa trápi s chybami, o ktorých nevie, ako vznikli a čo s nimi. Vidíte, stáva sa aj najlepším.

Video z prednášky je tu https://www.youtube.com/watch?v=zMf_xeGPn6s

Čoskoro vyjde React 19​

Po desiatich mesiacoch(!) vyšiel nový článok na React blogu. Možno je to reakcia na kritiku z komunity o nedostatočnej komunikácii plánov, možno nie. Ktovie. Každopádne sme sa dozvedeli, že čoskoro vyjde nová major verzia React-u. Dátum prezradený nebol, ale keďže v máji bude React Conf, tak to zrejme načasujú takým spôsobom, aby na konferencii s veľkou slávou oznámili nové vydanie.

Čo bude nové?​

React Compiler (Forget), od ktorého si všetci sľubujeme, že nebudeme musieť robiť ručnú memoizáciu a React sám zabezpečí elimináciu zbytočných re-rendrov.

Direktívy "use server" a "use client", ktorými budeme označovať klientské komponenty a serverové funkcie.

Akcie a hooky pre server, ktoré boli doteraz súčasťou Canary releasu, sa presúvajú do stabilnej verzie a tak ich môže používať každý. Ide najmä o hooky useFormStatus, useFormState a Actions. Komunita sa tiež už dlhšie sťažovala, že pokiaľ sú tieto veci dosť stabilné na to, aby ich používala Meta v produkcii a Vercel ich dokonca zahrnul do nových verzií Next.js, tak prečo nie sú v stabilnej verzii React-u? Tak sa teraz konečne dostaneme všetci na rovnakú úroveň a môžeme s novou funkcionalitou pracovať bez toho, aby sme boli nútení použiť Canary release.

Mimochodom, pokiaľ neviete, čo Canary znamená, tak je to verzia, ktorá je síce dostatočne stabilná na to, aby ste ju mohli používať, ale zároveň nie je garantované, že veci v nej sa nezmenia. Prečo sa to volá Canary? Baníci kedysi nosili so sebou do bane klietky s kanárikmi. Pokiaľ v bani začali unikať nebezpečné plyny (napr. CO), ktoré nie je cítiť, tak typicky najskôr umrel kanárik a baníci mali šancu si to všimnúť a ujsť.

Komponenty <title>, <meta> a <link> môžeme použiť hocikde a React sám zabezpečí ich vloženie do hlavičky HTML dokumentu. Zjednoduší sa nám tak tvorba hlavičky.

Koponenty <style>, <link> a <script> budeme môcť prepojiť so Suspense, pretože React bude sledovať, či sa už načítali assety v nich uvedené (fonty, štýly, JS) a do DOM-u sa elementy vložia až po ich načítaní.

Two Reacts​

Aj tretia správa je zo sveta React-u. Dan Abramov uverejnil začiatkom januára článok nazvaný Two Reacts. Ide ďalší pohľad na React zo serverovej strany (alebo aj statického renderovania). Dôležité je, že Dan hovorí o tom, ako príchod RSC zmenil známu rovnicu UI = f(state) (používateľské rozhranie je funkciou stavu) na UI = f(data, state), kde data sú stavom dát na serveri a state je stav v prehliadači. Na konci článku sa Dan pýta, ako teraz pristupovať k funkcii f, keďže musí fungovať v dvoch veľmi rozličných prostrediach? Odpoveď nám zatiaľ nedáva, vyzýva nás na premýšľanie a v nejakom budúcom článku predstaví svoj prístup.

Ink​

Objavil som Ink, čo je projekt prinášajúci React do terminálu. Je to blbosť, ale hrozne sa z toho teším, lebo si budem môcť písať interaktívne CLI programy a skripty v JavaScript-e a React-e. Samozrejme, neodporúčam to na nič, čo by potrebovalo lepší výkon, ale na nejaké jednoduché veci by to mohlo byť super.

Niekto s tým urobili aj hru Hľadanie mín: https://github.com/mordv/mnswpr

Ale nie je to len hračka, na ich Github stránke nájdete v zozname použití aj nejaké seriózne projekty.

Záver​

Vidím, že všetky vybrané správy sa nakoniec týkali React-u. Nebudeme si klamať, keďže je React pre mňa knižnica prvej voľby, keď potrebujem robiť frontend, tak aj veľa budúcich noviniek bude o ňom. Keď však narazím na niečo zaujímavé z iných frontendových oblastí, tak určite napíšem aj o tom.

Liskov Substitution Principle​

Definícia LSP je najpresnejšie vyjadrená matematicky, ale dala by sa prerozprávať zhruba takto:

Podtyp musí byť náhradou svojho rodičovského typu.

Keď si to rozmeníme na situácie, ktorých sa to môže týkať v JavaScripte a TypeScripte, tak dostaneme zhruba takúto množinu:

• odvodená trieda musí byť náhradou svojej základnej triedy
• odvodená trieda musí byť náhradou svojho interface-u
• objekt musí byť náhradou svojho interface-u
• implementácia typu musí byť náhradou svojho typového predpisu

Cieľom princípu je zabezpečiť, aby ste mohli vymeniť implementáciu nejakého rodičovského typu za implementáciu potomka a kód vám bude ďalej bez problémov fungovať.

Aby nejaký potomok alebo implementácia mohli o sebe povedať, že sú dobrými náhradami svojich rodičov, tak to pre nich znamená, že:

• musia poskytovať implementáciu pre všetky metódy, ktoré predpisuje rodič, interface alebo typ
• musia mať rovnaké typy návratových hodnôt z funkcií a metód
• nesmú zvoľňovať typ návratovej hodnoty funkcií a metód
• nesmú sprísňovať požiadavky na argumenty funkcií a metód
• nesmú sprísňovať kontrakt (formálny aj neformálny)
• nesmú obchádzať kontrakt v kóde

Pokiaľ neviete, čo je to kontrakt, tak sú to všetky "dohody" o tom, čo daný kus kódu má robiť. Časť kontraktu sa dá vynútiť prostriedkami programovacieho jazyka (typy parametrov a návratovej hodnoty), ale časť nie a tá je zapísaná len vo forme komentáru, názvov premenných alebo sa dokonca jedná len o predpoklady (napríklad o funkcii getUserId predpokladáme, že vracia ID používateľa).

Ako refaktorovať​

Výhodou LSP oproti ostatným SOLID princípom je to, že veľkú časť jeho porušení vieme odchytiť statickou analýzou kódu a to dokonca už v čase písania. Samozrejme, závisí to od vami používaného jazyka a v čistom JavaScripte sú možnosti značne horšie, ako v TypeScripte.

Statická analýza v TypeScripte nám vie pomôcť najmä s chýbajúcimi metódami, sprísnenými typmi pre parametre funkcií a metódy alebo nesprávnymi návratovými hodnotami.

V JavaScripte si sprísnené požiadavky na argumenty musíme postrážiť sami. V podstate si potrebujeme sledovať, či funkcia, ktorú chceme použiť na mieste nejakej jej nadradenej, nemá striktnejšie požiadavky. Ak sme mali napríklad funkciu, ktorá očakáva v nejakom parametri číslo, tak na jej miesto nemôžeme dať funkciu, ktorá čaká iba číslo z nejakého intervalu. A už vôbec nemôžeme vyhodiť výnimku, ak dané číslo nie je z očakávaného intervalu.

Podobne je to s návratovými hodnotami. Akurát, že tam nemôžeme návratovú hodnotu zvoľniť. Ak nám teda napríklad nejaký predpis, komentár alebo predpoklad hovoria, že funkcia vracia číslo z intervalu, tak nemôžeme vrátiť číslo mimo neho alebo úplne iný typ (napr. string).

Nevýhodou LSP oproti ostatným SOLID princípom je to, že ku každej situácii musíme pristupovať individuálne a nie je možné spísať nejaký algoritmus s konkrétnejšími krokmi refaktoringu. Je však veľmi nápomocné si uvedomiť, že problémy často pramenia z nesprávne zadefinovanej základnej triedy alebo typu. Vtedy je potrebné typy a predpisy upraviť.

Príklad​

Ako príklad si môžeme uviesť situáciu, ktorú vídam pomerne často. Väčšina webstránok má dva typy prihlásených používateľov: bežných návštevníkov a potom administrátorov. Administrátori majú často pridelené rôzne práva, podľa toho, ktorú časť funkcionality môžu obsluhovať.

Definícia typu pre používateľa takéhoto webu by mohla vyzerať aj takto:

interface User {
    getId: () => number;
    getName: () => string;
    getType: () => UserType;
    getFavouriteTvShowId: () => number;
    getAdminRights: () => AdminRight[];
}

V takomto nastavení máme problém minimálne na dvoch miestach našej webovej aplikácie. Na prvom z nich vytvárame inštanciu reprezentujúcu návštevníka:

const user: User = {
    getId: () => 11,
    getName: () => "Ferko Mrkvička",
    getType: () => "visitor",
    getFavouriteTvShowId: () => 42,
    //getAdminRights: () => ??? // čo máme vrátiť tu?
};

Na riadku 6 sa musíme rozhodnúť, aké administrátorské práva má mať bežný návštevník. Z technického hľadiska to nie je problém, lebo môžeme vrátiť prázdne pole. Ale už len to, že je možné takúto otázku ("aké admin práva má mať návštevník?") položiť, je vidieť, že niečo nie je v poriadku.

Druhé problémové miesto je vytváranie inštancie pre administrátora.

const admin: User = {
    getId: () => 101,
    getName: () => "Neo",
    getType: () => "admin",
    //getFavouriteTvShowId: () => ???,
    getAdminRights: () => ["ban-user", "edit-user", "view-user"],
};

Tu sa na piatom riadku dostávame do ešte komplikovanejšej situácie. Administrátor nášho webu nie je bežný návštevník a z hľadiska aplikácie nás jeho obľúbený seriál vôbec nezaujíma. Typ User nám však predpisuje, že ako ID obľúbeného televízneho seriálu musíme vrátiť číslo. My tak nemôžeme vrátiť ani null, ani undefined, ale musí to byť číslo. Môžeme sa dohodnúť, že niektoré čísla (napríklad 0, alebo záporné) budú brané ako špeciálne a ich hodnoty sa nebudú používať na prácu so seriálmi. To by však vyžadovalo zmeny na každom mieste, kde sa pracuje s ID televízneho seriálu. A takýchto miest môže byť veľa a ak zabudneme čo i len na jedno, tak kód môže byť nestabilný. Navyše je to len záplata na problém, ktorý bude naďalej existovať a jedného dňa nevyhnutne prebuble na povrch.

Tým problémom je v skutočnosti to, že potomkovia (inštancia user a admin) nie sú dobrými potomkami svojho rodiča (typový predpis User). A ani nemôžu nikdy byť, pretože samotný rodič je zadefinovaný tak, že to neumožňuje.

Úprava kódu tak, aby mohol spĺňať LSP znamená, že musíme zmeniť typový predpis rodiča takým spôsobom, aby obsahoval iba tie položky, ktoré sú spoločné pre každého používateľa webstránky. Zároveň potrebujeme zadefinovať nové typy pre návštevníka a pre administrátora a tam, kde je potrebné medzi nimi rozlišovať, musíme nastaviť typehinty podľa toho, akého typu inštanciu očakávame.

interface User {
    getId: () => number;
    getName: () => string;
    getType: () => UserType;
}

interface Visitor extends User {
    getFavouriteTvShowId: () => number;
    getType: () => "visitor";
}

interface AdminUser extends User {
    getAdminRights: () => AdminRight[];
    getType: () => "admin";
}

Zhrnutie​

LSP vraví, že pokiaľ máme v kóde nejakú hierarchiu (objektov, typov), tak ju treba stavať tak, aby sme inštancie rodičov mohli vymieňať za inštancie potomkov bez hrozby spadnutia kódu. Hoci sa táto požiadavka môže javiť triviálna, tak to tak nemusí vždy byť a to najmä v situáciách, kde si nevieme pomôcť statickou analýzou kódu.

Aby mohli byť potomkovia dobrými náhradami svojich rodičov, tak musia poskytovať implementáciu pre všetky predpísané metódy, nemôžu zvoľňovať typ návratových hodnôt, nesmú sprísňovať kontrakt a požiadavky na argumenty a ani obchádzať kontrakt.

Pokiaľ sa tohto držíme, tak zistíme, že časti nášho kódu sú navzájom bezpečne vymeniteľné a úplne sme eliminovali chyby spôsobené nedodržiavaním kontraktov.

Open-Closed Principle​

V literatúre a článkoch sa s týmto princípom môžeme stretnúť aj pod skratkou OCP. Jeho definícia znie:

Jednotka kódu by mala byť otvorená pre rozširovanie, ale uzatvorená pre zmeny.

Už z predchádzajúceho článku vieme, že za slovné spojenie jednotka kódu si môžeme dosadiť čokoľvek z množiny trieda, modul, objekt a funkcia. Ale aj keď to urobíme, tak nám definícia na prvé počutie nemusí vôbec dávať zmysel.

Trochu zmysluplnejšie nám môže znieť, že Open-Closed Principle hovorí, nech kód píšeme tak, aby sme vedeli rozšíriť jeho funkcionalitu aj bez toho, aby sme ho museli upraviť.

Znie to síce trochu magicky, ale čoskoro si ukážeme, že to nie je nič zložité.

Ak sa nám v našom kóde podarí spĺňanie tohto princípu dosiahnuť, tak odmenou nám budú bezpečnejšie a rýchlejšie úpravy funkcionality, pretože budeme robiť minimálne alebo žiadne zásahy do kódu.

Symptómy porušenia princípu​

Pokiaľ uvažujeme, či nejaká jednotka nášho kódu spĺňa OCP, tak si môžeme pomôcť príznakmi toho, kedy to tak nie je. Platí však to isté, čo aj pri Single Responsibility Principle: tieto príznaky hovoria len o tom, že je vyššia pravdepodobnosť nesplnenia princípu. Nehovoria, že to tak určite je.

Príznaky porušenia OCP princípu v nejakej jednotke sú:

• v kóde sú podmienky pre určenie stratégie (typicky napríklad switch)
• podobné podmienky sa opakujú na viacerých miestach v kóde
• kód obsahuje natvrdo zapísaný názov súboru, emailovú adresu alebo inú skalárnu hodnotu
• trieda v sebe obsahuje natvrdo zapísané názvy iných tried (v poliach, stringoch, podmienkach)
• vo vnútri triedy sa vytvárajú iné objekty pomocou new (výnimkou sú továrničky)

Ako refaktorovať​

V prípade, že máme hotový kód nejakej jednotky (povedzme funkcie) a tento nespĺňa OCP, tak ho vieme refaktorovať v piatich krokoch. Časom sa tento postup pre nás stane takým automatickým, že ho budeme vediet aplikovať na jeden prepis. Ale kým v tom nie sme zbehlí, tak je lepšie sa držať postupu krok za krokom.

1. zabezpečíme, že jednotka spĺňa Single Responsibility Principle
2. skúsime identifikovať všeobecné a špecifické časti úlohy, ktorú jednotka rieši
3. oddelíme všeobecné a špecifické časti od seba (vo vnútri jednotky)
4. špecifické časti prenesieme von mimo jednotku
5. všeobecnú a špecifickú časť prepojíme pomocou "konfigurácie"

Pokiaľ nám zoznam týchto krokov znie rovnako magicky, ako samotná definícia princípu, tak sa netreba báť, v nasledovnom príklade uvidíme, že to nie je také strašidelné.

Príklad​

Riadky kódu, ktoré sú podobné ukážke nižšie, môžeme vidieť pomerne často. Na prvý pohľad vyzerajú celkom v poriadku. Ale pri bližšom pohľade uvidíme problémy.

import type { Character } from "@local/types";
import { sortCharactersByRole } from "./sortCharactersByRole";

export async function getSortedCharacters() {
    const characters = await loadCharacters();

    return sortCharactersByRole(characters);
}

async function loadCharacters() {
    const result = await fetch("/api/list.json");

    return (await result.json()) as Promise<Character[]>;
}

Zamerajme sa na funkciu loadCharacters. Čo keby sme chceli, aby zoznam postáv načítavala z inej URL? Museli by sme siahnuť do jej vnútra a zmeniť jej kód. A toto je znak toho, že nespĺňa OCP. Chceme ju rozšíriť, ale musíme ju zmeniť. Keby spĺňala OCP, tak by sme ju vedeli rozšíriť aj bez toho, aby sme ju museli meniť.

Ako na to? Aplikujeme náš refaktorovací algoritmus.

Krok 1: Zabezpečíme, že jednotka spĺňa Single Responsibility Principle​

Tu našťastie nemusíme nič robiť, funkcia už spĺňa SRP. Keby to tak nebolo, tak tento krok je nutným.

Krok 2: Skúsime identifikovať všeobecné a špecifické časti úlohy, ktorú jednotka rieši​

Toto v tejto funkcii opäť nie je žiaden veľký problém. Špecifickou časťou je natvrdo zapísaná URL.

Krok 3: Oddelíme všeobecné a špecifické časti od seba (vo vnútri jednotky)​

Oddelenie všeobecných a špecifických častí je lepšie najskôr robiť priamo vo vnútri funkcie. Vizuálne tak uvidíme rozdiel, ktorý sme v predchádzajúcom kroku vytušili a pomenovali. A takéto zvýraznenie nám môže pomôcť v neskoršom rozhodovaní, čo s tým.

V tejto situácii toho nemáme na práci veľa, potrebujeme len špecifickú URL nejako oddeliť a zvýrazniť. Najjednoduchšie, čo môžeme urobiť, je vytiahnuť ju do samostatnej premennej.

async function loadCharacters() {
    const url = "/api/list.json";

    const result = await fetch(url);

    return (await result.json()) as Promise<Character[]>;
}

Krok 4: Špecifické časti prenesieme von mimo jednotku​

V tomto kroku potrebujeme URL dostať von z funkcie. Je niekoľko spôsobov, ako to urobiť. Najpriamočiarejší je urobiť z nej globálnu premennú, čo však nie je vôbec dobrý nápad. Globálne premenné sú vo všeobecnosti prvok, ktorý prináša do kódu veľa neprehľadných rizík a tak sa im snažíme vyhýbať.

Druhou jednoduchou možnosťou by bolo urobiť z premennej parameter funkcie. A presne to je riešenie, ktoré je v tejto situácii správne.

async function loadCharacters(url) {
    const result = await fetch(url);

    return (await result.json()) as Promise<Character[]>;
}

Krok 5: Všeobecnú a špecifickú časť prepojíme pomocou "konfigurácie"​

Zmenou v kroku 4 sme dosiahli, že funkcia loadCharacters je teraz konfigurovateľná. Zároveň už funkcia spĺňa aj OCP, pretože ju vieme rozšíriť o možnosť načítavať údaje z inej URL a pritom nemusíme modifikovať jej telo. Je teda otvorená pre rozširovanie, ale uzatvorená pre zmeny.

Aby nám však kód naďalej fungoval, tak teraz musíme nájsť všetky miesta, kde sa funkcia volá a dodať tam želanú URL.

export async function getSortedCharacters() {
    const characters = await loadCharacters("/api/list.json");

    return sortCharactersByRole(characters);
}

async function loadCharacters(url) {
    const result = await fetch(url);

    return (await result.json()) as Promise<Character[]>;
}

Tento krok by sme však nemali robiť bezhlavo. Treba sa zamyslieť jednak nad viacerými spôsobmi prepojenia a nad ich dôsledkami a vybrať si ten, ktorý nám vyhovuje najviac.

Zmena urobená vyššie je možno pre túto situáciu jednoduchá, lebo funkcia je volaná iba na jednom mieste, takže to vieme urobiť ľahko a rýchlo. Ale tým, že sme robili zmenu v inej funkcii (getSortedCharacters), tak sa teraz musíme pýtať, či táto druhá funkcia po zmene stále spĺňa Single Responsibility Principle a zároveň aj Open-Closed Principle.

Už asi tušíme, že OCP nespĺňa. Pretože sme v nej vytvorili rovnakú situáciu, akú sme mali na začiatku vo funkcii loadCharacters. Zároveň nespĺňame ani SRP, pretože okrem triedenia postáv má funkcia v zodpovednosti aj znalosť o URL na načítanie dát.

Veľmi dôležitou je aj otázka, či getSortedCharacters má vôbec niečo vedieť o nejakej URL. Je to funkcia, ktorá podľa názvu robí triedenie a dáta si len pýta od druhej funkcie. Pre svoju činnosť by nemala potrebovať poznať žiadnu URL a dokonca by jej malo byť jedno, akým spôsobom funkcia loadCharacters dáta získava.

Čo teraz s tým? Môžeme skúsiť aplikovať refaktorovacie kroky odznova na funkciu getSortedCharacters, čo nás zrejme privedie k poznaniu, že musíme nanovo premyslieť architektúru. Tento spôsob nemusí byť zlý, ale ukážeme si, že pre spĺňanie OCP princípu nám častokrát stačí dosiahnuť potenciál a nemusíme ho hneď využiť.

Ten potenciál je v tom, že chceme, aby sme funkcii loadCharacters mohli zvonka povedať URL, z ktorej má načítať údaje. Dôlezité je slovíčko mohli. Na dosiahnutie tohto nám úplne postačí dať parametru url defaultnú hodnotu. Výsledný kód vyzerá takto:

export async function getSortedCharacters() {
    const characters = await loadCharacters();

    return sortCharactersByRole(characters);
}

async function loadCharacters(url = "/api/list.json") {
    const result = await fetch(url);

    return (await result.json()) as Promise<Character[]>;
}

A toto je dostatočne dobré. Funkcia loadCharacters spĺňa OCP a keďže sme do getSortedCharacters nezasahovali, tak sa nad ňou nemusíme zamýšľať.

Defaultný parameter je celkom pekné riešenie pre túto situáciu, v iných však nemusí byť dostatočné. Pokiaľ by vás zaujímali iné spôsoby, tak by ste mohli skúsiť:

• uložiť URL do enumu, konštanty alebo zoznamu URL v nejakom konfiguračnom súbore
• modul (súbor) bude mať privátnu premennú držiacu URL a bude exportovať funkciu na jej nastavenie z vonka
• loadCharacters si URL vypýta z nejakého "registra"

Zhrnutie​

Open-Closed Principle nám vraví, že je dobré písať kód tak, aby bol otvorený pre rozširovanie funkcionality, ale uzatvorený pre zmeny kódu.

Na jednom príklade sme si ukázali jednu z najčastejších situácií, kedy je princíp porušený a postupným refaktoringom sme dosiahli spĺňanie princípu.

Je dôležité si uvedomiť, že nie je možné dosiahnuť taký stav kódu, kde nemusíme robiť žiadne zmeny a všetko bude možné urobiť len úpravou konfiguračných hodnôt. OCP teda nie je možné aplikovať absolútne. Limitom je pre nás zodpovednosť upravovanej jednotky. Pokiaľ sa táto zodpovednosť nemení, tak by dosiahnutie OCP nemalo byť zložité. Preto je zároveň dôležité, aby sme spĺňali princíp jedinej zodpovednosti.

Single Responsibility Principle​

V každom článku sa budem venovať jednému zo SOLID princípov. Prvým na rade je Single Responsibility Principle. Tento princíp má skratku SRP, do slovenčiny sa prekladá ako "Princíp jedinej zodpovednosti" a jeho definícia znie nasledovne:

Trieda by mala mať iba jeden dôvod pre svoju zmenu.

Pristavme sa chvíľu pri tom, že kým názov hovorí o zodpovednostiach, tak definícia o dôvodoch pre zmenu. Prečo zrazu ten rozdiel? Porozmýšľajte.

Keď si skúsite vymenovať dôvody, pre ktoré by ste mohli chcieť upraviť kód nejakej triedy, tak zistíte, že to sú všetko veci, ktoré daná trieda rieši. A keď ich rieši, tak je za ne zodpovedná. Sú to jej zodpovednosti. Takže vlastne medzi zodpovednosťou a dôvodom pre zmenu nie je rozdiel.

Trieda by teda mala mať jednu jedinú zodpovenosť a tým pádom jeden jediný dôvod pre svoju zmenu.

Ako som ale spomínal. Princípy sú všobecné a neplatia len pre OOP jazyky a pre triedy. Ako by teda mala znieť definícia SRP pre JavaScript?

Jednotka kódu by mala mať iba jeden dôvod pre svoju zmenu.

Pod pojmom "jednotka kódu" si môžete predstaviť čokoľvek z množiny: trieda, modul (súbor), objekt a funkcia. Princíp sa totiž aplikuje na všetko.

Dôležité je uvedomiť si, že pri pomenovávaní tej jedinej zodpovednosti nejakej jednotky by ste nemali použiť spojku "a"

Výhody dodržiavania Single Responsibility Principle​

Pokiaľ píšeme kód tak, že dodržiavame SRP, tak dosiahneme:

• jednoduchšie úpravy miernym prepisom alebo výmenou jednotky
• bezpečnejšie neskoršie úpravy, lebo v kóde nie sú nesúvisiace veci
• jednoduchšie pochopenie toho, čo jednotka robí
• ľahkú testovateľnosť jednotky vyplývajúcu zo skôr vymenovaných bodov

Symptómy porušenia princípu​

Ak chcete zistiť, či jednotka, na ktorú sa práve pozeráte, spĺňa tento princíp alebo nie, tak si môžete skúsiť vymenovať dôvody zmien, pre ktoré by ste ju museli niekedy prepísať. Našli ste iba jeden? Gratulujem, jednotka pravdepodobne spĺňa SRP. Problém je trochu v tom, že ak zodpovednosť (dôvod pre zmenu) pomenujeme všeobecnejšie, tak sa v nej ľahko schovajú zodpovenosti dve (alebo aj viac). Bohužiaľ, na rozpoznanie tohto rizika pomôže len prax.

Našťastie existuje niekoľko vzorov, ktoré je pri porušení princípu zvyčajne dobre vidieť. Ak ich v kóde vami skúmanej jednotky vidíte, tak je vysoká pravdepodobnosť, že SRP porušuje. Nie je to zaručené, ale šanca je vysoká.

Nuž a aké tieto vzory sú?

Pre triedy a objekty:

• trieda/objekt má priveľa properties
• každá metóda používa iné properties
• špecifické úlohy sú delegované na privátne metódy

Pre moduly:

• modul má priveľa premenných
• každá funkcia modulu používa iné premenné modulu
• špecifické úlohy sú delegované na skryté (privátne, neexportované) funkcie

Pre funkcie:

• funkcia má priveľa riadkov (50 je veľa, pri 30 by nám mala blikať kontrolka)
• funkcia obsahuje komentáre, ktoré pomenovávajú jej časti
• je možné funkciu rozdeliť na viacero menších podľa logických celkov
• funkcia má priveľa úrovní vnorenia vytvorených pomocou podmienok a cyklov (2 úrovne vnorenia sú rozumné maximum)

Ako refaktorovať​

Keď už viete, že nejaký kód porušuje SRP, tak refaktoring spočíva z troch krokov:

1. extrahujete špecifické úlohy do pomocných funkcií (prípadne metód)
2. identifikujete skrytých kolaborantov
3. prenesiete skrytých kolaborantov do samostatných modulov

Skrytý kolaborant je funkcia, ktorá dokáže existovať sama o sebe a v skutočnosti nemá žiadne silné previazanie na logiku skúmanej jednotky.

Ja pri uvažovaní o tom, či je nejaká pomocná funkcia skrytým kolaborantom, ktorého treba preniesť, alebo len pomocnou funkciou, ktorá má ostať v aktuálnom module, zvažujem to, či mi dáva zmysel, aby funkciu volala aj nejaká iná časť aplikácie. Ak je na to teoretická šanca, tak ju presúvam do samostatného (alebo iného už existujúceho) modulu.

Príklad​

Dobre sa pozrite na tento kód. Je to kód, ktorý sa podobá tomu, čo často vidieť v úvodných skriptoch React aplikácií, kde sa deje ich inicializácia. Ja som príklad značne zjednodušil a máme tu len načítanie úvodných dát a namontovanie React aplikácie. Kvôli jednoduchosti som neriešil žiadne skeletony, routovanie, preklady, lazy loading a React hlúpo čaká na to, kým dobehne ajaxový request. Ale pre účely učenia sa Single Responsibility Principle je to dostatočné.

import React from 'react';
import ReactDOM from 'react-dom/client';
import App from './App';
import { Character, RoleName } from './types';

const commanders: Character[] = [];
const ambassadors: Character[] = [];

const result = await fetch('/api/list.json');
const data = await result.json();

data.forEach((character: Character) => {
    if (character.role === RoleName.Commander) {
        commanders.push(character);
    } else if (character.role === RoleName.Ambassador) {
        ambassadors.push(character);
    }
});

ReactDOM.createRoot(document.getElementById('root') as HTMLElement).render(
    <React.StrictMode>
        <App commanders={commanders} ambassadors={ambassadors} />
    </React.StrictMode>
);

Zamyslite sa nad tým, koľko zodpovedností má tento kus kódu? Pri akých dôvodoch by ste do neho museli siahnuť a niečo zmeniť?

Ja som narátal dve hlavné zodpovednosti:

• získanie inicializačných dát
• namontovanie React aplikácie

Keďže sú zodpovednosti dve, tak už vieme, že kód nespĺňa SRP a mali by sme ho refaktorovať. Prvým krokom je extrahovanie špecifických úloh do pomocných funkcií.

Krok 1: Extrahovanie špecifických úloh do pomocných funkcií​

V programovaní je mimoriadne dôležité používať dobré pomenovania. Funkcia by mala byť pomenovávaná tak, aby nám už z názvu bolo jasné, čo je jej úlohou. Pri dodržiavaní SRP je tento názov zároveň veľmi často aj pomenovaním jej hlavnej zodpovednosti. Ja ich preto nazvem: getInitialData a mountApp.

import React from 'react';
import ReactDOM from 'react-dom/client';
import App from './App';
import { Character, RoleName } from './types';

async function getInitialData() {
    const commanders: Character[] = [];
    const ambassadors: Character[] = [];

    const result = await fetch('/api/list.json');
    const data = await result.json();

    data.forEach((character: Character) => {
        if (character.role === RoleName.Commander) {
            commanders.push(character);
        } else if (character.role === RoleName.Ambassador) {
            ambassadors.push(character);
        }
    });

    return {
        commanders,
        ambassadors,
    };
}

function mountApp(initialData: { commanders: Character[]; ambassadors: Character[] }) {
    ReactDOM.createRoot(document.getElementById('root') as HTMLElement).render(
        <React.StrictMode>
            <App commanders={initialData.commanders} ambassadors={initialData.ambassadors} />
        </React.StrictMode>
    );
}

mountApp(await getInitialData());

Trochu sa nám síce zvýšil počet riadkov v kóde, ale to nevadí. Počet riadkov nemá absolútne žiaden vzťah ku kvalite kódu. Našich riadkov je viac, ale čitateľnosť je vyššia.

Krok 2: Identifikovať skrytých kolaborantov​

Máme teda kód v module rozdelený do dvoch funkcií, z ktorých každá je zodpovedná za niečo iné. Teraz sa musíme rozhodnúť, ktoré z týchto funkcií sú prirodzené pre tento modul a je vhodné, aby v ňom ostali. A na druhej strane nájsť také, ktoré nie sú špecifické pre modul a sú teoreticky všeobecne použiteľné.

Najskôr si však musíme povedať, čo je primárnou zodpovednosťou modulu (súboru src/index.tsx). Podľa mňa to je spustenie aplikácie.

Mne sa potom ako jednoznačný kandidát na skrytého kolaboranta javí funkcia getInitialData. Zdá sa, že ona poskytuje dáta z nejakého endpointu a kľudne by si rovnaké dáta mohla vypýtať aj iná časť našej aplikácie. Presunul by som ju preto do samostatného modulu.

Trochu ťažšie je to s funkciou mountApp. Tú na prvý pohľad už zrejme v inej časti aplikácie nepoužijeme. Ale naozaj je to tak? Čo keby sme ju chceli otestovať automatizovanými testami? Navyše si viem predstaviť, že pre spustenie aplikácie (primárna zodpovednost modulu) nemusíme zavolať práve túto mountApp. Možno budeme chcieť iný spôsob montovania pre produkčné alebo nejaké špeciálne prostredie. Takže osamostatníme aj mountApp.

Krok 3: Presun skrytých kolaborantov do samostatných modulov​

Funkcia getInitialData rieši získavanie dát o nejakých postavách. Presuniem ju preto do súboru src/services/character/characterRepository.ts.

import { Character, RoleName } from "./types";

export async function getInitialData() {
    const commanders: Character[] = [];
    const ambassadors: Character[] = [];

    const result = await fetch("/api/list.json");
    const data = await result.json();

    data.forEach((character: Character) => {
        if (character.role === RoleName.Commander) {
            commanders.push(character);
        } else if (character.role === RoleName.Ambassador) {
            ambassadors.push(character);
        }
    });

    return {
        commanders,
        ambassadors,
    };
}

Funkcia mountApp je služba používateľského rozhrania. Tú dám do súboru src/services/ui/mountApp.tsx.

import React from 'react';
import ReactDOM from 'react-dom/client';
import { Character } from '@local/services/character/characterRepository';
import App from '@local/App';

function mountApp(initialData: { commanders: Character[]; ambassadors: Character[] }) {
    ReactDOM.createRoot(document.getElementById('root') as HTMLElement).render(
        <React.StrictMode>
            <App commanders={initialData.commanders} ambassadors={initialData.ambassadors} />
        </React.StrictMode>
    );
}

export default mountApp;

Po týchto presunoch vyzerá src/index.tsx takto:

import { getInitialData } from "@local/services/character/characterRepository";
import mountApp from "@local/services/ui/mountApp";

mountApp(await getInitialData());

Oveľa čitateľnejšie. Už z názvov funkcií je jasné, čo sa kde rieši.

Hoci sme si prešli všetkými troma bodmi, ktoré nám hovoria, ako refaktorovať jednotku, ktorá nespĺňa SRP, tak ešte nemáme hotové všetko. Dosiahli sme, že modul index.tsx už spĺňa Single Responsibility Principle. Ale aby sme mohli povedať, že s refaktoringom sme skončili, tak by sme sa mali pozrieť aj na všetky novo vytvorené funkcie. Spĺňajú oni tiež tento princíp?

mountApp je z tohto pohľadu celkom v poriadku. Sú tam síce nejaké problémy, ale tie už patria pod Open-Closed Principle, o ktorom si povieme nabudúce.

Horšie to je s funkciou getInitialData. Skúste pomenovať jej zodpovednosti. Pri akých dôvodoch by ste potrebovali siahnuť na jej kóde a zmeniť ho?

Ja vidím dva dôvody:

• získavanie dát z backendu
• filtrovanie dát

Čo s tým budeme robiť? Presne to isté, čo aj s modulom index.tsx a aplikujeme rovnaký algoritmus. Extrahujeme kód do pomocných funkcií. Potom sa zamyslíme, či niektoré z funkcií sú skrytými kolaborantami a pokiaľ áno, tak ich presunieme do iných modulov.

Urobme prvý krok:

import { Character, RoleName } from "./types";

export async function getInitialData() {
    const characters = await loadCharacters();

    return filterCharactersByRole(characters);
}

async function loadCharacters() {
    const result = await fetch("/api/list.json");

    return (await result.json()) as Promise<Character[]>;
}

function filterCharactersByRole(characters: Character[]) {
    const commanders: Character[] = [];
    const ambassadors: Character[] = [];

    characters.forEach((character: Character) => {
        if (character.role === RoleName.Commander) {
            commanders.push(character);
        } else if (character.role === RoleName.Ambassador) {
            ambassadors.push(character);
        }
    });

    return { commanders, ambassadors };
}

Druhým krokom je premýšľanie o tom, či niektorá z funkcií je skrytým kolaborantom. loadCharacters je pomerne úzko spätá s primárnou zodpovednosťou modulu characterRepository, ktorým je poskytovanie prístupu k zoznamu postáv. Tým pádom si myslím, že funkcia je len pomocnou pre tento modul a ako taká môže ostať jeho súčasťou.

Avšak, silné podozrenie na skrytého kolaboranta mám pri funkcii filterCharactersByRole. Ide len o filtrovanie zoznamu postáv, ktoré dostane v argumente. Nie je žiaden špeciálny dôvod na to, aby táto funkcia bola silno prepojená na modul poskytujúci prístup k zoznamu postáv. Vytiahneme ju teda von. Ja som zvolil súbor src/services/character/filterCharacters.ts. Výsledok by mohol vyzerať takto:

import { Character } from "./types";
import { filterCharactersByRole } from "./filterCharacters";

export async function getInitialData() {
    const characters = await loadCharacters();

    return filterCharactersByRole(characters);
}

async function loadCharacters() {
    const result = await fetch("/api/list.json");

    return (await result.json()) as Promise<Character[]>;
}

import { Character, RoleName } from "./types";

export function filterCharactersByRole(characters: Character[]) {
    const commanders: Character[] = [];
    const ambassadors: Character[] = [];

    characters.forEach((character: Character) => {
        if (character.role === RoleName.Commander) {
            commanders.push(character);
        } else if (character.role === RoleName.Ambassador) {
            ambassadors.push(character);
        }
    });

    return { commanders, ambassadors };
}

V tejto chvíli by sme refaktoring pre potreby spĺňania SRP mohli vyhlásiť za skončený. Ostala nám však jedna drobnosť, ktorá nie je úplne v poriadku. Názov funkcie getInitialData dáva zmysel iba v kontexte modulu index.tsx. Avšak my sme z nej pred chvíľkou zistili, že to je všeobecne použiteľná funkcia. Pokiaľ ju bude volať niečo iné v našej aplikácii, tak názov getInitialData bude celkom mätúci. Vhodnejšie pomenovanie by mohlo byť getFilteredCharacters.

Urobme patričné úpravy a už sme naozaj skončili.

import { Character } from "./types";
import { filterCharactersByRole } from "./filterCharacters";

export async function getFilteredCharacters() {
    const characters = await loadCharacters();

    return filterCharactersByRole(characters);
}

async function loadCharacters() {
    const result = await fetch("/api/list.json");

    return (await result.json()) as Promise<Character[]>;
}

import { getFilteredCharacters } from "@local/services/character/characterRepository";
import mountApp from "@local/services/ui/mountApp";

mountApp(await getFilteredCharacters());

Zhrnutie​

Ukázal som vám, ako v JavaScripte a TypeScripte rozpoznáte porušenie Single Responsibility Principle a akým postupom viete kód upraviť, aby tento princíp spĺňal.

Možno vás niektorých napadlo, že kým na začiatku sme mali jeden súbor s 24 riadkami kódu, tak na konci už máme súbory štyri a dokopy okolo 50 riadkov kódu. Opticky to teda vyzerá tak, že sme zvýšili komplexnosť a tým stratili prehľadnosť. Takže kde je ten benefit?

Hoci nám vzniklo viac súborov a funkcií, tak všetky tieto sú krátke.

Nové funkcie a aj moduly vieme použiť v iných častiach našej aplikácie a možno ich aj vytiahnuť do inej aplikácie.

Funkcie aj súbory sú dobre pomenované a pokiaľ do nich nepotrebujeme siahať, tak nemusíme študovať ich kód. Ak by sme potrebovali urobiť zmenu, tak podľa názvu vieme nájsť správny modul a funkciu, kde túto zmenu bude potrebné urobiť.

Potrebnú zmenu urobíme jednoduchšie, lebo v kóde funkcie sa nám nepletú pod ruky nesúvisiace veci.

A v neposlednom rade vieme funkcie otestovať samostatne a izolovane.

S použitím tmux-u to bolo ľahké. Proste som si napísal shellovský skript, kde som najskôr vytvoril session (tmux new-session), pootváral taby (tmux new-window) a v každom tabe spustil to, čo som potreboval (tmux send-keys).

Pre každý projekt mám takto urobený samostatný spúšťací skript. Niektoré sú zložitejšie, iné jednoduchšie. Napríklad skript spúštaný vtedy, keď idem napísať článok pre tento blog je pomerne jednoduchý.

Blog je robený v Gatsby a keď s ním idem pracovať, tak môj setup spočíva v tom, že otvorím tmux session s tromi oknami. V jednom je neovim, v druhom spustím server pre gatsby a tretí tab je len terminál v adresári, odkiaľ spúštam deploy.

Skript vyzerá takto:

#!/bin/bash

# ako sa má volať tmux session
SESSION_NAME=hrad

# ak už session bola spustená, tak sa len pripojím
if tmux has-session -t=$SESSION_NAME 2>/dev/null; then
    tmux attach -t $SESSION_NAME
    exit
fi

# prepnem sa do adresáru s projektom
cd ~/projects/perunhq.org/hrad.perunhq.org

# spustím session s prvým tabom, ale detachnem sa
tmux new-session -d -s $SESSION_NAME -n src

# otvorím ďalšie taby
tmux new-window -n gatsby
tmux new-window -n deploy

# v tabe `src` spustím nvim
tmux send-keys -t $SESSION_NAME:src "cd web" Enter "nvim" Enter
# v tabe `gatsby` spustím dev server
tmux send-keys -t $SESSION_NAME:gatsby "cd web" Enter "gatsby develop" Enter
# v tabe `deploy` nerobím nič, len sa prepnem do adresáru, odkiaľ neskôr spustím deploy
tmux send-keys -t $SESSION_NAME:deploy "cd deploy" Enter

# keď je hotovo, tak sa pripojím do session a môžem písať
tmux attach -t $SESSION_NAME:src

Bez komentárov je to 21 riadkov kódu, čo je celkom fajn. Skript som si uložil pod názvom hrad.sh a s právami na spúšťanie (chmod 755 hrad.sh) do adresára ~/bin, ktorý je v mojej $PATH. Tým pádom ho viem odkiaľkovek spustiť zadaním príkazu:

hrad.sh

No a takto to vyzerá hneď po spustení:

Ukončenie session​

Ukončenie je jednoduché, ak nemáte v žiadnom okne spustené niečo, čo sa netriviálne ukončuje. Stačí spustiť príkaz:

tmux kill-session -t nazov-session

Ak je v niektorom okne niečo netriviálne, tak sa to dá najskôr pomocou tmux send-keys ukončiť a upratať a potom môže nastúpiť tmux kill-session.

Znovupoužiteľná funkcia na otváranie session​

Keďže vo veľa štartovacích skriptoch sa mi objavoval stále rovnaký kód pre vytvorenie session a toto je pre programátora signál, že niečo je možné abstrahovať a vytiahnuť do samostatnej funkcie, tak som urobil funkciu pre naštartovanie session.

Jej aktuálny kód je v repozitári tmux-functions na Bitbuckete, v čase písania tohto textu vyzerá nasledovne:

start_session_and_open_windows() {
    local SESSION_NAME=$1
    shift
    local WINDOW_NAMES=("$@")

    if [ -n "$TMUX" ]; then
        echo "Can not run inside another tmux session"
        exit
    fi

    if tmux has-session -t=$SESSION_NAME 2>/dev/null; then
        tmux attach -t $SESSION_NAME
        exit;
    fi

    tmux new-session -d -s $SESSION_NAME -n ${WINDOW_NAMES[0]}

    for i in ${!WINDOW_NAMES[@]}; do
        if [ $i -eq 0 ]; then
            continue
        fi

        local WINDOW_NAME=${WINDOW_NAMES[$i]}

        tmux new-window -n $WINDOW_NAME
    done
}

Stačí si ju naimportovať do skriptu, pri zavolaní jej odovzdať názov pre session a pre okná. V repozitári je aj ukážka použitia, ale keď s jej pomocou upravím svoj skript pre gatsby blog, tak sa dostanem k takémuto kódu:

#!/bin/bash

SESSION_NAME=hrad

source ~/.local/share/tmux-functions/tmux-functions.sh

cd ~/projects/perunhq.org/hrad.perunhq.org

start_session_and_open_windows $SESSION_NAME src gatsby deploy

tmux send-keys -t $SESSION_NAME:src "cd web" Enter "nvim" Enter
tmux send-keys -t $SESSION_NAME:gatsby "cd web" Enter "gatsby develop" Enter
tmux send-keys -t $SESSION_NAME:deploy "cd deploy" Enter

tmux attach -t $SESSION_NAME:src

Jeden skript na naštartovanie aj ukončenie​

Najnovšia iterácia mojich štartovacích skriptov v sebe obsahuje aj variantu pre ukončenie celej session. Stačí, ak skript zavolám s argumentom stop.

# keď idem písat blogpost alebo meniť kód pre môj blog
hrad.sh

# keď som dopísal a chcem všetko zavrieť
hrad.sh stop

Docielil som to veľmi jednoducho. Proste som si prečítal prípadný argument pre skript a cez case v bash-i sa rozhodol, či sa session vytvorí alebo ukončí.

#!/bin/bash

COMMAND=$1
SESSION_NAME=hrad
WINDOW_NAMES=(src gatsby deploy)

source ~/.local/share/tmux-functions/tmux-functions.sh

start_project() {
    cd ~/projects/perunhq.org/hrad.perunhq.org

    start_session_and_open_windows $SESSION_NAME "${WINDOW_NAMES[@]}"

    tmux send-keys -t $SESSION_NAME:src "cd web" Enter "nvim" Enter
    tmux send-keys -t $SESSION_NAME:gatsby "cd web" Enter "gatsby develop" Enter
    tmux send-keys -t $SESSION_NAME:deploy "cd deploy" Enter

    tmux attach -t $SESSION_NAME:src
}

case "$COMMAND" in
    "stop")
        tmux kill-session -t $SESSION_NAME
        ;;

    *)
        start_project
        ;;
esac

A to je všetko. 🎉

🎁 Bonus: Skript pre zložitejší projekt​

Jeden z mojich projektov je webová hra, ktorá má frontend v Reacte, backend v PHP, komunikuje aj cez websockety a na vývoj sa používa docker.

Keď na nej idem pracovať, tak musím najskôr spustiť docker kontajnery pre projekt a následne chcemvšetko toto:

• jeden tab v tmux-e s editorom
• jeden rezervný tab pre rôzne príkazy
• jeden shell do webserver kontajneru na spúšťanie composer install a pod.
• jeden shell do node kontajneru na spustenie dev serveru pre frontend
• jeden shell do webserver kontajneru na spúšťanie testov v PHPUnit-e
• jedno pripojenie do DB
• jedno pripojenie do fixtúrovej DB (to je DB pre autoamtizované testy)
• prihlásiť sa do webserver kontajneru a spustiť websocket server

Všetko mi to zabezpečuje skript nazvaný podľa projektu (wareena.sh), ktorý prijíma aj prípadný argument stop pre ukončenie session. Jeho kód je tu:

#!/bin/bash

SESSION_NAME=wareena

COMMAND=$1

TARGET_DIR="/home/perun/projects/wareena/src/web"
DOCKER_DIR="/home/perun/projects/wareena"

WINDOW_NAMES=(src misc node webserver test db fixture_db ws)

# https://bitbucket.org/perungrad/tmux-functions
source ~/.local/share/tmux-functions/tmux-functions.sh

start_project() {
    if tmux has-session -t=$SESSION_NAME 2>/dev/null; then
        tmux attach -t $SESSION_NAME
        exit;
    fi

    USER_ID=`id -u $USER`
    COLS=`tput cols`
    ROWS=`tput lines`

    WEB_LOGIN_CMD="cd $DOCKER_DIR; docker exec --user $USER_ID -it -e COLUMNS=$COLS -e LINES=$ROWS wareena_php_1 bash"
    DB_LOGIN_CMD="cd $DOCKER_DIR; docker exec -it -e COLUMNS=$COLS -e LINES=$ROWS wareena_db_1 bash"
    FIXTURE_DB_LOGIN_CMD="cd $DOCKER_DIR; docker exec -it -e COLUMNS=$COLS -e LINES=$ROWS wareena_fixture_db_1 bash"

    cd $DOCKER_DIR
    docker-compose up -d

    read -p "Continue with a new tmux session [Y/n]?" yn
    case $yn in
        [Nn]* ) exit;;
        * ) echo "OK";;
    esac

    start_session_and_open_windows $SESSION_NAME "${WINDOW_NAMES[@]}"

    tmux send-keys -t $SESSION_NAME:webserver "$WEB_LOGIN_CMD" Enter
    tmux send-keys -t $SESSION_NAME:node "$WEB_LOGIN_CMD" Enter
    tmux send-keys -t $SESSION_NAME:node "yarn dev" Enter
    tmux send-keys -t $SESSION_NAME:misc "cd $TARGET_DIR" Enter
    tmux send-keys -t $SESSION_NAME:test "$WEB_LOGIN_CMD" Enter
    tmux send-keys -t $SESSION_NAME:test "export SYMFONY_DEPRECATIONS_HELPER=disabled=1" Enter
    tmux send-keys -t $SESSION_NAME:test "bin/phpunit"
    tmux send-keys -t $SESSION_NAME:db "$DB_LOGIN_CMD" Enter
    tmux send-keys -t $SESSION_NAME:db "sleep 5; mysql -u root wareena" Enter
    tmux send-keys -t $SESSION_NAME:fixture_db "$FIXTURE_DB_LOGIN_CMD" Enter
    tmux send-keys -t $SESSION_NAME:fixture_db "sleep 5; mysql -u root wareena" Enter
    tmux send-keys -t $SESSION_NAME:ws "$WEB_LOGIN_CMD" Enter
    tmux send-keys -t $SESSION_NAME:ws "node bin/ws-server.js" Enter

    tmux send-keys -t $SESSION_NAME:src "cd $TARGET_DIR" Enter
    tmux send-keys -t $SESSION_NAME:src "nvim" Enter

    tmux attach -t $SESSION_NAME:src
}

stop_project() {
    cd $DOCKER_DIR
    docker-compose down

    tmux kill-session -t $SESSION_NAME
}

case "$COMMAND" in
    "stop")
        stop_project
        ;;

    *)
        start_project
        ;;
esac

Veľmi skoro som zistil, že v programovaní sa skôr cení prehľadnosť a udržateľnosť kódu. Je veľmi dôležité správne pomenovanie, jednotná a prehľadná formálna úprava kódu. Všetky tieto veci znižujú kognitívny load na náš mozog v čase, keď kód potrebujeme čítať.

V odsadzovaní som preto prešiel na používanie štyroch medzier, ktoré sa nakoniec stali v PHP svete štandardom. Kým sme v PHP viedli sväté vojny za 4 medzery namiesto tabov, tak z môjho pohľadu sa v JavaScripte viedla tichá vojna dvoch proti štyrom medzerám. A k môjmu prekvapeniu sa zdá, že vyhrali dve medzery.

Nerozumiem tomu, lebo mne sa zdá, že dve medzery prinášajú neprehľadnosť a veľmi ťažko sa odhaduje, o koľko úrovní je vlastne riadok odsadený, špeciálne, ak ho porovnávam s nejakým iným. V JavaScripte sa mi to zdá o to dôležitejšie, lebo je to jazyk, kde sa veľmi používajú callbacky a kód sa tak celkom rád ťahá doprava.

Akurát, že zástancovia dvoch medzier používajú presne tento argument na obhájenie svojej pozície. "JavaScriptový kód sa zvykne ťahať doprava, tak potrebujeme dve medzery, aby sme to kompenzovali". 🙃

Ja si naopak myslím, že ak sa mi kód ťahá doprava, tak ho mám asi zle naprogramovaný a príliš veci vnáram. Zrejme niekde porušujem aj Single Responsibility princíp a mal by som ten kód upratať.

Dve medzery mi tak maskujú problémy v kóde. Avšak ja nechcem, aby mi vizuálna úprava zakrývala chyby návrhu. Ja chcem, aby na mňa kód vizuálne kričal: "haló, haló, tu je niečo zle, som veľmi napravo, treba ma prepísať".

Preto ja ostanem pri používaní štyroch medzier aj v JavaScripte a vo svojich projektoch som si upravil aj konfiguráciu pre ESlint a Prettier.

Takto som si to zapísal do .prettierrc

{
    "tabWidth": 4
}

A takto do .eslintrc.js

module.exports = {
    // ...
    rules: {
        indent: ["error", 4],
    },
};

Môj hlavný problém s powerline dizajnom v tmux-e je jeho rozvláčnosť. Ak mám otvorených 8 a viac tabov (ehm... okien), tak ich častokrát nevidím na stavovom riadku všetky.

Tmux, kde sa o dizajn stará Powerline​

Ako vidieť z obrázku, ľavá časť stavového riadku sa celkom naťahuje a je tam veľa prázdneho miesta.

Toto je moja pôvodná konfigurácia, súbor ~/.tmux.conf:

set -g prefix C-a

set -g escape-time 10

set -g default-terminal "tmux-256color"
set -ga terminal-overrides ",*256col*:Tc"

run-shell "powerline-daemon -q"
source "/usr/share/powerline/bindings/tmux/powerline.conf"

Môj vlastný dizajn pre tmux​

V novej konfigurácii som vyhodil Powerline a nakonfiguroval som si dizajn, ktorý nezaberá toľko miesta. Výsledok je vidieť na obrázku.

Keď som už bol pri tom, tak som k svojej konfigurácii rovno vytvoril aj git repozitár a tak si môžete výsledný kód rovno stiahnuť. Repozitár je tu: https://bitbucket.org/perungrad/dotfiles-tmux/

Tu je teda moja nová konfigurácia:

set -g prefix C-a
set -g escape-time 10

# pekné farby pre vim a pod.
set -g default-terminal "tmux-256color"
set -ga terminal-overrides ",*256*:Tc"

# stavový riadok chcem dole
set -g status-position bottom

# C-a C-r reloadne konfiguráciu a aplikuje zmeny pre bežiacu session
bind C-r source-file ~/.tmux.conf

# definície farieb
color_dark="colour232"
color_light="white"
color_status_text="colour245"
color_main="colour10"
color_session_bg="colour229"
color_session_fg="colour16"
color_icon_load="colour190"

# farbičky pre zobrazenie okna, správ a základný štýl pre stavový riadok
set -g mode-style "fg=default,bg=$color_main"
set -g message-style "fg=$color_main,bg=$color_dark"
set -g status-style "fg=$color_status_text,bg=$color_dark"

# max. dĺžka pre pravú časť
set -g status-right-length 100
# ako často obnovovať statový riadok (v sekundách)
set -g status-interval 5

# oddeľovač okien
set -g window-status-separator ""

# pomocné premenné
separator_left="]"
separator_right="["

# vlastné príkazy, ktoré sa použijú ako "widgety" v pravej časti
widget_date="#(date +'%d.%m.%Y')"
widget_time="#(date +'%H:%M')"
widget_load="#(node ~/.config/tmux/widget-load.js)"

# ikonky, potrebuješ Nerd Fonty: https://www.nerdfonts.com/
icon_flame="\uf490"
icon_clock="\uf43a"

# na tabe pre okno je číslo a názov
setw -g window-status-format " #I:#W "
# farby pre tab aktuálneho okna
setw -g window-status-current-style "fg=$color_light,bold,bg=$color_main"
# formát aktuálneho okna
setw -g window-status-current-format "#[fg=$color_dark,bg=$color_main]$separator_right#[fg=$color_dark,bg=$color_main] #I:#W #[fg=$color_dark,bg=$color_main]$separator_left#[default]"

# štýl pre okna, kde je upozornenie na aktivitu
setw -g window-status-activity-style "fg=$color_main"

# ako vyzerá blok s názvom session
set -g status-left "#[bg=$color_session_bg,fg=$color_session_fg,bold] #{session_name} #[default]"

# ako vyzerá pravá časť
set -g status-right " #[fg=$color_icon_load]$icon_flame#[default] $widget_load | $widget_date $icon_clock $widget_time "

Na zobrazovanie aktuálneho vyťaženia systému (aka load) som si napísal vlastný kód v JavaScripte, na ktorý sa odkazuje príkaz pre widget_load.

const { exec } = require("child_process");
const process = require("process");

const colors = [
    "colour10",
    "colour11",
    "colour166",
    "colour168",
    "colour9",
    "colour196",
];

const getColor = (load) => {
    const n = Math.min(Math.floor(load / 2), colors.length - 1);

    return colors[n];
};

exec("cat /proc/loadavg", (error, stdout, stderr) => {
    const result = stdout.match(/^([^\s]+)\ ([^\s]+)\ ([^\s]+)/);

    if (!result) {
        return;
    }

    const load1 = parseFloat(result[1]);
    const load5 = parseFloat(result[2]);
    const load15 = parseFloat(result[3]);

    process.stdout.write(
        `#[fg=${getColor(load1)}]${result[1]}#[default] ` +
            `#[fg=${getColor(load5)}]${result[2]}#[default] ` +
            `#[fg=${getColor(load15)}]${result[3]}#[default]`,
    );
});

Nudné predstavenie​

Tmux je modernejším a myšlienkovým nástupcom programu, ktorý sa volá screen. Oboje sú aplikácie, ktoré umožňujú mať taby (v ich terminológii sú to "okná") v termináloch a okrem toho je možné sa od nich odpojiť, pričom oni a programy v nich spustené bežia ďalej. Keď sa dokážete odpojiť, tak sa viete aj naspäť pripojiť.

Toto je užitočné napríklad aj pre administráciu serveru. Pripojím sa na server, spustím tmux (alebo screen), v ňom naštartujem nejaký dlhotrvajúci skript. Odpojím sa z tmux-u, odpojím sa zo serveru a idem domov. Doma sa opäť pripojím a pozriem, ako môj dlhotrvajúci skript napreduje.

Tmux má oproti screen-u aj panely, čo vlastne znamená, že viete okno rozdeliť na viacero častí a v každej mať samostatný shell.

Killer feature tmux-u je však podľa mňa to, že umožňuje programovo zasielať príkazy a simulovať písanie do hociktorej svojej session a hociktorého okna 🤯.

K čomu je to dobré?​

Ja mám tmux rád, pretože jeho taby sú nezávislé na termináli a zaberajú menej miesta na výšku. Ale najmä tmux používam na rýchle naštartovanie projektov a setup pracovných nástrojov.

Keď chcem ísť programovať Wareenu, čo je jeden z mojich projektov s PHP backendom a React-om na frontende, tak potrebujem urobiť kopec vecí na to, aby som mohol pohodlne vyvíjať a všetko mal na dosah ruky. Konkrétne:

• spustiť docker kontajnery
• prihlásiť sa do kontajneru s PHP, aby som mohol spúšťať napr. composer
• prihlásiť sa do kontajneru s node, aby som tam hneď spustil HMR
• prihlásiť sa do kontajneru s PHP a pripraviť si tam príkaz na spustenie PHPUnit-u
• prihlásiť sa do kontajneru s databázou a otvoriť pripojenie
• prihlásiť sa do kontajneru s fixtúrovou databázou a otvoriť pripojenie
• prihlásiť sa do kontajneru s node a spustiť websocket server
• nastaviť sa do adresáru s projektom, aby som odtiaľ ľahko spúšťal príkazy (napr. git)
• nastaviť sa do adresáru s projektom, aby som odtiaľ spustil editor

Keby som nemal tmux, tak by som pri týchto požiadavkách skončil s tým, že sa mi otvorí 8 samostatných terminálových okien. Trochu lepšia situácia by bola v prípade, keby som používal terminál umožňujúci programovo otvárať nové taby a spustiť v nich príkaz, ale taký nepoznám.

S pomocou tmux-u si však viem k tomuto napísať skript a potom to spúšťať jediným príkazom (alebo aj klávesovou skratkou).

Základy práce v tmux-e​

Inštalácia​

Tmux sa na Linuxe inštaluje klasicky cez balíčkovací manažér (napr. apt install tmux), na Mac-u cez Homebrew (brew install tmux) alebo MacPorts (port install tmux). Na Windowse ho nepotrebujeme, lebo Windows je predsa pre programátora hernou konzolou a nie pracovným nástrojom 😃. (Ak ale máte na Windowse WSL, tak inštalujte cez balíčkovací systém distribúcie.)

Spustenie a okná​

Tmux spustíme v konzole príkazom tmux. (Kto by to bol povedal.)

tmux

Týmto príkazom sa spustí nová tmux session. Session môžete mať viac a každá je samostatná so svojimi oknami. Ak však chceme, tak sa vieme z jednej session pozrieť do druhej.

Pre konfigurovanie je dôležité vedieť, že prvá session na pozadí spustí aj tmux server, s ktorým komunikujú všetky session a ktorý zaniká s poslednou ukončenou. Tento server si drží konfiguráciu. Ak sa teda budeme hrať s konfiguračným súborom pre tmux, tak zmeny sa nám neprejavia, kým bude bežať aspoň jedna session. Musíme ich najskôr všetky vypnúť a naštartovať tmux odznova.

V spustenom tmux-e máme rovno otvorené prvé okno (má číslo 0). Ak chceme otvoriť ďalšie, tak sa to robí klávesovou skratkou CTRL+B C, čo znamená, že najskôr stlačíme CTRL+B, potom uvoľníme oba klávesy a stlačíme C.

Všetky klávesové skratky v tmux-e začínajú prefixom, ktorý je defaultne nastavený na CTRL+B. Je však možné ho zmeniť buď pre aktuálnu session alebo rovno v konfiguračnom súbore na stálo. Ja osobne som si prefix zmenil na CTRL+A, pretože tak to bolo v screen-e a zvykol som si a zároveň mi to je príjemnejšie.

Ďalej budem namiesto CTRL-B alebo CTRL-A uvádzať {prefix} a vy tam budete stláčať to, čo ste si nakonfigurovali.

Medzi oknami sa prepíname skratkou {prefix} číslo-okna. Ak je okien viac, ako desať, tak ich zoznam si zobrazíme skratkou {prefix} W

Zoznam základných skratiek, vyskúšajte si:

Príkazy​

Tmux má hrozne veľa príkazov. Viete ich zadávať ako parametre príkazu tmux alebo priamo v bežiacom tmux-e do príkazového riadku zobrazenom po stlačení {prefix} :. A tie isté príkazy zapisujete aj do konfiguračného súboru (defaultne ~/.tmux.conf).

Ak je možné príkaz jednoznačne identifikovať aj z časti jeho názvu, tak ho nemusíme písat celý. Napríklad nemusíme písať list-sessions a úplne postačí list-s.

Zoznam niektorých užitočných príkazov:

Príkazy môžu mať vlastné prepínače (klasicky unixovské písmenkové flagy začínajúce pomlčkou). Pre detaily je dobré si pozrieť dokumentáciu (príkaz man tmux v konzole).

Moja konfigurácia​

Tmux sa konfiguruje v súbore ~/.tmux.conf.

U mňa tmux vyzerá takto:

Spodný riadok je "tabbar". Úplne naľavo je názov session, potom nasleduje zoznam okien, uptime, systémový load, dátum a čas a názov počítača.

Dosiahol som to touto konfiguráciou:

# prefix bude CTRL+A
set -g prefix C-a

# Chvíľku čakáme na escape sekvencie.
# Vysvetlenie viď https://unix.stackexchange.com/questions/608142/whats-the-effect-of-escape-time-in-tmux
set -g escape-time 10

# Chceme pekné farby
set -g default-terminal "tmux-256color"
set -ga terminal-overrides ",*256col*:Tc"

# O vizuál tmux-u sa mi stará powerline
run-shell "powerline-daemon -q"
source "/usr/share/powerline/bindings/tmux/powerline.conf"

Ak sa vám nepáči defaultný vzhľad tmux-u, tak existuje veľa možností na to, aby ste si to nastavili podľa svojho gusta (pozrite man tmux). Ak to chcete mať rovnaké ako ja, tak si potrebujete nainštalovať powerline a k tomu ešte fonty (na Ubuntu apt install powerline fonts-powerline).

Zázračný skript pre spustenie projektu​

Spomínal som, že mám vytvorené skripty pre jednoduché spúšťanie projektov. Jeden taký mám pre projekt Wareenu a po spustení skriptu sa mi naštartujú docker kontajnery, rovno ma do niektorých prihlási a všetko je pripravené tak, aby som len otvoril neovim a mohol programovať.

Takto to vyzerá po spustení skriptu:

Do konzoly iba napíšem start-wareena.sh, pár sekúnd počkám (lebo docker kontajnery chvíľku štartujú) a môžem pracovať.

Skript samotný vyzerá takto, kľudne sa inšpirujte a upravte pre svoje potreby. Nezabudnite mu dať práva na spúšťanie.

#!/bin/bash

# názov tmux-ovej session
SESSION_NAME=wareena

# ak už session s týmto názvom existuje, tak sa do nej len pripojíme
if tmux has-session -t=$SESSION_NAME 2>/dev/null; then
    tmux attach -t $SESSION_NAME
    exit;
fi

# adresár, kde sú zdrojáky projektu
TARGET_DIR="/home/perun/projects/wareena/src/web"
# adresár, kde je umiestnený docker-compose.yml k projektu
DOCKER_DIR="/home/perun/projects/wareena"

# id aktuálneho používateľa (aby som sa do docker neprihlásil ako root)
USER_ID=`id -u $USER`

# aktuálny počet riadkov a stĺpcov v termináli (docker občas hnevá a nevie to správne detekovať)
LINES=`tput lines`
COLUMNS=`tput cols`

# Príkaz na prihlásenie sa do web kontajneru.
# V tomto projekte mám ten istý kontajner pre PHP aj pre node
WEB_LOGIN_CMD="cd $DOCKER_DIR; docker exec --user $USER_ID -it -e COLUMNS=$COLUMNS -e LINES=$LINES wareena_php_1 bash"

# Príkaz pre prihlásenie do databázového kontajneru
DB_LOGIN_CMD="cd $DOCKER_DIR; docker exec -it -e COLUMNS=$COLUMNS -e LINES=$LINES wareena_db_1 bash"

# Príkaz pre prihlásenie do kontajneru s fixtúrovou databázou
FIXTURE_DB_LOGIN_CMD="cd $DOCKER_DIR; docker exec -it -e COLUMNS=$COLUMNS -e LINES=$LINES wareena_fixture_db_1 bash"

# Naštartovanie kontajnerov
cd $DOCKER_DIR
docker-compose up -d

# Občas nejaký kontajner nenaštartuje, vtedy nechcem pokračovať
read -p "Continue with a new tmux session [Y/n]?" yn
case $yn in
    [Nn]* ) exit;;
    * ) echo "OK";;
esac

# Vytvorím novú tmux session:
# - nechcem sa do nej hneď pripnúť (-d parameter), inak by sa zvyšné príkazy spustili az po jej ukončení :)
# - so zvoleným názov (-s parameter)
# - vytvorím aj nový tab/okno a rovno ho pomenujem (-n parameter)
tmux new-session -d -s $SESSION_NAME -n webserver

# Povytváram zvyšné taby
tmux new-window -n node
tmux new-window -n src
tmux new-window -n misc
tmux new-window -n test
tmux new-window -n db
tmux new-window -n fixture_db
tmux new-window -n ws

# V tabe webserver sa prihlásim do web kontajneru.
# Parameter -t určuje cieľovú session a okno
tmux send-keys -t $SESSION_NAME:webserver "$WEB_LOGIN_CMD" Enter

# V tabe pre node sa prihlásim do kontajneru a spustím HMR
tmux send-keys -t $SESSION_NAME:node "$WEB_LOGIN_CMD" Enter
tmux send-keys -t $SESSION_NAME:node "yarn dev" Enter

# V tomto tabe spúšťam neovim, len sa prepnem do adresáru so zdrojákmi
tmux send-keys -t $SESSION_NAME:src "cd $TARGET_DIR" Enter

# Tu spúšťam kadejaké príkazy (napr. git), len sa prepnem do adresáru so zdrojákmi
tmux send-keys -t $SESSION_NAME:misc "cd $TARGET_DIR" Enter

# Pripravím si tab pre spúšťanie testov pre PHPUnit
tmux send-keys -t $SESSION_NAME:test "$WEB_LOGIN_CMD" Enter
tmux send-keys -t $SESSION_NAME:test "export SYMFONY_DEPRECATIONS_HELPER=disabled=1" Enter
tmux send-keys -t $SESSION_NAME:test "bin/phpunit"

# Prihlásim sa do databázy
tmux send-keys -t $SESSION_NAME:db "$DB_LOGIN_CMD" Enter
tmux send-keys -t $SESSION_NAME:db "sleep 5; mysql -u root wareena" Enter

# Prihlásim sa do fixtúrovej databázy
tmux send-keys -t $SESSION_NAME:fixture_db "$FIXTURE_DB_LOGIN_CMD" Enter
tmux send-keys -t $SESSION_NAME:fixture_db "sleep 5; mysql -u root wareena" Enter

# V poslednom tabe spustím websocket server
tmux send-keys -t $SESSION_NAME:ws "$WEB_LOGIN_CMD" Enter
tmux send-keys -t $SESSION_NAME:ws "node bin/ws-server.js" Enter

# Pripojím sa do vytvorenej session a do tabu, kde chcem spustiť neovim
tmux attach -t $SESSION_NAME:src