Buffer flush 01/2014

Člověku se čas od času nashromáždí spousta odkazů, které je dobré vypustit, utřídit, předat lidu… Tady máte lednovou várku.

Axel Rauschmayer popisuje skvěle jak paralelismus v JavaScriptu, tak dvě nové metody pro práci s polem v ES6 – .find a .findIndex.

Už dlouho si slibuju, že se podívám na Web Components. Pokud jste na tom jako já, třeba vás zaujme Addy Osmani a jeho Yo Polymer.

Jestli chcete ES6 už dnes, máte možnost použít ES6 shim.

No a asi největší téma, co jsem v lednu řešil, byly moduly. Pokud nevíte, která bije, tak: Moduly v JavaScriptu slouží k témuž účelu jako v jiných jazycích, totiž k rozdělení návrhu do logických celků. A stejně jako není Jediný Univerzální Způsob, Jak Simulovat Třídy (i když Dan Steigerwald ví, že jediný možný způsob je ten jeho), tak není ani jediný univerzální způsob psaní modulů.

Jedna možnost je moduly neřešit, dělit zdrojový kód na soubory a zavírat je do jmenných prostorů. Což je dneska pravděpodobně mainstream.

Druhá možnost je použít definici modulů podle CommonJS – to je ten přístup, kdy je modul samostatný soubor, exportuje své metody pomocí exports a k modulům se přistupuje přes require(). Tento způsob se prosazuje víc na serverové straně, i díky tomu, že je hodně synchronní. Tento způsob je nativní pro Node.js

Třetí možnost je použít AMD – Asynchronous Module Definition. Moduly se definují funkcí define() a přistupuje se k nim v callbacku funkce require(). Asynchronní moduly se používají často na klientské straně a k jejich načítání slouží nějaký vhodný správce. Asi nejznámější je RequireJS, vylepšený a rychlejší je třeba Walshův CurlJS.

Co s tím? Každý způsob má svá pro a proti. Shrnuje je opět Addy Osmani: Writing modular JS. Naštěstí existují způsoby, jak jedním způsobem načíst modul pro ten druhý způsob – například jak asynchronně načíst CommonJS modul. Navíc existují správci, kteří dokáží zpracovat různé formáty a konvertovat je mezi sebou. Například uRequire.

Z druhé strany je zase možné psát moduly tak, aby splnily požadavky pro všechny tři způsoby. Nejflexibilněji k tomu přistupuje UMD (Universal Module Definition). Já používám jednodušší způsob:

Jo a až budete hledat JavaScriptovou knihovnu, která umí parsovat Markdown, zkuste Tinydown.

Líbil se vám článek? Podpořte autora na Patreonu

8 Comments

Got Something To Say:

Vaše emailová adresa nebude zveřejněna.

Já to zatím nikde moc neventiloval, ale posledních pár let už JS aplikace vlastně ani nepíšu jinak než právě. Oblíbil jsem si RequireJS, vymyslel si vlastní konstrukt, co mi nejvíc sedí, a můj typický modul teď vypadá nějak takhle:

http://pastebin.com/Nh431VzF

Navíc poslední rok všechny nové projekty už rovnou začínám v CoffeeScriptu, což je pro mě ještě čistší a přehlednější:

http://pastebin.com/f08pQ0Sf

Ak ste niekto skúšali Browserify (http://browserify.org/), tak by ma celkom zaujímal váš názor. Dík.

Kloním se k táboru odpůrců AMD/UMD, ten kód je prostě hroznej.
Používám už dlouho vlastní DI kontejner, který pracuje synchronně
(načítá třídy, funkce nebo objekty z globálního (či jiného) namespace v
browseru, popř. přes require v node). Zrovna nedávno jsem jej přepisoval
tak, aby fungoval asynchronně s libovolným module loaderem, ale přináší
to problémy. Např. pokud nemáme pod kontrolou, kdy přesně se něco začne
načítat, komplikuje to životní cyklus objektů.

Browserify je
fajn věc, ale závislosti vyhodnocuje logicky během kompilace. Oproti
tomu já potřebuji závislosti vyhodnocovat až během runtime, takže to
skřípe. Ideální řešení zatím neexistuje.

Adente, nezapomeň, že jde o 4 roky starý článek 🙂 Nicméně ten stejný způsob znamená neobcházet/nehackovat prototype. Na tom se nezměnilo nic. Máme jinou a lepší syntax, ale pořád jde o prototype.

banner

Copyright © 2017. Powered by WordPress & Romangie Theme.

banner