CategoryJavaScript

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.

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í.

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

NodeJS: new Buffer

Už delší dobu se vedou diskuze kolem konstruktoru new Buffer, které, jak to vypadá, skončí uvolněním NodeJs ve verzi 10, kde tato konstrukce bude označena za deprecated. Pokud tedy někde ve svých projektech Buffer používáte, měli byste začít refaktorovat svůj kód a nahrazovat volání konstruktoru za jeho alternativní metody:

Pokud ve svých projektech používáte ESLint, tak stačí, když upravíte jeho konfiguraci a on vám olintuje a vyhodí všechny výskyty deprecated volání konstruktoru a můžete docela jednoduše a rychle refaktorovat.

TypeScript: dynamická modifikace objektu

Pokud přicházíte z JavaScriptu, určitě budete znát tento způsob práce s typem Object:

Kód je jednoduchý a zcela jasný:
– deklarujete a zároveň definujete proměnnou osoba jako objekt s jediným klíčem jmeno.
– potom k vytvořenému objektu přidáváte další klíč povolani
– a nakonec celý objket vytisknete na standartní výstup, do konzole.

V JavaScriptu OK.

Tohle vám ale v TypeScriptu neprojde


Důvod je jasný: TypeScript je nadmnožina JavaScriptu, která do něj zavádí statické typování. Z příkladu vyplývá, že objekt jste deklarovali joko objekt s jediným klíčem, a proto jej dál úž nikde nemůžete modifikovat, co se klíčů týče. Nově vzniklý objekt už je typově jiný.

Ale i s tímto si TypeScript docela elegantně vypořádá. V deklaraci proměnné stačí místo konkrétního jednoho klíče deklarovat obecné pole s typem string, který může nabývat jakékoliv hodnoty a máte po problému:

V TypeScriptu OK 🙂

Celý fígl je v jediném řádku

Kterým říkáte: hele Object nebude obsahovat jeden, přesně pojmenovaný klíč, ale bude obsahovat celé pole hodnot klíčů stringů, které budou odkazy na proměnné, samotné klíče, jakéhokoliv typu (any)

Praktické využití?

To se samo nabízí: pokud se snažíte složitější datové struktůry udržet na uzdě pomocí interface, pak statický typovost vám nedovolí uhnout. Někdy dobré, ale někdy ne. Může se hodit mít definovaný intarface jako nějaké datové minimum, který konkrétní objekt má splňovat, ale krom povinných klíčů byste chtěli čas od času někde něco k něčemu přidat. Pak se vám tento fígl bude hodit.

Je jasné, že

můžete pouřít přímo v deklaraci samotného interface.

JavaScript: promises a async/await

Jsem si vědom toho, že o promises toho bylo napsáno dost. Určitě už ale o něco méně o async/await. Nicméně z diskuzí s javascriptovými vývojáři, kterých se v poslední době účastním, mám pocit, že většina z nich vidí async a promise jako zcela odlišné techniky, které krom toho, že řeší stejný problém, chápou jako zcela odlišné věci.

Promises


Určitě ne ideální, ale plně funkčnní javascriptový kód, který pomocí promises řeší asynchronní operace, byť se v příkladu jedná o obyčejné matemtické operace. Důkaz že asynchronně se dá psát i non-blocked kód 🙂

Async/Await


Přepsal jsem výše uvedený kód z promises do async/await.

Vlastně nepřepsal 🙂 Použil jsem všechny jednotlivé funkcionality tak jak jsou s primises a jen jsem nahradil chain volání v promisách implementovaný skrze then do jedné jediné funkce, uvozené klíčovým slovem async. Samotné volání může vypadat složitě, ale to jen kvůli IIEF, které jsem v příkladu použil.

Suma sumárum

Async/await přímo staví na promises. Je vnitřně naiplementovaný skrze promises. Jen zavádí novou konstrukci zápisu, která může být programátorům přicházejících ze světa blokujících operací na první pohled bližší, než více méně funkcionální zápis v zřetězeném chainu pomocí holých promisí.

Osobně se dál držím callbacků, ale pokud bych musel šáhnout po něčem z výše popsaném, vyberu si async/await konstrukci.


PS: calback hell není vlastnost jazyka, je to jen špatně navržená kompozice jednotlivých funkcionalit 🙂

For loop v TS, JS (performance)

V ES6 je nově for of loop, který iteruje nad čímkoliv, co umí iterovat, jako je např. pole a objekt.
A to mě vedlo ke krátkému a opravdu jednoduchému testu, ve kterém jsem si ověřil výkonost jedotlivých for loop konstrukcí.

Výsledky

Env NodeJS Safari Chrome Firefox
Create time 497 209 507 2793
For in 1421 7606 1534 6575
For of 11 36 31 10643
For 11 46 34 8724

Všechny časy jsou v ms.

Několik rychlých závěrů

  • Firefox už dlouho nepoužívám a do testu jsem jej vložil jen pro úplnost. Pozitivní zjištění: o nic jsem nepřišel…
  • Je super, jak je NodeJS opravdu dobře zoptimalizovaný a na prováděný kód téměř nemá žádný vliv prostředí.
  • Chrome: V8 společná s NodeJS je znát. Výkonový rozdíl vyplývá z prostředí ve kterém kód běží a dá se pochopit.
  • Safari má vlastní JS engine SquirrelFish, který je opravdu dobrý…

Poznámka na závěr

Ze zvědavosti jsem chtěl takto otestovat i PHP.

Při pokusu vytvořit pole s 10.000.000 čísly (tak jak jsem to dělal v JS) jsem se dočkal chybové hlášky Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 134217736 bytes) in /Users/pepa/test/looptest/test.php on line 7 a tím jsem testování v PHP odpískal.

Pravdou je, že jsem ještě zkusil zmenšít velikost vytvářeného pole na 10.000, tedy tisíckrát meněí. Jo! Pole se vytvořit podařilo. Pak jsem se zarazil. Tohle chceš vážně testovat?

© 2018 pepa.holla.cz

Theme by Anders NorénUp ↑