Vidis, ja bas gledam da se polako iskljucim, tj. radim na tome 
Yep, plus MDN kaze sljedece za await 
The
awaitoperator is used to wait for aPromise. It can only be used inside anasync function.
Ostatak mi se ne da citati, sve u svemu drago mi je sto imas jos jednu soluciju na listi
Da sam dobio barem marku svaki put kad mu je neko predložio da se lati dokumentacije…
PM? 
Primijetio? Koji po tebi nema smisla?
PM kao detalji na Private Message, ili mislis na PM role (Product/Project manager) - malo mi je konfuzno ?
Ako je ovo drugo, odmah da kazem da nije
Onda ništa. 
Da, drugo-be.
Razumijem…ima toga…
Možda ti samo ovo bude hint za kompletno rješenje:
function someParentFunkcion(a,b,c,f){
//some code before confirmation
if(!dialogConfirm("Želiš li nastaviti?", arguments) return;
//some code after confirmation
}
…ključ je u arguments. Ako te slučajno zanima što je iza dialogConfirm, zalijepim ti…
Daleko od toga, samo se selim na drugu stranu - tu gdje ti vec jesi
Aaa. Go i Ruby (and little bit of Monica Python)?
Pa zapravo u tom teksu ne piše ama baš ništa značajno što bi čovjeka trebalo natjerati na arrow funkcije. Ima tamo prednosti i mana jednog i drugog pristupa. Tako da ako bi se arrow i uzeo u obzir, nebi to bila permanenta promjena…nego djelomična po potrebi.
A to što se arrow funkction ne ponaša identično kao klasična, to baš i nije plus. Treba ipak imati na umu da neki relativno moderni browseri još uvijek ne podržavaju takve kerefeke. A sa klasičnim načinom se moglo praviti sve što i sa time… eto, koliko vidim iz teksta, jedino je u klasičnom načinu minus što negdje treba svjesno iz kontrolirati ponašanje “this” varijable, sa zarobljavanjem na način: var self = this;
I to je jako poznato kako se model ponaša…i nije nikakav problem.
A što se tiče rest parametra, pa taj dio je recimo upravo minus za arrow funkcije. Ne znam kako si to uspio pročitati kao prednost?
One zapravo ne podržavaju arguments unutar funkcije, pa se mora sama input varijabla konceptirati na način da se koristi rest parametar, da bi se tom modifikacijom omogućio arguments. Koji po defaultu imaš u klasičnim funkcijama bez da išta petljaš.
Kako god, sve ima svoje prednosti i mane i iz tvog priloženog teksta je više nego očigledno da arrow funkcije nemaju ultimativnu prednost nad klasičnim. (Imaju zapravo jednu vrlo usku i ograničenu prednost). Zato nema potrebe niti za ultimativnim prelaskom na njih…tj. ultimativnim korištenjem samo jednog načina od toga dvoje.
Pa naravno da normJS neće izmišljati nazive iz nule. Treba prekopati uzduž i popreko sve najkorištenije nazive i postaviti standard prema onome što se najčešće koristi od strane velikih.
Već je sada očigledno kako neki nazivi trebaju biti, no to što je očigledno i da bi bio propisan standard prema tome očiglednom…je velika razlika.
Jer standard je vodilja upravo onima koji nisu upoznati sa širom materijom i praksom… i kojima nije očigledno.
Nije poanta da jedan ima smisla ili nema. Dok je razvoj komponenti in-house…nazivi mogu biti po toj in-house konvenciji. I nema tu što imati ili nemati smisla. Problem je što te in-house komponente završe ponekad i out-house i onda dolazi do jedne velike šarenikolitosti.
Cilj je postići ovo…
…da se vratim na komponentu confirmDialog, koja upravlja “nekim” dialogom. Zamislimo da tvorac te komponente ne zna kakav dialog je upogonjen na aplikaciji gdje će se koristiti njegova confirmDialog komponenta. A on da bi svoju konfirmaciju prikazivao u skladu sa ostatkom stranice, naravno da želi prikazati isti dialog koji se prikazuje na ostatku stranice.
Osim vizualne izjednačenosti, to puno utječe i na pozadinske libriry-e koji se povlače u projekt…pa je to veliki optimizacijski boost. (Ako se gleda šire, na usklađivanje svih komponenti aplikacije)
U sljedećem code-u treba primjetitii samo u zaglavlju funkcije sljedeće:
var dialog = normJS.dialog;
…a evo i cijeli code confirmDialog-a. (Iako je mehanika toga codea ovdje totalno nebitna)
var DialogConfirmGlobalState = {confirmedStates:{}}
function dialogConfirm(uniqProcessName, poruka, onTrue){
var dialog = normJS.dialog;
DialogConfirmGlobalState.confirmedStates[uniqProcessName] = DialogConfirmGlobalState.confirmedStates[uniqProcessName] || {};
var This = This.confirmedStates[uniqProcessName]; //This je individualno vezan uz "uniqProcessName" ...kako različite konfirmacije nebi mogle doći pod konflikt
if(!This.confirmed){
dialog({
msg:poruka,
onTrue:function(){
This.confirmed=true;
onTrue();
This.confirmed=false;
}
});
return false;
}
return true;
}
A negdje u zaglavlju projekta:
normJS.dialog = Perin_dialog;
// ili:
normJS.dialog = Swal;
Sada smo postigli da je komponenti dialogConfirm totalno nebitno koji dialog je upogonjen na projektu, dok se zna da taj dialog poštuje normJS standard, neće ništa puknuti i u samo jednom registratoru komponenti se može kompletno izbaciti iz projekta Perin dialog i zamjeniti sa Swal-ovim dialogom.
Sada zamisli istu fleksibilnost sa svim modernim komponentama koje imamo…
Ili još bolje…treba zamisliti koje sve komponente bi mogle nastati pod tim okolnostima, kada se sve mogu razvijati kao da imaju na raspolaganju sve žive komponente iz projekta u koji će se uključiti, bez da one same po sebi podižu dependency tom projektu prema komponentama koje žele koristiti da isporuče svoju funkcionalnost.
Tu je čarolija
Velika logička pogreška.
Po tvome skoro nitko nebi ništa mogao mijenjati, jer samo su rijetki oni koji za jednog života nauče što drugi stignu za dva života. Totalna glupost.
Gle, svi mi mijenjamo svijet…neki više, neki manje. Čak i kada smo ne-ambiciozni da nešto mijenjamo, opet ga mijenjamo sa svojim kenjanjem, plakanjem ili kukanjem.
Drugim riječima i izostanak reakcije je reakcija :D.
A ti si mnogo pesimističan u pogledu na sebe i koja je tvoja uloga u ovom svijetu. Ali kao što rekoh, ne trebaš niti znati da mijenjaš svijet da bi ga mijenjao. Tvoj hejt prema meni je jedna velika moja motivacija da budem još i bolji. Tako da…vidiš da i ti mijenjaš svijet. 
Ono što je još bitno primjetiti, komponente poput dialoga se koriste nevezano jel bila platforma:
…pa jedna standarizacija u pozivu komponenti približava tome da i različite platforme počmu međusobno lakše komunicirati.
Tipa, imaš neku svoju komponentu koja radi sa dialogom, prekucaš ju malo za neki drugi engine…i ona bez problema dalje u toj novoj okolini upravlja sa dialozima iz te nove okoline.
Huh, da ne preskočim ovo.
Jel kužiš ti što si upravo rekao?
Reako si nešto tipa: “Sve je izmišljeno i nema se više što izmisliti.”
Bratko moj, bilo je više luđaka redovito duž cijele povijesti koji su to izjavljivali. No niti jednom očito nije išla matematika i percepcija grafova.
Jer ako grafički analiziraš tu izjavu, vidjet ćeš da što više ima toga izmišljenoga da je lakše izmisliti nešto novo. Graf je eksponencijalno rastući i ne možemo ni slutiti gdje nas vodi. Znamo samo da nebu pod oblake. Tj. znaju neki…
Shodno tome, ono što nas čeka u narednim godinama neće imati skoro nikakvu poveznicu sa današnjom situacijom, iako je ovo danas podloga iz koje će nastati naša budućnost.
A u našoj budućnosti otprilike ćemo:
programirati i komunicirati računalima u potpunosti bez tipkovnica. Drugim riječima, tipkovnice će jednog dana biti arheološka uspomena, ko danas kamena sjekira. I nije to tako niti daleko.
s računalima ćemo surađivati vizualno i audio, u potpunosti kao što to sada radimo sa drugim ljudima.
ona će pri tome odavati kao da su svjesna, do mala djeca će teško i uočavati razliku
…nebum dalje.
Kako god, pogodio ja ovo gore sada ili ne…ono što je sigurno, budućnost će biti toliko apstraktna da iz ove perspektive teško možeš o njoj i maštati. Isto kao što ljudi iz kamenog doba nisu mogli maštati o internetu, iPhoneu…i svim čudesima današnjice.
I ti kažeš da je sve dobro utemeljeno, postavljeno i da se nema tu što mijenjati? Kako da ne…
Ne. Krivo zakljucujes i izvrces ono sto sam napisao.
Ne. Oni koji mijenjaju svijet, brzo uce i ono sto tebi treba 5 sati, njima treba 1 sat. Ne mozes se usporedjivati sa van serijskim ljudima u IT-u.
Citaj sa razumijevanjem i izmedju redaka, dolazit ce nove stvari i uvijek dolaze koje ce se temeljiti na iskustvima iz prakse i na onome sto se pokazalo najbolje kroz x godina. Ovih 70 godina je bio samo primjer za ono sto sam htio reci.
Da bi tvoje ideje zazivjele moraju biti implementira u praksi na hrpi enterprise projekata i onda ce vrijeme pokazati.
Nikog ja ne mrzim. Napisao sam ti, da ako nesto neznas da proucis literaturu, a ti me popljujes.
Ja sam dobro namjeran, a ti si taj koji ima sve nas ovdje na forumu na piku.
Meni ti je tako svejedno, samo savjet, ako ces doci u firmu gdje ce biti jaci igraci i ako ces poceti nametati svoju volju, brzo ces izletjeti, tako da se ili prilagodis ili radis za sebe.
Ako ces traziti od ljudi nebulozno znanje kako ti smatras da bi trebalo biti(sto si napisao da ce morati uciti iz tvoje knjige) svi ce tu firmu izbjegavat, a gazde ce gubiti lovu, a tebe ce svi kasnije izbjegavati.
Zivili.
Mi sve više i više zalazimo u rejon gdje ti mene uopšte ne razumiješ. Ali nisi usamljen jer već i ja džinovskim koracima grabim prema istom rejonu. Još malo ni ja tebe ništa neću razumjeti.
<- Bićemo ovaj i ovaj.
Ne znam šta ti ovo znači. Daj tri linije koda šta želiš da kažeš s ovim.
Ja zapravo mislim, ustvari sve vise sam siguran, da nash @bozoou uopce ne razumije engleski, sto onda i objsnjava to da sve sto je vec odradjeno i u praksi isprobano on onda radi nanovo. Mislim to mi je jedino logicko objasnjenje zasto on sve ovo radi. Jer niti u jednom threadu do sada sa njegovim idejama nisam naisao niti na jedan jedini redak koda ili primjer koji donosi nesto revolucionarnu, a kad ga uputis na citanje dokumentacije on se jednostavno na to oglusuje.
Bila je nekad davno epizoda Star Trek-a (The Next Generation serijal) kad maltene kompletna posada Enterprajza fasuje neki virus koji im izmjijenjuje riječi. Misle šta misle ali se ne izražavaju shodno tim mislima. I niko nikog ne razumije.
Sad da mu kažeš ovo prosto nije istina niti si to gdje mog’o pročitati " One zapravo ne podržavaju arguments unutar funkcije ," on će da kaže “Nisam na to mislio već…”.
Ovog puta si ti daleko jedan klik, što ne čitaš dokumentaciju koju mi linkaš?
Dobro, mogu ti i citirati dio onoga na što se sam pozivaš:
We’ve seen how arrow functions don’t bind a
thisand they just use the value ofthisin their scope. Arrow functions also don’t bind anarguments
.
.
Mogu ti i rezumirati sve prednosti / mane koje si linkao u tekstu, kada si već sam lijen pročitati ono što linkaš. Znači redom:
Arrow funkcije, prednosti:
this, pa se može zaobići potreba deklariranja var self = this;
Arrow funkcije, mane:
this.Heto, to je iz tvog teksta
I bez brige, bacio sam ja pogled na njih nekada ranije kada sam ih prvi puta sreo…i sjećam se da tada nisam primjetio ništa značajno da se pod must selim na njih. Zato sam te u startu i pitao, koji razlog je da me motiviraš da preselim? Očekivao sam nešto smisleno, kada si već imao potrebu mi iz vedra neba to sugerirati.
Neću reći time da su one loše…nisu. Svaki alat za svoju namjenu.
Ali tvoja konstatacija iz vedra neba kako me motiviraš da pređem na arrow funkcije je očito opet ničim utemeljena. Kao što rekoh, sve se radi po potrebi…ne iz nekog hira “da se bude moderan”.
Živio.
Ne moraš me citirati dok ne savladaš materiju. Ti ako nešto ne želiš da naučiš, to svakako nema sa mnom dodirnih tačaka.
