CategoryJavaScript

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?

Geolokalizace IP adresy

Z důvodů pořešení nějakých bezpečnostních praktik jsem potřeboval nějak blíže geolokalizovat IP přihlašovaného uživatele, respektive záškodníka, abych věděl odkud se fyzicky přihlašuje:

NodeJS: geolokalizace IP adresy

Python: geolokalizace IP adresy

Jaký je rozdíl mezi Javou a JavaScriptem?

Q: What’s the difference between JavaScript and Java?

A: One is essentially a toy, designed for writing small piecess of code, and traditionally used and abused by inexperienced programmers. The other is scripting language for browser.

🙂

Výpočet GEO vzdálenosti v JavaScriptu

Výpočet dle Haversine formula

ESLint

Dnes jsem přešel z JSHintu na ESLint. Tím asi nejpádnějším důvodem je podpora Reactu, respektive jeho JSX a lepší monžnosti konfigurovatelnosti. Musím ale dodat, že jsem se bránil do poslední chvíle. Důvodem byla třeba rychlost lintování: JSHint mi zdrojáky lintoval rychleji… A tohle je informace, kterou se nikde nedočtete.

Než jsem switchnul, pročetl jsem kde co, abych zjistil, že:

  • JSHint je fork původního JSLintu
  • ESLint je dnes už asi více používaný než JSHint, který je tady nicméně déle
  • velké a významné IT používají ESLint…

ESLint, stejně jako JSHint, fungují dobře jak v Atomu, tak i Sublime, což jsou dnes už jediné editory, které dnes používám (když nepočítám Vim…).

Co se mi asi na ESLintu o trochu víc líbí je jeho konfigurace. Konfigurační soubor můžete mít jak v JSON souboru, tak v JS, ale i v Yamlu. V rámci projektu můžete mít v root adresáři výchozí konfiguraci pro ESLint a v dalších jeho podadresářích můžete mít specifické, upravené konfiguráky dle konkrétní potřeby. Vedle toho můžete použít něčí best-practice vzorový konfigurák, ten použít jako základ a upravit jen to chcete jinak…

V ESLintu samozřejmě funkují inlajnované directivy pro linter vkládané přímo do souborů se zdrojáky, stejně jako v JSHintu.

Instalace

Lodash

Ať už píšete svoji aplikaci v jakémkoliv jazyce, určitě používáte nějaké ty knihovny pro takové ty základní funkcionality, jako je hledání v poli, porovnávání objektů a podobně.

Pokud píšete v JavaScriptu, pak se vám určitě bude líbit Lodash. Najdete v něm téměř všechny základní funkcionality ať už pro práci s čísli, poli, řetězci a podobně. Krom samotného rozsahu jeho nespornou výhodou je výborná dokumentace.

PhantomJS: web screen capture

phantomjs2

Už jste někdy potřebovali automaticky a sbírat náhledy webových stránek z prohlížeče (screenshoty)? Pak asi nejjednodušším řešením je použití PhantomJS, který, jak o sobě uvádí, je full web stack, no browser required řešením:

Výsledkem scriptu je sada PNG obrázků se screenshoty požadovaných webových stránek. Jedná se o rychlý návod jak na to. Samotný script by se dal ještě dopracovat…
PhantomJS se dá použí ke spoustě dalších věcí. Já jej používám např. i pro vytváření PDF dokumentů na webovém serveru.

JavaScript and Node FUNdamentals

5178Ep21UkL._SX384_BO1,204,203,200_

Javascript And Node Fundametals

© 2018 pepa.holla.cz

Theme by Anders NorénUp ↑