JS Tricky request for confirmation

Programiranje
41

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.

42

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:

43

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.

44

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
45

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.

46

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.

47

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.

48

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.

49

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
50

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:

51

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
52

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(){
	
}});
53

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?

54

Svi problemi koji te @bozoou muce su riješeni u praksi i to kvalitetno, samo treba pronaći u literaturi (knjige, tutoriali i sl.) .

Preporuka za knjige:

55

Ništa mene ne muči, ja rasturam :smiley: :smiley:
Od mene se traži da napišem knjigu i da svoje develop patterne prenesem. Ali polako, ne žurim sa time…

56

Pa vidi, definitivno nešto što se treba pojaviti na početku se nikad neće ne bi trebalo zvati tail ili footer.

A što se tiče standardizacije naziva, veliki već postavljaju standard (Google, MS, FB) i ostali. Prateći njihovu nomenklaturu raznih naziva od klasa, propertija, metoda pa tako kroz razne jezike manje problema se ima poslije.

Da bi razumio više od pola modernog koda ti nije dovoljan motiv?
Opet si bio 1 klik daleko.
Evo prvi link:

Svidjelo ti se / ne svidjelo, u tom tekstu možeš pronaći zašto koristiti rest parameter ili spread syntax što ti može pospješiti (par postova iznad) prikazani kod.

Tako da

Knjige, braćo moja, knjige, a ne zvona i praporce.

2 Likeova
57

Ne bi baš rekao.
Design patterni su stari 40 godina, mvc je star isto tu negdje, prije 40 godina je bila 79 god,.

Uzet ćemo početak 1949.

To je još 30 godina, dakle u 70 (teorije, razvoja i sl.) godina, hrpe enterprise software na kojem su se utvrdila pravila , best practice, istraživanja, testiranja, eksperimentiranja i to od hrpe računalnih znanstvenika i sad će neki mali tamo izmišljati svoju toplu vodu,

Da se auto razvijao ovih 100 god, kao IT , sad bi imali leteće automobile brzine 500 - 800 km na sat sa skladištenjem energije u obliku el. energije koja bi se dobivala od obnovljivih izvora u letu sa 80-90 % iskorištenosti.

I sad će se naći neki klinac reći taj leteći auto ne valja, meni više odgovara današnji načina automobila.

Sam si rekao da se promjene moraju događati , to je točno, ali znaš od koga od stručnih ljudi koji imaju iza sebe napisane hrpe enterprise code-a, software-a za simulacije, compilera i sl.

58

To ne mijenja činjenicu da ću ja pisati knjigu/e, koje će morati svladati ljudi koji će se prijavljivati na pozicije koje će biti uvjetovane tim knjigama.

Ti si međuostalim također bio kod mene na razgovoru na posao i od tada samo kenjaš. A pred razgovor si bio: “Božo je majstor, božo rasutra”. Heh…koji si ti lik ispao u mojim očima, to je strašno…

59

Imaš određenog znanja i ideje, ali nekad mi se čini da to znanje nije prisutno kad pišeš neke odgovore i pokušavaš progurati svoje ideje za probleme koji su već riješeni.
To je bila neformalna kava, a ti nazovi to kako hočeš, nebitno.

U tvojim očima mogu biti lik kakav god i to je tvoj problem , ne moj, ali ako imam neki problem , ideje, prvo potražim na google da vidim da li već nešto slično postoji, kako su to ljudi riješili, da li mi se to rješenje sviđa ili ne. Ili ću onda to rješenje koristiti ili neću ili ću tražiti dalje.

Čitam literaturu i ne izmišljam toplu vodu, ako hočeš doći do te razine da češ biti jedan od onih koji će mijenjati pravila, morat češ imati znanja do te razine da moraš naučiti još hrpu stvari, a to nečeš u 2 života, ne zato jer ne bi bio sposoban, nego su ta dva života premalo koliko bi morao naučiti.

A ljudi koji imaju velikog znanja, oni su talenti kojima puno manje vremena treba za neke stvari nego tebi ili meni za naučiti.

Poštujem svakog čovjeka, nikog ne vrijeđam u životu, ali šarlatani, lopovi, prevaranti, muljatori , lopovi i sl. nemaju što tražiti kod mene.

Branio si jednog dotičnog gospodina, koji nezna osnove, stranica iz 92’, a u nazivu firme mu stoji i djelatnost programiranje.

To sve govori, a tražio čovjeka za 3000 kn sa širokim znanjem, od c/c++, .net-a, jave, nekoliko baza, unix, linux itd…

Sprdačina žešća.

60

Upotreba rekurzivne funkcije u praksi.
Note: Ne zaboravi da poslije prvog loop-a obilježiš true.

1 Like