EmberJS frissítése 2.18-ra

[jmarton]

A 2.18-as EmberJS lesz a 2.x sorozat utolsó tagja, várhatóan kap majd LTS szupportot, ami kb. 60 hetet jelent.

Jelenleg - ha jól látom - a 2017. márciusi 2.11.3 verziójú EmberJS van a frontend alatt, ami nem is LTS

A 3.x-es verzió nem fogja támogatni az IE9, IE10 és PhantomJS környezeteket, ezért egyelőre nem lépünk fő verziót.

[lordblendi]

Valoban jot tenne egy frissites a rendszernek, sok hasznat latnatok. De azert ez nem egy egyszeru feladat. Van hozza tool, amit hasznaltam: https://github.com/kellyselden/ember-cli-update. De utana meg rengeteg bugfixet kellene csinalni (es sok ido lehet megtalalni, hogy melyiknek hol van a gyokere). Plusz az ujabb Emberben pl nincs bower. Biztos vissza lehet rakni, azt meg nem probaltam.

Mi inkabb a kezi megoldast szoktuk valasztani a cegnel nagyobb projekt eseten: Keszitunk egy uj projektet, es egyenkent letrehozzuk a komponenseket benne. Viszont igy biztos, hogy a generalt komponenses (js es hbs fajlok) jol lesznek "osszecsatolva". Azokba copy paste code, ami szukseges, es akkor folyamatosan tesztelni, hogy mi mukodik es mi nem. Ez lassabb, de celravezetobb. Es sokkal egyszerubb bugokat megtalalni.

Modositas 2018.01.23. 20:17:
Es ne felejtsuk el, hogy az ember-addonokat sem feltetlenul tartjak mindig karban. Ez is okozhat gondot.

[csutorasr]

A bower-t el kell felejteni., ahogy a honlapjukon is irjak.

Ha uj projektbe masolnam at a kodot, akkor biztosan valami mas frameworkot hasznalnank. A json api-t is tamogatjak tobbnyire. (Talaltam lib-et, ami tudtommal 4.2-es anuglarig mukodik deprecated kod hasznalata nelkul) Bar az uj frontend a json api eldobasat is jelentene szerintem, ami nagy backend feladat lenne. (pl graphql-lel mindig a megfelelo adatok kerehetoek le a backendrol, es nem lenne ez a nagy felesleges mennyisegu adat lekerve)

A webpack sokat segitene a toltesi idon (AOT), es az adatmennyisegen is.

(@szaszm irt androidos appot is a diakoknak a jegyeik lekerdezesere, de nem tudom vallalja-e)

[lordblendi]

Bower nelkul valoban megvagyunk, ha nem hasznalsz semmit a frontendben, amihez szukseges.

graphql-lel mindig a megfelelo adatok kerehetoek le a backendrol, es nem lenne ez a nagy felesleges mennyisegu adat lekerve

A megfelelo filter hasznalattal ez megelozheto lett volna. Plusz felesleges az included-be beletomni mindent, hogyha a hianyzo relaciokat ugy is lekeri az Ember Data.

[csutorasr]

A problema a model bonyolultsagan van. Az ember data mindent lekert, csak amikor a demonstrator lekerte a diakjait (pl 20 db), akkor azt az event template-hez tartozo eventek, annak a deliverable-jai (mert kellenek az ertekelesek), amibol van 2, a student registration (mert azon keresztul erheto el a student) es a student lekerdezese a feladat. Ez 20*(1+2+2) lekerdezes. Ez 100ms-es backend idovel szamolva (a ping tavolsagot hanyagolva) 10 sec. Az include-olt helyzet 2s korul alakult (ugy hogy sok metaadat ismetlodik a jsonapi miatt). A problema, hogy a backend sem ilyen gyors es ping ido is van.

ADDED:

A js feldolgozasi ido ki is maradt.