JS Tricky request for confirmation

A sada bi mogao malo ped-erski reći:

“A lako je sa tim modernim alatima” .

Hehe, šalim se. Velika vrlina je pratiti tehnologiju, naravno.

Svejedno, imaš što za mozgati ako hoćeš riješiti isti problem bez tog await sistema. Kada se to uopće pojavilo? To je dio ECMA6 , 7 ili čega? Ja uopće zaboravim svaki puta u kojem ecma razdoblju smo, haha.

Nego da još jednom konkretiziram problem koji sam postavio.
Doduše, već sam dosta razjasnio, ali i meni je naknadno palo na pamet što mi je bilo najbitnije kada sam taj problem htio rješiti.

Bilo mi je najbitnije da neku funkciju mogu samo napola (ili bilo gdje već želim) …presjeći sa snippetom code-a koji će izvršavati konfirmaciju.
Nije mi sada bilo bitno hoće li ta konfirmacija biti 20, 50 ili 100 karaktera…ali bilo mi je bitno da je mogu elegantno samo copy-paste na željenu poziciju i da ništa drugo ne moram rekonstruirati. A pristup sa callback-ovima bi uvijek tražio barem neku minimalnu rekonstrukciju…zato sam to htio izbjeći za slučaj konfirmacije što je relativno čest slučaj…pa sam ga zato u pozivu htio maksimalno pojednostaviti.

Drugi uvjet mi je bio da u tom snippetu code-a koji ću kopirati, da u njemu nemam varijabilnih stvari.
Naravno, jedna varijabilna stvar mora biti…a to je poruka koja će se prikazati korisniku kod konfirmacije. No osim te poruke nisam htio da imam još neki dio snippeta koji moram prilagođavati situaciji gdje taj snippet postavljam.

Taj drugi uvjet sam duugo imao samo djelomično ispunjen…uvijek se nešto malo motalo oko nogu u tom snippetu, ali ajd, bilo je prihvatljivo i dalje praktičnije od rekonsturiranja i prebacivanja code-a u callback.

Eto, pojašnjavam taj dio jer je ok da se shvati koja mi je bila namjera i nit vodilja kada sam krenuo sa prvom varijantom te svoje konfirm metode. Znači htio sam pure “copy-paste” snippeta…i da radi. A što se u pozadini poziva…što Bog da, haha.

Nego, sukladno ovom što napisah u prošlom postu oko želje da se izbjegne ikakvo rekonsturiranje postojećeg code-a kod ubacivanja konfirm dialoga…ovaj tvoj pristup isto to malo krši. Jer se funkcija u koju se ubacuje mora prepraviti u async funkciju ukoliko to slučajno u startu nije bila.

Nije strašno, ali je detalj…
Isto tako, teško mi je ovako napamet reći što se još remeti nakon što funkciju prepravim u async funkciju… ako unutra imam nekakve ajax pozive ili što već…

Pretpostavljam da taj async utječe samo na one funkcije unutar koje su deklarirane sa “await” ?

Evo kako je tekao tok misli prilikom traganja za custom confirm dialogom…

Izrada custom confirm dialoga, ideja no.1

Znači, prva ideja je bila sljedeća:

  • ajde da napravim u tom mom confirmation dialogu callback koji će pozivati onu funkciju unutar koje je konfirmacija ugnježdena.
  • tako da rekurzivno pozovem istu funkciju, a samo u prvom prolazu ću paliti konfirmaciju
  • u tom prvom prolazu ću uvijek abortati funkciju
  • ako korisnik klikne TRUE, onda će putem callbacka funkcija pozvati sama sebe ponovno, a za drugi prolaz ću nariktati triger da se konfirmacija ne upali, što će spriječiti i abortanje funkcije.
  • taj triger bi zakačio na jedan od parametara koji prima funkcija i stvar bi radila

Ima tu puno mana:

  1. Spomenuti prvi uvjet je bio ispunjen…snippet je zaista trebalo samo copy-paste
  2. Drugi uvjet nije baš bio idealan. u svakom snippetu je trebalo preimenovati funkciju koja se nalazi u callbacku i zadati joj iste one parametre koje je primila parent funkcija. To i nije tako strašan job, ali ipak minus.

Puno gora greška je bila u tome što se triger koji pazi da se konfirmacija ne upali u drugom prolazu, morao kačiti na jedan od parametara parent funkcije. A to već povlači za sobom moguće probleme…

Code:

function someParentFunkcion(a,b,c,f){

	//some code before confirmation

	if(!f.confirmed) {dialog({msg: "Želiš li nastaviti", onTrue:function(){f.confirmed=true,  someParentFunkcion(a,b,c,f)}}); return;}

	//some code after confirmation
}

Svejedno, ovo mi je radilo više nego zadovoljavajuće dugi niz godina :slight_smile: :slight_smile:
Nastavak slijedi…

Jbg.

Neki nikad neće[mo] naučiti.
Čovjek se muči sa špagetama 12 godina i ja k’o budala izadjem u susret da ga upoznam sa standardizacijom i progresom a on vrijedja. Jbg, neki nikad ne naučimo.
Nadjem mu rješenje za 5 minuta, a kako ne koristim JS pretjerano, frontend ga napomene na async await i riješeno. Ali ne, on k’o june

Tako da ako se nekome čisto mozga kako bi se to moglo rješiti sa malo sirovijim JS-om, nek mozga…

Pa izmozgano je, mislim se. Zar ne uočavaš?!

Ko ga ■■■■ (disclaimer: nikom konkretno/stilska figura/uzrečica, nije psovka), drugi put nek sam traži rješenje.

@belmin
Bravo, znaš znanje. Gledam i ja da se uključim u JS ali stidljivo to ide što se tiče posvećenog vremena. :expressionless:

Izrada custom confirm dialoga, ideja no.2

Ideja dva je bila nastavno na prvu ideju…htio sam se riješiti trigera “f.confirmed”, koji je bio najveći uljez.
Palo mi je na pamet da izdvojim svoj dialog koji je u službi konfirmacije u zasebnu funkciju koja je dobila ime “dialogConfirm”. Taj dialogConfirm je bio naseljen od dialoga iz prvog primjera i zapravo se ništa značajno unutra nije dešavalo, osim što je dialogConfirm unutar sebe naizmjenično dizao i spuštao jedan flag u stanja true/false …i ta stanja su predstavljala ono što je u prvom primjeru bilo:

situacija 1 (prvi prolaz): f.confirmed = false
situacija 2 (drugi prolaz): f.confirmed = true;

Znači, funkcija dialogConfirm je izgledala:

var DialogConfirmGlobalState = {confirmedStates:{}}
function dialogConfirm(uniqProcessName, poruka, onTrue){

	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;
}

I ta funkcija možda izgleda malo smušeno, ali nebitno…jer je čučala u pozadini.
Ono što se ugrađivalo je sada izgledalo nešto jednostavnije nego u primjeru 1. Više nam nije trebao “f.confirmed”:

function someParentFunkcion(a,b,c,f){

	//some code before confirmation

	if(!dialogConfirm("someUniqNameAboutAction", "Želiš li nastaviti?", function(){someParentFunkcion(a,b,c,f)})) return;

	//some code after confirmation
}

E sad, ovo je izbacilo najgoreg uljeza…ali i dalje je kod svake konfirmacije trebalo pretipkavati parent funkciju unutar snippeta.
To je zaista simple job…ali eto…to je ostalo kao uljez…koji je konačno u zadnjem koraku izbačen…

Šta je ovo?
Izmijenili ste 2% mog koda i folirate se? lol
Ali se svelo na to da je upotrijebljeno za izvedbu samog rješenja, zar ne.

@bozoou Nemoj očekivati od mene da ti pišem baš kod.
Vidi ja tebi kad pomažem, prvenstveno to radim zbog sebe jer na taj način učim druge stvari.
Ti si mi u drugom planu pri tome. Mislim, da se ne lažemo. I naravno, u mogućnosti sam od dopuštenog mi vremena.

Ako ti ne odgovara idejno rješenje i smjer razmišljanja te ako ne namjeravaš to koristiti, da se ne trudim i ne prenosim iskustvo i znanje (ma kol’ko ga bilo).

Izrada custom confirm dialoga, ideja no.3

I zadnji korak koji me jučer razveselio, tarannn:

function someParentFunkcion(a,b,c,f){

	//some code before confirmation

	if(!dialogConfirm("Želiš li nastaviti?", arguments) return;

	//some code after confirmation
}

arguments - to je tih devet viška karaktera koje spomenuh u uvodu. Doduše, tih devet karaktera su uvijek isti kod svake konfirmacije, tako da je u potpunosti ispunjen uvjet 1 koji kaže da se u snipetu ništa ne mora mijenjati osim poruke konfirmacije.

A uvjet dva je također ispunjen, jer se snippet ubaci gdje god treba bez ikakve potrebne rekonstrukcije funkcije unutar koje se umeće.

No što je točno arguments?
arguments je nativna varijabla koja nosi informacije o funkciji unutar koje se nalazi.

Znači:
arguments.callee -> to je funkcija unutar koje se arguments pojavljuje
arguments.length -> broj parametara koji su prosljeđeni u funkciju
arguments[0] -> prvi parametar funkcije
arguments[1] -> drugi parametar funkcije
// itd.

Sada kada imamo arguments, prosljedimo ga u dialogCofirm i unutra možemo sve odraditi sa njime.
Također je ranije i “uniqProcessName” bio suvišan zato jer jedinstveno ime procesa možemo dobiti na način:
someParentFunkcion.toString()
ili u slučaju argumentsa:
arguments.callee.toString();

Tarann…to je to.

Ima još jedna cakica koju je vrijedno znati, a bila je potrebna za resolvati ovo sa arguments.

Radi se o tome, kako pozvati neku funkciju sa određenim parametrima, gdje nam nije unaprijed poznato koliko tih parametara ima. Kao što je ovdje slučaj…arguments se može pojaviti sa nula, jednim ili deset parametara.
Seljački bi bilo:

if(params.length==0) someFunkc();
else if(params.length==1) someFunkc(params[0]);
else if(params.length==2) someFunkc(params[0], params[1]);
else if(params.length==3) someFunkc(params[0], params[1], params[2]);
// seljački, ali i to bi držalo vodu..samo iteriramo do jedno 20 parametara xd.

Dobar način za napraviti isto je:
someFunkc.apply(this,params || []);

Sramotiš se pred svakim tko barem malo razumije problematiku. Da ti slikovito dočaram što se desilo:

Ja pitam: “Kako se ruši zgrada?”
Ti mi pokažeš zgradu i kažeš: “Vidi, srušit će se.”
Ja kažem: “Bogme sama od sebe neće.”
Ti kažeš: “Ako se zaletiš muhom u zgradu, srušit će se.”
Ja kažem: “Bogme neće ni tad.”
Ti kažeš: “Kako znaš ako nisi probao?”
Ja te probam uvjeriti da probaš sam i da se uvjeriš da muha neće srušiti zgradu… (Belmin se još tu usuglasi samnom)
Ti mi kažeš: “Tko ti je kriv što nisi dovoljno stručan da zaletiš muhu u zgradu…treba znanja za to!”
Ok, ja da ti pokažem … zaletim muhu u zgradu i pokažem ti da se zgrada od toga srušiti neće!
Dođe @belmin, uzme tonu dinamita i razori tvoju zgradu u milijun komada. Ja i belmin se veselimo kako je rasturio zgradu, a ti dođeš i kažeš:

“Što je ovo? Vaš dinamit je samo 2% veličine moje zgrade, a folirate se da ste je vi srušili? lol
Ali se svelo na to da je moja zgrada upotrebljena za izvedbu rješenja rušenja, zar ne”

Hahaha…e ako sada ne shvatiš što se desilo, nema ti spasa :smiley: :smiley:
Zaista nisam mogao preciznije i slikovitije dočarati što se desilo.

Razočaran sam.
Moji postovi na ovoj temi su zaslužili analogiju u domenu evolucije makar. :disappointed:

No, obojica smo rekli šta smo imali.
Žiri se sad može povući na donošenje procjene. :blush:

Tvoji postovi bi zaslužili jedan sasvim drugačiji tretman da nisi upao u temu sa stavom pametnjakovića, koji do tog statusa pokušava doći bahatim diskreditiranjem sugovornika, bez osnova da ga uistinu diskreditira.

Ali nadam se da si iz gornjeg slikovitog primjera skužio da je sam dialog u cijeloj priči nebitan. Još sam i spomenuo u uvodu:

…i ti sve što si napravio, kopirao si u pohvalnih 5 minuta tamo neki dialog i očekivao da će se konfirmacija, na način kako je zadano, desiti sama od sebe?
Nakon što se nije desila i nakon što je belmin na “tvom” dialogu pokazao kako treba upregnuti konfirmaciju, ti zaključuješ da si ti odradio 98% posla?

Srry, ali takvo razmišljanje ti zaista ne daje prostora da vrijeđaš tuđa razmišljanja.

Vidi, ti se nisi udostojio da pogledaš kod koji sam ti dao i da obrazložiš što (ako) ne radi.
Drugo ne umiješ da procčitaš običnu funkciju da bi utvrdio da sam joj proslijedio objekt a ne string + sam naveo u komentarima iza linija sšta bi trebalo zvati.
Definitivno je Belmin uradio rješenje sa await async ali sam ti i prije toga rek’o da moraš vratiti true/false ako tamo negdje očekuješ if (!this_need_to_be_true_or_false()) {};.
Dao sam ti sasvim dovoljno koda da se zanimaš i čitaš dokumentaciju koja će te navesti na rješenje.
Pisati kod znaš i sam tako da ja to ne moram za tebe, ne? Prosto sam te uputio kud da kreneš a sad ako nemaš osjećaj da je bilo tako, onda ništa. :slightly_smiling_face:

1 Like

Naravno, znamo svi.

Elem, za goste koji su se kasnije uključili - post br. 1:

Znači, jedna linija koda, koristeći naredbu confirm , nam omogućava tu opciju.
Jedino je mali problemčić što nemamo nikakvu mogućnost utjecaja na izgled tog confirmation dialoga.

I sada sam ja htio napraviti isto to, ali sa svojim custom dialogom. Ali isto da bude jedna linija koda.

Nothing to see here, move along.

Da, sa svojim custom dialogom…to ne znači da je poanta u dialogu, nego u načinu manipuliranja sa njime da se dobije željeno ponašanje :slight_smile:
Logično, zato jer sa nativnim dialogom/alertom nema mogućnosti nikakve manipulacije.

No to ne znači da je tajna u custom dialogu, nego upravo u toj manipulaciji. A custom dialog, može biti moj, tvoj, Swalov, Perin…nebitno.

Da smo proveli ovu temu ugodnom tonu, sada bi imao odličan primjer da shvatiš nešto i o normJS-u.
Recimo, ovdje imamo dvije komponente:
komponenta 1: custom_confirmation
komponenta 2: custom_dialog

Komponenta custom_confirmation barata sa custom_dialogom da postigne željeno ponašanje konfirmacije.

Kada bi se sve te komponente držale standarda po kojem se zna u kojem obliku custom_dialog prima ulazne parametre, tada bi komponenti custom_confirmation bilo totalno nebitno jel se na poziciji dialoga pojavi moj dialog, tvoj, Perin ili Swalov. Naravno, dok svi ti dialozi poštuju spomenuti standard za svoje ulazne parametre.

U tako jednom sinkorniziranom sistemu, samo bi se u registratoru komponenti nekog projekta promjenilo da ulogu dialoga više ne vrši Perin dialog, nego Ivin dialog …i ništa se nebi raspalo. Komponenta custom_confirmation bi i dalje jednako uspješno baratala sa dialogom kojega bi ispod sebe koristila da ispuni svoj zadatak.

Ne znam da li ćeš se potruditi sada ovo shvatiti, ali mislim da je ovo lijep primjer za @belmin -a, jer sam uvjeren da će on biti jedna od prvih osoba na ovom forumu koja će shvatiti koja je to moć standarizacije modernih komponenti, i što bi zapravo bio normJS. A vrlo vjerovatno i prva osoba.

Ti prvi iskačeš iz ovakvog principa jer još od backnone-a, knockoutjs-a, pa na ovamo kroz angular, react i vue vrlo standardizovan parametar funkcije da prima objekt ili callable k’o argument. I još naovamo sa Promise-ima da prima resolve reject. A tome ima 5-10 godina (ne)praćenja procesa upgrade-a i samog koncepta jezika.

Svi iskaču iz toga principa, kada tog principa još nema.
Moraju se točno propisati strukture i nazivi parametara koje će određene koponente primati, koje su već dobro poznate da postoje.

Ima tu razno raznih caka koje moraju biti propisane…ali naravno, komponente se ne smiju ograničiti da dalje evoluiraju.

Mora biti i precizno definirano i fleksibilno. Pravi izazov.

I ti baš nisi primijetio da su svi fw-ci koncipirani da prihvataju objekte i da se radi sa objektima? Ne zvoni, a? Mislim ponavaljam se, ali ti si neko ko neznanje ne upotpunjava čitanjem dokumentacije (po sopstvenom priznanju), tipa čudiš se prostim primjerima zašto rade ili zašto ne rade a objašnjenje je tek 1 klik daleko. Tako da, o čemu da pričamo ovde?

1 Like

Pa naravno da će parametri biti u objektima…time i dalje nisu poznati točni nazivi određenih atributa, niti strukture za određene atribute koji imaju više nodova itd.

Opet pričaš gluposti i opet s visoka. Sorkač.

Kao što rekoh, nisam očekivao da ćeš potruditi nešto skužiti vezano za normJS. Nema veze…ovo ionako nije tema o normJS. Ovdje smo rušili zgrade, kako tko. Sve muhe su uglavnom preživjele :smiley: :smiley:

Kako ko. Neko je tražio (a neko i naš’o) rjesšenje za problem koji te mučio godinama.

Prob’o sam se ujesti za jezik prste al’ da pitam:

Ovo znači da ako ja imam funkciju

let sumTwoNumbers = (x, y) => {
  return x + y;
};

normJS evandjeliste se zalažu pred vaskolikim auditorijumom da to izgleda

let sumTwoNumbers = (a, b) => {
  return a + b;
};

Da bi moj kod više odgovar’o tebi nego meni?

:laughing:

Edit, a ne hvališ se kako te usmjeravam da koristiš arrow functions kod za razliku od onog arhaičnog s početka teme? :stuck_out_tongue:
Opet, ja to zarad vježbanja sebe prvenstveno. :wink:

1 Like

Nazivi atributa objekta nisi isto što i nazivi attributa funkcije. Iz konteksta se moglo skužiti na koje mislim, ti si barem sugerirao da će parametri biti najčešće objekti.

Primjeti razliku u sljedećem primjeru:

dialog({head:'Naslov',content:'Some content', onTrue:function(){
	
}}); 

// Ili:

dialog({head:'Naslov',body:'Some content', onAprove:function(){
	
}});

Sigurno me nećeš motivirati bez da elaboriraš koje su prednosti tog načina?

Dok ne uvidim prednosti, smtaram da je sve stvar navike. A već godinama su mi svi snippeti u editoru podešeni da izbacuju code na klasičan način, tako da nemam potrebe niti da mijenjam naviku niti da se zamaram time. A sa snipetima tipkam jednako brzo, bio code nešto duži ili kraći. A što se tiče optimizacije, sve ionako prođe kroz webpack compiler, pa dođe i sa te strane na isto…

Koje točno prednosti ću ostvariti sa arrow funkcijama? Budi slobodan razuvjeriti me? Ne negiram da je moguće da nešto bitno propuštam, pitanje je što?