ExJS TypeScript emitter

ExtJS s využitím dynamických vlastností javascriptu ponúka OOP nadstavbu nad týmto jazykom. O to isté sa snaží aj TypeScript, ktorý navyše prináša typovú bezpečnosť, ale z pohľadu samostatného jazyka, ktorý sa kompiluje do javascriptu. Je prirodzené, že najlepší výsledok je možné dosiahnuť práve spojením týchto prístupov. Bohužiaľ, toto nechápe alebo len ignoruje samotná Sencha a aj tvorcovia TypeScript. Našťastie to pochopila komunita vývojárov a Fabio Parra(https://github.com/fabioparra/TypeScriptExtJSEmitter) patchol typescript emitter javascriptu tak, aby generoval javascript v súlade so systémom tried, ktorý ponúja ExtJS.
Bohužiaľ, aktuálne je k dispozácii emitter len verzia 1.8 ale už čaká pull request na merge pre verziu 2.0. 

Lepšie asi vidieť o čom je reč na príklade:

TypeScript

module foo.bar
{
    export class Greeter {
        greeting: string;
        constructor(message: string) {
            this.greeting = message;
        }
        greet() {
            return "Hello, " + this.greeting;
        }
    }
}
 
let greeter = new foo.bar.Greeter("world");
 
TypeScriptom generovaný ExtJS

Ext.define('foo.bar.Greeter', {
    constructor : function Greeter(message) {
        this.greeting = message;
    },
    greet : function () {
        return "Hello, " + this.greeting;
    }
});
var greeter = new foo.bar.Greeter("world");
 
Pôvodný kód bez emitteru a extjs
var foo;
(function (foo) {
    var bar;
    (function (bar) {
        var Greeter = (function () {
            function Greeter(message) {
                this.greeting = message;
            }
            Greeter.prototype.greet = function () {
                return "Hello, " + this.greeting;
            };
            return Greeter;
        }());
        bar.Greeter = Greeter;
    })(bar = foo.bar || (foo.bar = {}));
})(foo || (foo = {}));
var greeter = new foo.bar.Greeter("world");

Viac príkladov je možné vidieť tu:
https://rawgit.com/fabioparra/TypeScriptExtJSEmitter/master/TypeScriptExtJSEmitter/index.html

Zaradené do: ,

Komentáre

# liero said:

Neviem, odkial to ludia maju, ze TypeScript prinasa OOP nasdstavbu do JavaScriptu. Neprinasa. JavaScript samotny prinasa OOP -> ES6, ES7.

Ulohou typescriptu je len umoznit lepsiu podporu toolingu pomocou statickych typov. To ostatne je len ceresnicka na torte. Pokial toto ludia nepochopia, bude pre nich typescript viac brzda, ako pomoc.

Co sa tyka transpilacie, tak po odstraneni type annotations, transpilacia musi byt kompatibilna s W3C specifikaciou. Toho co je specificke pre typescript je velmi malo.

Co sa tyka ExtJS, tak dnes by uz asi nikto neskusal urobit framework na simulaciu OOP. Preto si myslim, ze robit specialny emmiter pre ExtJS nieje spravny krok. Nieje to totiz trivialna zalezitost a s kazdou novou verziu typescriptu bude problem s emmiterom.

Saturday, December 17, 2016 11:00 AM
# T said:

@liero: Az na to, ze typescript tu bol skor ako ES6 a toto ako vysvetlis?  

var __extends = this.__extends || function (d, b) {

   for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p];

   function __() { this.constructor = d; }

   __.prototype = b.prototype;

   d.prototype = new __();

Ak dovolis, ulohu, typescriptu si nastavim sam. Ale kludne upresni v com je/bude pre konkretne pre mna brzdou?

"Co sa tyka ExtJS, tak dnes by uz asi nikto neskusal urobit framework"

....naco by ho robil, ked je ich tu uz roky niekolko

"reto si myslim, ze robit specialny emmiter pre ExtJS nieje spravny krok. Nieje to totiz trivialna zalezitost a s kazdou novou verziu typescriptu bude problem s emmiterom."

Ano, to plati o kazdom nastroji so zavislostou na inom externom komponente. Navyse nikde nie je napisane, ze musis prejst hned na novsiu verziu TS. Patchnut si tsc nie je ziadna velka veda v konecnom dosledku. Uz dnes je tam niekolko "modulov".

@liero sorry, ale celemu prispevku chyba akekolvek uchopitelne posolstvo alebo vecny argument, skus rozviest

Sunday, December 18, 2016 12:24 AM
# liero said:

Dovolil som si pokusit sa tlmocit to, co hovori A.Hejlsberg - autor typescriptu - o typescripte. Jeho definicia v case ked predstavil typescript pred par rokmi: Typescript je jazyk, ktory do javascriptu prinasa staticke typy a umoznuje pouzivat ES6 prvky uz dnes. A opakuje to donekonecna. To bolo moje posolstvo.

Sledujem rozne feature-requesty na githube a som predvedceny, ze request nejakeho custom emmitera by reagovali v takomto zmysle. V typescript teame tiez prebieha diskusia o tom, co vsetko by mat typescript robit. A. Hejlberg dokonca chcel z typescriptu vyhodit aj velku cast transpileru a cely minifier.

Sunday, December 18, 2016 7:41 PM
# liero said:

ES6 bol v preview specifikacii, ked vysiel typescript. A. Hejlsberg vtedy hovoril, ze snazili sme sa vsetko urobit tak, aby to bolo kompatibilne s ES6, ale kedze jeho release sa stale oddaluje, nemozeme uz dalej cakat. Takto vzniklo napriklad to, ze slovo module povodne v typescripte znamenalo nieco uplne ine, ako v ES6. Jednoducho v ES6 specifikacii sa to medzitym zmenilo.

Odvtedy na githube odmietaju akykolvek feature request, ak je sanca, ze dana feature by mohla pribudnut aj do javascriptu, aby sa vyhli tomu, co sa stalo z modulmi. Dobry priklad je Null-Conditional operator: github.com/.../16

"it's certainly possible for ES to adopt a feature that is already present in TypeScript, but with different semantics"

"I should note that we broadly consider this to be a worst-case scenario. We really wanted modules in ES6 to be finalized before we declared TypeScript 1.0, but the committee's schedule delays prevented that. This is something to be avoided, not repeated. We'd really like to hit features that have either a ~0% chance of making it into ES7+ (e.g. type annotations), or have a ~100% chance of making it in with easily-defined semantics (e.g. where fat arrow was two years ago). New operators are likely to fall in the awkward middle."

Sunday, December 18, 2016 7:50 PM
# liero said:

Co sa tyka tej transpilacie (extends funkcia), nechapem celkom, co mam na tom vysvetlovat. Ked si zvolis ES6 compilation target, tak ziadena extend funkcia nieje emmitnuta.

Ked si zvolis ES5, tak je tam taky polyfill aby to bolo kompatibilne. ES6 classy boli umyselne navrhnute tak, aby sa dali transpilovat do ES5 (W3C tusim dokonca definuje aj tieto transpilacie) a TypeScript len ide v zmysle tejto kompatibility

"v com je/bude pre konkretne pre mna brzdou?"

Pre teba alebo pre mna v nicom. Brzdou by to mohlo byt pre TypeScript ako taky. Napriklad by sa im skomplikovala implementacia nejakej ES7 feature, pretoze by to bolo v konflikte s niecim v ExtJS, ale to si uz naozaj vymyslam....

Sunday, December 18, 2016 7:58 PM
# liero said:

Co sa tyka tej extends funkcie, neviem, co na tom treba vysvetlovat.

1. Ked si zvolis ES6 compilation target, tak ziadna taka funkcia tam nieje. Vtedy je transpilacia takmer 1:1.

2. ES6 triedy boli navrhnute tak, aby boli spatne kompatibilne s ES5 a teda sa dali emulovat pomocou nejakej transpilacie. Typescript len ide v tomto zmysle. W3C dokonca tusim niekde definuje aj to, ak maju vyzerat tieto transpilacie.

"V com je/bude pre konkretne pre mna brzdou?"

Pre teba alebo pre mna v nicom. Myslel som to skor z pohladu TypeScript teamu. Oni sa nezaviazu k niecomu, co im moze v buducnosti sposobit problemy. Napr, ak by vznikla nejaka ES7 feature, ktora by bola v konflikte s ExtJS, tak co? Ale to si uz naozaj vymyslam..

Sunday, December 18, 2016 8:07 PM
# T said:

@liero: liero, este raz, ohradil si sa voci mojmu vyroku ohladom toho, ze typescript prinasa OOP nadstavbu. Dokonca to, ze pri jeho vzniku(zacal vznikat asi niekedy 2012), ze niekto tusil, ze novy ES prinesie aj OOP moznosti a chcel dopriat tieto moznosti developerom uz skor jeho opodstatenost potvrdzuje(aj ked som nepoznal priznavam detaily). Este dnes tam mas barle ako vidis a nijako si na to nereagoval. Ale davno davno predtym boli ludia, ktori videli ako do js priniest OOP nadstavbu a niektori k nej predali aj komplexne framework, tooling...napr. extjs.

Tvoje posolstvo bolo, ze niekto nieco opakuje dookola? Mna netrapi co kto opakuje ale ake ma argumenty. Bez neho mi je akekolvek posolstvo na dve veci.

Request nejakeho custom emitteru - vobec si nepochopil, custom emitter by mal by vecou senche a lepsi class system zase vecou typescriptu. A cakat na ES10 a este aj s knizicami ktore budu aspon trosku siahat na uroven tych extjs sa mi naozaj nechce.

__extends / je to len dokaz o tom, ze typescript tu OOP nadstavbu prinasa, je uplne jedno, aka motivacia za tym bola...pretoze si reagoval prave na tento moj vyrok

"ale to si uz naozaj vymyslam...."

Vymyslas :-) bol by to problem emitteru pre extjs, ktory sa da upravit a ak raz ES1X bude aspon na tej urovni ako class system v extjs aj sencha mozno vyhodi svoj class system. Specialne z pohladu typescriptu nad extjs budem na tom lepsie ako bez neho(nebudem zrejme musiet prerabat takmer nic, ja ako developer).

Sunday, December 18, 2016 9:52 PM
# liero said:

ok, zase sa hrame zo slovickami.

Ja tvrdim, ze TypeScriptove classy neexistuju, existuju iba JavaScriptove classy. Hovorit, ze TypeScript je OOP nadstavba JavaScriptu, sa mi zda take iste, ako hovorit, ze Babel je OOP nastavba JavaScriptu. Tu je to uz iba o tych slovickach.

Emmiter v TypeScripte ma v zmysle Hejlsbergovej definicie TypeScriptu z ulohu:

1. odstranit Type Annotations

2. transpilovat ES6,7 do ES3, 5 s optional minifikaciou

pricom aj bod 2 je obcas spochybnovany tym, ze nato tu mame Babel a Uglify.

Potom nastava otazka, preco by sa o tu transformaciu do ExtJS mal starat TypeScript a nie Babel?

Mimochodom TypeScript->ES6->Babel->ES5 je dnes najviac preferovana volba

Sunday, December 18, 2016 10:42 PM
# liero said:

aha, uz mozno zacinam chapat, co chces povedat. Ze typescript nejakym sposobom simuluje classy v ES5 a pouziva k tomu nejake barlicky. ExtJS robi to iste so svojimi barlickami. Preco by teda typescript nemohol pouzivat tie ExtJS barlicky? Pochopil som to spravne?

V pripade dnesneho TypeScriptu vysledok musi presne zodpovedat spravaniu sa ES6. Predpokladam, ze preto je to problem, lebo ExtJS triedy niesu 100% kompatibilne s ES6, co sa tyka spravania.

Sunday, December 18, 2016 10:55 PM
# T said:

@liero:

ano, pochopil si to.

"V pripade dnesneho TypeScriptu vysledok musi presne zodpovedat spravaniu sa ES6."

Ale to hovoris Ty a mozno autor. existuje ina moznost pouzit typescript spolu s vyspelim frameworkom...a preco ho nevyuzit.

Ext triedy su plne kompatibilne s ES6 :-) ale nevyuzivaju plne moznosti es6.

Sunday, December 18, 2016 11:59 PM
# liero said:

Myslel som, ci su ExtJS triedy plne kompatibilne s ES6 triedami. Napriklad, sprava sa this keyword rovnako?

Rozmyslam, ci namiesto custom emmitora by nebola lepsia cesta ist s cisto typescriptovymi definiciami + nejaky codegen, resp v tomto pripade type definition generator.

Myslim nieco na tento sposob:

Ext.define('Beer' { cheers: function () { }})

Z tohto by sa vygeneroval prislusny interface a overload metody Ext.Create('Beer') : () => Beer.

Pripadne by sa typescript mohol naucit rozumiet ExtJs definiciam, podobne ako sa naucil rozumiet JsDoc napr.

Prislusny interface Beer si uz teraz typescript takmer vie odvodit sam. Bolo by treba dorobit aby pochopil ExtJS mixing, inheritance a ctor, co by nemal byt az taky velky problem

Implementovat obe riesenia by bolo IMO ovela menej roboty a hlavne by si to nevyzadovalo takmer ziadny maintenance s novymi verziami typescriptu.

Ked uz custom JS Emmiter, tak potom by som to robil ako plugin do babelu.

Wednesday, December 21, 2016 7:44 PM
# liero said:

Ten napad s generovanim type definitions sa mi zacina pacit :)

Len si to predstav. Copy&Paste-ol by si exitujuci js kod to .ts suboru a hned by si dostal compile-type checking. Potom by si uz len doplnal typy do parametrov funkcii. Casom by si mohol vypnut --noImplicitAny. Kod by vyzeral identicky s cistym JS kodom, az na nevyhnutne deklaracie typov. Presne tak, ako bol typescript zamyslany.

Wednesday, December 21, 2016 7:56 PM
# T said:

@liero:

Viem ako si to myslel s tou kompatibilitou.Jasne, ze nie su "kompatibilne" z pohladu class systemu es6, hore v clanku mas priklady.  this funguje ako v es5, cize this v metode triedy normalne funguje ale s limitaciami scopingu es5.

Typedefinition generator existuje, to je dalsia vec, ktora Ti samozrejme pomaha.(dokonca je viac ako jeden takyto generator:-) Toto som bral ako samozrejmost, bez toho by typescript nad ext nemal az taky velky vyznam, produktivita

Neviem, ci som Ta pochopil spravne, ale ja chcem pisat typescript syntaxou definicie tried(es6), pretoze ak ext raz prerobi framework na es6 kompat, tak nemam taky velky problem ako ked si to budem pisat priamo cez extacke zapisy, Dalej, ked budem chciet pouzit Kendo alebo Jquery UI tak pouzivam tu istu syntax, co je fajn, ked chces zapojit novych javascript neexpertnych ludi do takehoto vyvoja.

ALe vysvetli, ako som nepochopil.

Este drobnost, pozeral som, kam smeruje Dojo (filozofiou velmi blizky ext)

Continue to Push JavaScript Forward

Firstly, Dojo 2 will be written in TypeScript. While ES6/ES2015 offers some much needed improvements, there are many unfinished things. Languages like TypeScript allow us to add extensions to improve JavaScript, before they are added to the language. Then we can easily compile/transpile to JavaScript in AMD, CJS, or ES6 module formats. This allows us to improve the language itself, but more importantly, improve your productivity.

A uprimne, toto je ovela lepsie nadhlad a smerovanie ake ma sencha, ktora typescript ignoruje....presne taketo nieco by som si rad precital aj u senche

Wednesday, December 21, 2016 9:11 PM
# liero said:

Aha, no ta motivacia preco chces ES6 syntax mi unikla. Sice si myslim, ze si tym viac ublizis ako pomozes, ale to uz necham na teba.

Mimochodom, aj Angular2 je napisany v TypeScripte, ale to asi vies. Robil som teraz dve aplikacie v Reacte a musim povedat ze TypeScript sa hodi na React ako rit sa serbel. Paradoxne s TypeScriptom nemusis pisat PropTypes (akesi Reactove definicie typov, ktore sa chechukuju runtime), takze je to este menej kodu. Facebook sa dokonca inspiroval TypeScriptom, okopiroval z neho typovy system a nazval to Flow. Flow nieje nic ine, ako TypeScript bez transpilacie, resp s prizmurenym okom plati rovnica: TypeScript = ES6 + Flow + Babel

Wednesday, December 21, 2016 10:44 PM
# T said:

nevedel som, len Anguler nema ambiciu "vylepsovat" JS ako dojo a ext, je to ucelovy fmwk, ktory berie JS taky aky je a OOP sa nezatazuje.

Stale si mi ale nepovedal, ako si ublizim, ked sme to uz prediskutovali z prava aj zlava a celkom ma to zaujima. Viem co to prinesie (samozrejme, este sa stale moze objavit nejaky pruser hlboko v patchnutom emitteri), pocnut produktivitou konciac typmi.

Thursday, December 22, 2016 11:55 AM
# liero said:

1. "chcem pisat typescript syntaxou definicie tried(es6), pretoze ak ext raz prerobi framework na es6 kompat"

Kde mas istotu, ze ked to prerobia na ES6 kompat, tak to urobia tak, ze tvoj kod bude fungovat. Vidim dve moznosti. Bud to spravia tak, ze novy ExtJS bude navrhnuty tak, aby bol prechod jednoduchy. V takom pripade by som radsej chcel mat extacke zapisy, pretoze mozem upgradovat podla navodu. Skor si ale myslim, ze to bude nieco uplne ine ako napr Angular1.x -> Angular2. V takom pripade ti tvoj typescriptovy kod s clasami bude naozaj len na pritaz.

2. "budem chciet pouzit Kendo alebo Jquery UI tak pouzivam tu istu syntax" Pokial viem, jQueryUI nepouziva triedy. Kendo tusim tiez nie, ani vacsina inych kniznic. Keby aj, nevidim v tom ziadny benefit, mat vsetko napisane cez triedy.

ES6 nieje ina syntax ako ES5, len ju dopluje o par veci. Tak ci tak musis poznat vsetky ES5 veci. Jedine od coho ta mozno uchrani su prototypy. Ale to robi ExtJS aj tak.

3. "ked chces zapojit novych javascript neexpertnych ludi do takehoto vyvoja.". Toto mi pride ako utopia. Taky clovek ked pozrie do ExtJs dokumentacie a potom to ma pretransformovat to Typescriptu s classami, musi aj tak rozumiet obom. Pre neho je to akurat tak komplikacia.

Pre mna ako stredne pokrocileho JS developera bez skusenosti s ExtJs by bolo urcite jednoduchsie pouzivat klasicky zapis. A to aj napriek tomu, ze typescript poznam celkom dobre.

Robit som knowledge transfer na jedneho Java developera bez velkych js skusenosti. Tykalo sa to len mojej reactovej aplikacie (ReactJs je postaveny na ES6 triedach). Tak ci tak sa musel najprv naucit ES5, potom ES6 a potom TypeScript (thanks god for pluralsight!).

CoffeScript sa mozno snazi zmenit JavaScript, ale TypeScript nie. TypeScript sa naopak snazi byt co najblizsie k JavaScriptu a pridat tam podporu refacktoringu a compile-time validacie, aby si vedel pisat udrziavatelny kod. Cize uplne odplisny pristup.

5. takyto radikalny zasah do typescriptu a jeho zneuzitie na nieco naco nebol navrhnuty moze byt velke riziko. Typicky priklad - budes chces pouzit najnovsie jquery, ale jquery.d.ts uz budu napisane pomocou TypeScript 2.1. TypeScript sa totiz zlepsuje hlavne v tejto oblasti a umoznuje pisat coraz lepsie TypeDefinitions. Ty ale nebudes moct upgradnut kvoli custom emmiteru.

Inu neprijemnost vidim v tom, ze ked zmenis js emmiter a vysledni kod sa bude spravat trochu inak, tak tooling nemusi sediet. Napriklad budes musiet neprirodzene pretypovavat this...

Thursday, December 22, 2016 8:57 PM
# liero said:

Ja v tom custom js emmitery dokazem vidiet len jednu vyhodu, ktora stoji za rec a sice ze kodenie by bolo zrejme omnoho pohodlnejsie ako s type-definition generatorom. O ostatnych "vyhodach" som zapolemizoval vyssie

Thursday, December 22, 2016 9:01 PM
# T said:

1. Istotu nikde a nic take som netvrdil. Ine som hovoril, ze je velka pravdepodnost, ze to tak bude, alebo ze to portnem s vyrazne mensim usilim,

2. pokym robim v typescripte pouzivam tu istu typescript syntax aj pre ext aj pre kendo napr. pre definiciu tried. Co je na tom nepochopitelne?  Uchadza mi pointa celej argumentacie v tomto bode. (len btw. aj kendo ma svoj class system, akurat nema emitter pre ts)

3. musi rozumiet tomu na co je dana trieda a na co je metoda, ake ma parametre, jedine z pohladu nejakych samplov ktore su sucastou dokumentacie bude mat ale fakt len mozno problem, (ale sample z dokumentacie nie su rozhodne tym, na co maju byt zo zaciatku odkazani)

Samozrejme, ze sa postupne nauci aj JS syntax a samozrejme, ze je vyhodou syntakticka pribuznost/suvztaznost ts a js.

Naco do diskusie tahas coffee, react ...

4. Pouzivam typescript na rovnaky ucel ako bol vymysleny, len inak ako bol vymysleny. A to je uplne normalna ludska vlastnost hladat ako inak pouzit zname veci, ktora nas posuva dopredu.

Samozrejme riziko toho, ze s novou typescript verziou nebude hned alebo vobec emitter tu je a ratam s tym. Ale ako mi to moze bezprostredne uskodit, ked som dnes schopny v tom urobit projekt netusim. Naozaj to povazujem za hlupe porovnavat aktualne prinosy s hypotetickymi problemami buducnosti. Ze nebudem vediet pouzit hned ts 2.1? No a co, ani C# kod neprerabam tak, aby vyuzival vsetky syntakticke features novej verzie. JQuery pouzit nebudem chciet s extjs a definicie si viem vygenerovat z extjs dokumentacie

to co nazyvas pohodlnejsie ja nazyvam produktivitou a ano, to je ta pridana hodnota o ktoru mi ide primarne, najdolezitejsia, bezprostredna. Diskutujeme tu o es6 ale es6 dnes nie realna volba. ExtJS je komplexny framework a porovnavame ho z pohladu buducich rizik s cim? Holym javascriptom. Vyskladaj na druhej strane ekvivalent extjs a potom mozeme porovnavat komplexne (prinosy,rizika).    

Friday, December 23, 2016 6:12 AM
Prihlásiť | Registrovať | Pomoc