Tento blogový příspěvek je výsledkem iniciativy „Call for Blog Posts“ od týmu Ember.js za vytvoření plánu pro rok 2019.
Také doufám, že můj první pokus o psaní článku bez emotikonů! :fingers-crossed:(To by se technicky nemělo počítat jako emoji)
Toto je poprvé, co se účastním série blogových příspěvků Ember roadmap. Osobně se mi líbí Ember a jeho abstrakce, které umožňují a zvyšují produktivitu.
Abych mohl napsat tento blog, připravil jsem seznam věcí dokumentace WRT a komunikace v ekosystému, které lze zlepšit. Při kontrole dokumentů a průvodců Jsem ohromen tím, že většina těchto bodů je již vyřešena v dokumentech Guides and API. To je skvělé vědět. Díky všem hlavním týmům a přispěvatelům.
Níže je seznam několika věcí, které v nadcházejících letech rád vidím v základním rámci a okolních ekosystémech.
1) Lehké konstrukce
Jedním z důvodů, proč se Ember mezi moderní frameworky nepovažuje (to je hořká pravda), je ten, že se snažíme vybudovat plnohodnotný framework se všemi bateriemi v ceně a skončili jsme jako tlusté dítě. Osobně miluji tuto povahu Ember, protože většina webových aplikací tyto baterie v určité fázi vývoje nakonec přidala.
Když však vývojář z jiného frameworku nebo nový vývojář JavaScriptu hodnotí frameworky, velikost balíčku bude převládajícím rozhodujícím faktorem. Takže strom třese moduly frameworku (a kód aplikace), dokud nebude použit, bude mít velký dopad na výše uvedené hodnocení. Rád vidím, že tyto sestavení jsou výchozí v budoucích aplikacích Ember.
Existují případy, kdy jsem z tohoto důvodu musel opustit Ember, přestože Ember překonává většinu ostatních populárních frameworků jako React nebo Vue WRT. rychlost vykreslování
2) Vyšívat
Osobně si myslím, že jsme příliš viseli na specializovaném stavebním nástroji, který byl postaven na brokolici po dlouhou dobu. Experimentování se stávajícími oblíbenými sadami nástrojů, jako je Webpack with Embroider, je tak skvělé a funkce, které si ostatní uživatelé frameworku užívají již dlouhou dobu, jako je HMR , Rozdělení kódu na různých úrovních (trasa, součást atd.) lze pomocí Embroideru přivést do ekosystému ember. Líbí se mi, že je vyšívací nástroj v roce 2019 výchozím nástrojem.
3) Dokumenty kolem Ember CLI a Broccoli internals
Vývoj addonu, který není prezentační, je v Emberu opravdu těžší proces. Skutečná dokumentace API pro CLI opravdu není užitečná pro snadné provedení úkolu (TBH, to je nemožné). Obvykle odkazuji na jiné podobné doplňky, které využívají tyto háčky a učím se z nich, abych implementoval svou logiku. Vzhledem k tomu, že se jedná o věci na nízké úrovni, byla by skvělá dokumentace.
4) Chybová komunikace
To je inspirováno ekosystémem Vue. Nejsme skvělí ve sdělování chyb vývojářům. Jakmile narazím na několik problémů, je těžké je odladit a přinejmenším vyžaduje značnou znalost rámce k jejich identifikaci a nápravě.
Při práci s Vue mám pocit, že chybová komunikace je elegantnější. V některých případech stačí zkopírovat a vložit navrhovaný výstup z konzoly do mého kódu, aby to fungovalo. Vidím, že chybové zprávy v Emberu se neustále vylepšují a bude skvělé, když to vezmeme v úvahu při sestavování plánu na nadcházející rok.
Pro nového vývojáře může být hledání příčiny problému na Googlu opravdu zdrcující, pokud mu nebyl poskytnut potřebný kontext, a mohlo by to vést k odchodu lidí.
5) Registrace vývojáře
Musím se smířit s tím, že začlenění nového vývojáře je mnohem snazší ve srovnání s dřívějšími dny. Ale je tu několik malých hrbolků, které jsem osobně v posledních letech viděl.
QueryParams
Může to být maličkost, ale opravdu to není intuitivní. U nových vývojářů jsem při práci s parametry dotazu viděl, že jim není zřejmé, proč musíme provádět zápis do různých souborů (soubor řadiče a odpovídající soubor trasy) TBH, osobně nedokážu zdůvodnit, proč je to implementováno takovým způsobem.
Testování jako samostatná sekce v tutoriálech
Může se jednat o „Nepopulární názor“, ale oddělení testovací části v tutoriálu může být dobrou volbou, zejména když nový vývojář poprvé zkouší rámec. Obvykle nový vývojář rád vidí něco na obrazovce tak rychle, jak je to jen možné, a většinou vidím, že mnoho vývojářů tuto sekci testování přeskakuje a začíná znovu, až když se se skutečným rámcem seznámí.
Složení komponent a osvědčené postupy
Základní kázání témat jako „proč potřebujeme komponenty?“ a „Jak lze vytvořit část uživatelského rozhraní pomocí různých složení komponent“ a možná by prospělo jen málo převládajících anti-vzorců. Uznávám, že většina z těchto témat je silně zaujatá, ale bylo by skvělé, kdybychom zdokumentovali alespoň to nejpřijatelnější. Možná v sekci s názvem "Pokročilé koncepty komponent" nebo něco podobného.
6) Ember CLI Presets nebo Project template
To je trochu příjemné na funkčnost. Osobně se mi líbí způsob, jakým Vue používá CLI. Můžeme si ručně vybrat funkce, které budeme používat v našem projektu, jako je TS nebo JS, komponenta založená na třídě nebo klasické komponenty, Need Service Workers nebo ne ze samotného CLI a podpůrné balíčky za nás nainstaluje CLI. . Pak to můžeme uložit jako přednastavení a použít je v budoucích projektech. V Emberu používáme features json upravit tato nastavení a bylo by skvělé mít toto integrováno se samotnou službou CLI.
Úžasný addon, jehož cílem je udělat podobnou věc, je ember-cli-create (jako vue create )
Tento příspěvek byl původně umístěn na mém osobním blogu:https://gokatz.me/. Články o EmberJs, Chrome Extensions atd. najdete také na blogu