CategoryProgramování

Kvalita dokumentace…

Nádherná ukázka toho, jak i rádoby dokumentace může být špatná…

Screenshot jsem pořídil ze stránek w3schools.com 🙂 Vím, že tohle není oficiální dokumentace, ale znám spoustu lidí, co odtud čerpají a berou informace odsud za ty jedině správné…

23 javascriptových návrhových vzorů

Proč návrhové vzory?

Abyste nemuseli vynalézat kolo.
Aby to co napíšte mělo hlavu a patu a rozuměli tomu i ostatní.

Pěkný článek popisující javascriptové návrhové vzory. Jednoduše a pochopitelně.

this v arrow functions

Tohle jsem viděl nesčetněkrát. Tohle vám skutečně fungovat nebude 🙂

Arrow functions jsou super, ale je dobré vědět jak fungují… Respektive vědět minimálné to, že nemají this, mino jiné, a proto se neprovede this.num++ nad num definovaném v objektu a, jak by se na první pohled mohlo zdát. this ukazuje na parent, tedy v tomto případě global, kde žádný num není 🙂

Správně tedy

Pěkný článek popisující detailně chování this kdekoliv v JS.

ES moduly v NodeJS

Modularita, co by nezbytná vlastnost jakéhokoliv programovacího jazyka pro psaní velkých aplikací, je v NodeJS zajištěna pomocí funkce require. Samotnou fyzcickou definici a implementaci pak zajišťuje CommonJS.

Takže takto v NodeJS

JavaScript a import

JavaScript, skrze svou specifikaci ECMAScript 2015 zavádí, mimo jiné, i nové klíčové slova import a export pro možnost modularizovat javasxriptový kód.
To dovoluje následující zápis kódu:

Tohle vám bude například fungovat, pokud píšete React, VueJS, nebo Typescript aplikaci, protože ta je teprve skrze nějaký transpiler kompilována do požadované verze JavaScriptu.

Nicméně v NodeJS import nefunguje… Zatím 🙂

node –experimental-modules

A tady přichází na scénu parametr příkazového řádku --experimental-modules, který vám umožní v NodeJS používat klíčové slovo import místo require. Přesně tak, jak byste jej použili v Reactí apce…
Opravdu píšu místo, protože obě možnosti zatím nejdou kombinovat.
Takže pokud spustíte NodeJS script s tímto parametrem, můžete použít novou syntaxi pro importování, ale samozřejmě i exportování na úrovni modulu:

Dalším rozdílem je samotná přípona souboru se zdrojákem. Původní require funguje v klasických .js souborech, nově import pak v souborech s příponou .mjs.
Samozřejmě můžete import přímo psát do.js souboru a spouštět pokaždé s potřebným parametren, ale je to proti zavedené konvenci a navíc, nejde na první pohlef vidět jaký způsob práce s moduly jste použili.

Moje doporučení?

Pište v TypeScriptu 🙂 budete moct v .ts souborech použít obě konstrukce pro import, ale vedle toho mnohem víc věcí, které JavaScript dělají skutečně silným programovacím jazykem.

NPM: link

Pedpokládám, že každý kdo něco píše v JavaScriptu, nebo TypeScriptu zná NPM.
Pro ty co jsou tu prvně: největší a nejrychleji rostoucí repozitář (knihovna) javascriptových modulů. Samozřejmě se vším co k tomu patří.

Vedle toho, že NPM je nějaký síťový, skrze internet dostupný, centrálně spravovaný, byste třeba někdy chtěli dosáhnout stejného chování balíčků pomocí require pro nějaké vlastní, lokálně vyvíjené moduly, které neopustily disk vašeho notebooku.

NPM lokálně

Příklad

Mám někde na disku adresář, ve kterém mám vlastní implementaci super výkoné matematické knihovny:

zdrojový kód mé knihovny:

package.json v adresáři s knihovnou:

Tak a tenhle modul bych chtěl pak používat v dalších svých projektech stejně jako jakýkoliv jiný modul, který pochází z NPM.

Jak na to?

1. zaregistrování modulu

V adresáři s balíčkem ./my-math-lib spustím následující:

Tím dojde k vytvoření sym linku do globálního prostoru NPM balíčků na vašem stroji. O tom, že balíček se zaregistroval se přesvědčíte následovně:

2. samotné využití požadovaného balíčku

Pak už jen stačí v adresáři s projektem, kde chcete váš balíček používat spustit následující:

V podstatě náhrada za

Protože příkaz install by hledal a stahoval balíček z centrálního, síťového repozitáře a to nechceme.

Pak už můžeme v projekt klasicky použit require jak jsme zvyklý:

Resume

Celý fígl je v tom, že příkaz npm link vytváří symlinky mezi globálnín NPM uložištem na vašem stroji a adresářem node_modules v daném projektu.
Super je, že zůstává plně zachována plná funkcionalita práce s baličky, takže funguje i toto:

Tím dojde k odebrání balíčku z daného projketu, nicméně sdílený balíček půjde dál využívat v ostatních projektech.
Pokud budete chtít úplně zrušit sdílení lokálního balíčku, pak následovně:

Elegantní a hezhé řešení…

NodeJS: MongoDB callback VS async/await

Odjakživa co píšu v NodeJS se držím callbackového zápisu asynchronních funkcí. Callback-hellu se snažím vyhnout rozumnou dekompozicí řešené úlohy a Promises zápis mě nikdy nedostal… Nicméně s jazykovou konstrukcí async/await, která se do JavaScriptu dostala ve verzi ES2017, se dá leckdy kód napsat čitelněji, pochopitelněji a tím pádem snad i bezpečněji.

Takhle by tedy mohl vypadat kód pro čtení dat z MongoDB:

Původní callback implementace

Nová async/await implementace

Resumé

Na první pohled jde vidět několik věcí: ošetření všech chyb se přesouvá jen do jednoho místa a tím odpadá mnoho opakujícího se kódu, výsledek, načtená data nejsou nikde hluboce zanořená a nemusíte řešit problém s kaskádou otevřených závorek if-else větví.
Nutno podotknout, že výhoda nového zápisu ještě více vzroste v momentě, kdy máte sérii callback dotazů a obslužný kód vám začne ještě více narůstat.

Vedle toho si samozřejmě dokáži představit kód, kde bych se dál držel callback zápisu, ale to je věc konkrétního použití.

Návod, jak se stát frontendovým vývojářem :)

VueJS VS React VS Angular

Existuje spousta porovnání těchto frameworku, nicméně tahle tabulka je výstižná a hlavně hodně přehledná. Byť verze Angularu není aktuální, nicméně jeho paramtery srovnávané v tabluce se až tak moc nezměnily.

TypeScript: Jest a testování asynchronních funkcí

V tomto případě asynchronních funkcí implmementujících svůj návrat skrze callback funkci.

Tohle by mohla být nějaká asynchronní funkce pro výpočet součtu:

V kódu nic nehledejte. Je to opravdu jen princip: funkce s několika parametry, kde posledním je callback funkce, která se provede po získání výsledku. V mém případě ihned, nicméně princip je jasný…

Jest test

A tohle je na Jestu pěkné. Chová se přesně tak, jak byste čekali. Prostě zavoláte svou asynchronní funkci a v jejím callbacku provedete patřičný test. Hotovo.

Připojím snad jen kompaktnější zápis testovací funkce využívající arrow function.

TypeScript: unit testy s Jest

Jest je, jak píše Facebook co by jeho tvůrce, skvělý JavaScriptový testovací framework. Jedná se o přímou náhradu, či konkurenci jinému, v současné době asi rozšířenějšímu, testovacímu frameworku, kterým je Mocha.

Proč Jest?

  • méně nutné konfigurace pro okamžité použití
  • velice jednoduché vše rozjet a okamžitě začít pokrývat zdroják testmi
  • na rozdíl od Mocha obsahuje i assert knihovnu (Chai) a mock knihovnu (SinonJS)
  • performance

Nicméně žádný z těchto důvodů nebrání použítí Mocha frameworku pro váš kokrétní projekt, či tým.

Jak na to?

Instalace

Předpokádám, že už máte nějaký NodeJS projekt a v něm package.json. Pak stačí jen doinstalovat pár balíčků nasledujícím způsobem:

Hotovo 🙂

Konfigurace

Do pakcage.json vložit konfiguraci pro Jest a následně upravit sekci script:test pro spuštění testů:

Samotná konfigurace Jestu může být alternativně uložena mimo package.json přímo do jest.config.js:

Vytvořte adresář __tests__ v root adresáři vašeho projektu. Adresář s testy se může samozřejmě pojmenovat jakkoliv jinak, stačí korektně přenastavit v konfiguraci.

Hotovo 🙂

Kódování, develop, vývoj…

Založte si src adresář a v něm vytvořte svůj nějaký soubor, který bude obsahovat váš TypeScript kód. Řekněme sum.ts, pro nějaké matematické funkce…

Hotovo. Máme knihovnu, která v tuto chvíli exportuje jednu jedinou funkcionalitu pro sčítání 2 čísel.

Konečně testování

V dříve založeném adresáři __tests__ vytvořte stejně jmenující se typescriptový soubor který bude obsahovat samotné testy, tentokrát s příponou .test.ts:

Hotovo 🙂 Můžeme testovat:

Výstupem je krom informace s výsledky testů i informace o tom, jak máte svůj zdroják testy pokrytý:

TDD

V rámci TDD si pak dokážu představit, že pro každou nově vyvíjenou funkcionalitu si nejdřív napíšete její testovací sekci, ve které pokryjete všechny scénáře, kterou mahou nastat a pak teprve začnete vyvíjet a píšete tak dlouho, dokud všechny zadefinované testy nejsou zelené 🙂

Zdroje

Jest homepage, dokumentace, blog

© 2018 pepa.holla.cz

Theme by Anders NorénUp ↑