AuthorPepa

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: JWT autorizace

JWT je docela jednoduchá metoda použitelné k autorizaci. Princip fungování asi nejlépe popíše samotný obrázek s diagramem:

Součástí vráceného tokenu mohou být jakákoliv data získaná při autorizaci na serveru, protože jsou vráceny zakódovaná. Data si takto můžete předávat v aplikaci dál. Každá zabezpečená routa může dostat do svého requestu dekódovaná data a dál s nimi pracovat

Opravdu jednoduchá implementace

Samotnou práci s JWT zajišťuje NPM balíček jsonwebtoken. Nejdůležitější je asi samotná funkce verifyToken jako Expressjs midleware funkce, ktará zajišťuje JWT autorizaci. Vše ostatni je jen obsluha jednotlivých rout…

POST /login – získání tokenu, kde v body je email a password
POST /data – zabezpečené načítání dat, kde v requestu musí být ‚token‘ získaný z /login a pak v odpovědi jsou požadovaná data.

Routa /data samozřejmě může fungovat i na metodě GET, ale pak by bylo potřeba přepsat autorizačni funkci midlewaru tak, aby token hledala například v hlavičce requestu. Nic složitého…

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

PHP v 2018

OK, taky jsem kdysi psal v PHP, jako snad každý, kdo dělal něco na Internetu… Nicméně k mému dobru, nikdy jsem neměl ambice psát nad PHP vlastní templejtovací systém (templejty v templejtách…), nebo ještě dál, celý framework… 🙂

Narazil jsem dnes na tohle video, kde autor PHP, Rasmus Lerdorf, popisuje aktuální stav PHP, tedy retrospektivně porovnává některé věci v PHP z minulosti s tím co je v PHP 7…

Jednou z věcí, kterou řekne někde skoro na začátku videa je, že PHP podle něj mělo být uplně něco jiného, než se z PHP dnes stalo…. Co k tomu dodat….

Myslím si, že Rasmus musí být strašně nasranej, když dnes vidí NodeJS, Rust, Go, WebAssembly a všechno kolem a on už kdysi tam někam mířil…

JavaScript: callback, promises, async/await, naposledy…

Mám pocit, že čím dál víc javascriptových vývojářů používá nové jazykové kostrukce pro práci s asynchronním kódem, ale ne všichni mu rozumí jak by měli a jen slepě používají něco co viděli někde jinde. Proto naposledy tohle velice stručné, ale podle mě snad všeříkající shrnutí všech možných současných variant pro psaní asynchronních operací:

Dodám, že v TypeScriptu se píše asynchronní kód úplně stejně.

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

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.

© 2018 pepa.holla.cz

Theme by Anders NorénUp ↑