Ili da objasnim zahjev na primjeru:
Imaš neku funkciju u skripti koja izgleda ovako:
(Znači sljedeća funkcij ima razno raznog mesa…to je samo simbolički prikaz da je tu puno svega…)
function someFunkcion(x,y,z, ...n){
var nesto1 = nekaAkcija1(x,y);
var nesto2 = nekaAkcija2(x,y);
var nesto3 = nekaAkcija3(x,y);
var nesto4 = nekaAkcija4(x,y);
var nesto5 = nekaAkcija5(x,y);
var nesto6 = nekaAkcija6(x,y);
var nesto7 = nekaAkcija7(x,y);
//..itd
}
I sada poželiš ubaciti konfirmaciju prije nego se izvršava akcija: “nekaAkcija5”, bogme najjednostavniji način ubacivanja konfirmacije je sljedeće:
function someFunkcion(x,y,z, ...n){
var nesto1 = nekaAkcija1(x,y);
var nesto2 = nekaAkcija2(x,y);
var nesto3 = nekaAkcija3(x,y);
var nesto4 = nekaAkcija4(x,y);
if(!confirm("Sigurno želiš nastaviti?"))return;
var nesto5 = nekaAkcija5(x,y);
var nesto6 = nekaAkcija6(x,y);
var nesto7 = nekaAkcija7(x,y);
//..itd
}
…znači bez ikakvog preslagivanja ostatka funkcije u nekakav callback parametar, želimo funkciju presjeći sa confirm metodom. Eto, to je zahtjev.
Ne kužim opasku, u tom osmom primjeru se također koristi callback da se korisnika preusmjeri na tu callback akciju nakon što potvrdi konfirmaciju.
Tim pristupom ne možeš ugraditi konfirmaciju kao što sam naveo u svom zadnjem gore postu.
Ne kažem ja sada da je to nešto strašno loše…nije. Ali da ga hebeš, ne može biti elegantnije nego da presječeš neku funkciju gdje god i da tamo injektaš mali code konfirmacije. Bez potrebe da ostatak funkcije kopiraš u callback parametar itd.
A možeš imati varijantu da nekada i želiš raditi konfirmaciju, a nekada ne želiš. Onda u toj varijanti sa callback-om moraš dodatno petljati da posložiš code kada imaš takav slučaj…
…kako god, radio sam i ja tako nekada. Ali ovo je sigurno bolje.
Ali tema i nije o tome da ustvrđujemo koje je bolje…nego, dali netko naslućuje kako se može to izvesti na način kako sam to izveo.
A zašto bi ostatak code-a čekao korisnika dok on odabere Aprove ili Cancel?
Ostatak ide dalje…a po user odabiru se trigira callback koji je zakačen na taj odabir. Ili je to tu nekako drugačije rješeno?
Sad kad se sjetim da je @belmin pisao o mogućnostima da se asinkronim djelovima codea zada da se ponašaju sinkrono i da ih ostatak codea čeka…bogme ovo možda i ima šanse da tako funkcionira. Al zasad nisam dobio dojam da se o tome radi.
Mada je to možda još jedna opcija da se rješi zahtjev iz uvoda. Da li bi moglo i tako…tesko mi reći, nisam se još igrao sa time da asinkrone dijelove setupiram da budu sinkroni.
Ako si ovo u pravu da swal tako radi…opet ostaje jednako visiti u zraku što se to nalazi untar Swal.fire da omogući takvo ponašanje da izvršavanje code-a čeka dok user ne izvrši akciju aprove ili cancel.
Bum probao baš…iskreno sumnjam da tako radi. Barem ne vidim razlog zašto si ti odjednom zaključio da tako radi.
Može se čuditi 5 godina (očekujući kvazi-providjenje) a sa druge strane može se pročitati i kod. Pa šta bude brže.
if (!custom_confirm(obj)) {
return;
}
Blok ovaj ovde očekuje vrijednost koju može interpretirati k’o boolean.
Tvoje je da mu to omogućiš u custom_confirm funkciji - no matter what, it should return bool.
Ako ti nije problem, jel bi mogao istipkati komad code-a koji bi zahtjevao user reakciju, a koji bi blokirao main thread, stavio ga da čeka dok user ne odreagira?
Naravno, ako je to neki simple kratak code…nemoj se dat tlačit
Ja, kao što rekoh…nisam radio još sa tim varijantama čekanja/nečekanja. Znam samo da asinkrono ide ajax request, image loadinzi, setTimout …i takve forice. Ali nemam na pameti kako bi mogao definirati da takvi pozivi budu sinkroni, tj. da ostatk code-a čeka da se izvrše.
Sjećam se da si jednom negdje spomenuo da se i to može…tad sam prvi puta čuo da i to postoji, hehe.
A unutar ove teme mi palo na pamet da bi i sa takvom opcijom možda mogao rješiti custom_confirm, da se čeka njegovo resolvanje.
Generalno da, ali da se user pričeka da nešto aprova ili odbije, ne vidim neki problem?
Pa i nativni confirm() je blocking code i neće se ništa izvršavati dok se ne zatvori. Isto kao i svaki nativni alert.
Mislim stvarno da za konfirmaciju odluke, blokiranje codea ne može unesti nikakvu štetu.
Neću reći da nisi u pravu, ali nisam iskreno ništa probavao. Di bi došao da idem za svakim po forumima i analziram što je on negdje testirao i klikao…i koje file-ove moram downloadati da bi to isto testirao.
Ako si već imao funkcionalan primjer, mogao si mi linkat radnu verziju u nekakav jsFiddle file i probao bi.
Onaj primjer 8 što se da kliknuti na swal stranici (što si linkao), ništa ne dokazuje!
Prvo sam htio reći da developer vjerovatno zna kakvu mehaniku ima u pozadini, pa prema potrebi zna jel smije ili ne blokirati thread…
Ali vidiš, tu si u pravu…jerbo ako se prave nekakve komponente za koje se nezna u kakvoj okolini će raditi, tj. tko će ih sve koristiti…onda je blokiranje threada svakako nepoželjno
