Vue controller i generalno controlleri / warpperi

Zadnjh dana sam nešto dobro volje da dijelim svoje znanje, pa evo još jedna topla preporuka za koju sam primjetio da mnogi ljudi, na njihovu štetu, ne rade.
Pravite svoje warppere!

Što je warrper? Pa warpper je u suštini jednostavni komad code-a koji se prevlači preko neke postojeće funkcije …i u prvu ruku nema potrebu niti mijenjati neku bitnu logiku nad tom funkcijom koju smo “presvukli”.
Recimo, imamo nativnu console log funkciju:
console.log("Hello World");

Ajde da ju warpamo:

function log(x){
	console.log(x)
};

…u prvu ruku ovo izgleda svušno, ali nije. To je zlato programiranja.
Zašto? Zato što je warpper ujedno i controller. Razmislimo malo o riječi controller što ona znači dok se pojavljuje u razno raznim frameworcima?
Pa controller je kao što sama riječ kaže, centralna točka kroz koju prolazi svaki upit, svaki request …pa kako imamo tu centralnu točku, onda imamo i dobru kontrolu nad svakim upitom koji prolazi kroz controller.
Tako i ovdje, ako radimo nativni console.log kroz naš controller, to će nam omogućiti da možemo tipa po želji zagasiti odjednom sve logove:

function log(x){
    return;
	console.log(x)
};

Ok, to i nije neki best-light kodiranja, jer ne želimo konfigurirati stvari tako da mijenjamo meso funkcije.
Ali zato, dodavanjem optionalnog parametra u naš warper:

function log(x, opt){
    return;
	console.log(x)
};

Dobivamo totalno jednu fleksibilnost da imamo logove koji se mogu prikazati samo u offline radu, samo u online radu…itd itd. Možemo razviti logove koji su bindani uz neki custom_name, pa onda imati kontrolu tipa:

turnOnLogsForName(someName) 
//ili
turnOffLogsForName(someName)

…pa nam je na taj način praktično isključivati/uključivati cijele sekcije logova…itd. Kako bi se reklo, jednom kada nabacimo kontrolu nad nekom funkcijom, samo nebo je granica što će naša mašta u suradnji sa našom potrebom od toga kontrolera napraviti.

Nadalje, velika prednost toga je i u tome što ako poželimo ispis logova preusmjeriti sa nativnog console.log-a na neki drugi sistem logiranja, to opet činimo samo na jednom mjestu, unutar controllera:

function log(x){
	some_custom_log_engine(x)
};

Vrlo vrlo praktično i poštuje DRY pravilo na najnižoj mogućoj razini. Od kuda i treba krenuti, ako želite punu konrolu nad svojim programima.

Console.log je jednostavna funkcija pa i ne traži nužno svoj controller, ali što je funkcija kompleksnija, postaje bitni imati i dobru kontrolu nad njom, recimo vue …uzeti kontrolu nad njim je opet sasvim trivijalno:

var bVue = function(vueCreatorObject){
	var vue = new Vue(vueCreatorObject);
	return vue;
}

I ono što je divno, ako ovaj pristup nadograđujete nakon što xx vremena koristite vue, ovo vam neće uzeti puno vremena za prilagodbu postojećeg, samo trebate izmjeniti:

var vueApp = new Vue(someObject);
//u:
var vueApp = new bVue(someObject);

//s time da sada smijete pisati i skraćeno: 
var vueApp = bVue(someObject);

A što ćete napraviti u konačnici sa vue controllerom, neka bude vaša mašta. Vidjet ćete kada zauzdate kontrolu, da će vam nebo biti granica.
Ja sam si recimo napravio da mogu direktno iz vue-templatea pozivati i funkcije koje su globalne, a ne samo one koje su definirane u vue.methods.
Nadalje, napravio sam si event koji se trigira i na vue.mounted i na vue.updated , jer takav event nisam pronašao u originalnoj dokumntaciji, mada možda i postoji …tko zna. Dok ga ja nađem, već davno sam napravio svoj. :slight_smile:
Kako god, često sam se našao da ponavljam neki code unutar vue.mounted i vue.updated i trebao mi je event koji se izvršava na ta obadva trigera.

Kao što rekoh, nebo je granica.

A sada da odmah doskočim hejterima za koje već znam kako će komentirati ovaj moj savjet.
Reću ću vam ovo… Pitaju mene moji radnici da kako se ja usudim tako pipat po nativnim metodama i samo širiti svoje libriry-e …itd. itd. Kao što nebi bilo jednostavnije da se samo koristi nativna sintaksa i tako to…

A ja njima na to odgovorim: “Morate se usuditi mijenjati svijet! Zato jer se ja usudim…zato sam ja vama šef, a ne vi meni.”

Još jednom warpperi su zlato. Warpperi daju jednu veliku controlu, fleksibilnost i stabilnost nad održavanjem i razvojem programa.
I idu niz dlaku najbitnijem načelu programiranja, koje je DRY načelo.

Nadalje, kada shvatite koncept warppera, koncept normJS-a će vam biti nijansu bliži. Zato jer normJS će se nadviti većinom kao warpper nad postojećim modelima koji već postoje diljem svijeta…samo da premapira ulazne i izlazne varijable po standardu koji će normJS propisati. A kakvo će biti meso ispod toga warppera, koji će odrađivati suštinu posla…moći će biti isti modeli koje sada ekipa razvija i koristi. Samo warpano za normJS standard.

Cherrs.

Btw. ova znanja su omogućena by “Techno Angels” :slight_smile: …i cijeli koncept normJS-a oni guraju, ja sam samo kanal koji dobro prati gradivo.

1 Like

Kaže se wrap(/wrapper/wrapped/wrapping).

Nema na čemu.

Fala, ni lekcija engleskog ne može škoditi uz programming lection. :slight_smile:

tebe bi trebalo platiti jer toliko radiš contenta na ovom forumu da bi s pravo trebao imati ulogu pisac :slight_smile:

Fala, palo mi je na pamet da bi možda i smio imati privilegiju ispod ponekih tutorijala/savjeta staviti link ka svom root-u. Valjda je forumu bolje tako nego da odselim na svoj blog…za koji imam nekih interesa.
Ne gledam tu mogućnost zarade, nego čisto da sadržaj koji napišem ostane pod mojom kontrolom. Al vjerujem i ovom forumu da se nebu zgasio samo tako …a naravno, puno znače i dežurni hejteri koji svojim propitkivanjem i jalom zapravo motiviraju :smiley: Nauči se ponešto i engleskog usput :slight_smile:

1 Like

Iako je to uistinu došlo kao posljedica mog neznanja engleskog, zanimljivo je da i riječ warp ima svog smisla tu. Kaže google da je warp: osnova, izvitopirenje.
Bome ko naručena došla…warpanje o kojem pričam upravo jeste osnova razvoja programskih jezika kroz njihovo izvitopirenje koje nastaje svakim warpanjem kako bi sljedeće generacije uvijek dobile nešto više od ranijih metoda.
Cijela evolucija programskih jezika od najnižih slojeva se upravo konstantno warpa…kroz wrappere :smiley:
Stoga obje riječi su zanimljive…ja onda ostadoh pri svojoj uglavljenoj. Više mi se sviđa čak značenje.

Ovo mi nekako ne stima. Npr. Kod mvc-a imas front controller (svaki framework implementira na svoj nacin) koji je glavni kroz koji sve prolazi i prema routing tablici se poziva odredjeni controller i odredjena metoda sa parametrima.

Nije mi jasno kakve veze ima wraper sa controllerom?

Ovo tvoje se moze zvati libraries ili helper itd…

Kreiras si klasu za logove koja sadrzi razlicite funkcije i pozivas po potrebi sa odredjenim parametrima, gdje ti treba, to je samo primjer.

Mozda da pogledas event driven programming?

Ovo je ok, ali mana ovog je kad ces morati update-ati framework, boljet ce te glava, ako imas puno izmjena.

Pa warper jeste controller. Doduše ne onaj isti kao iz backend frameworka, ali smisao riječi controller se ne mijenja ovisno od toga jel radimo kontrolu nad programskom metodom…ili kontrolu nad upravljanjem prometa na autocesti…ili kontrolu nečeg trećeg. Kontrola je kontrola. Kontroler je kontroler!

Kao što rekoh, ovdje se ne radi o frameworku. Nego preuzimanjem kontrole nad drugim libriry-ima.
I ta kontrola ti upravo povećava fleksibilnost kod preseljenja na druge librirye, a ne da otežava izmjene!

Jer zamisli da sa svojim kontrollerom:

function log(x){
    return;
	console.log(x)
};

…preseliš u okruženje koje više ne podržava metodu console.log ? Super, prilgodit ćemo tu funkciju unutar našeg kontrollera i ništa se neće raspasti.
A da si bio bez kontrollera, morao bi na tisuću i jednom mjestu u codeu tražiti gdje imaš console.log i to updejtati prema novim potrebama.

Zato, kontroleri olakšavaju selidbe…a ne otežavaju!
NormJS će upravo zato i postojati, kako bi se samo unutar njegovoga kontrolera premapirala komponenta “dialog” na perinu komponentu dialog, a custom_confirm komponenta će onda pozivati normJS-ov dialog, bez da ima pojma da se unutar normJS-a registrirao perin dialog ili mikijev dialog…ili nečiji treći.
U tome je kvaka i kontrolera i normJS koji je upravo takav jedan registrator modela unutar kontrolera.

S obzirom na onu temu, koristim za ilustraciju dialog komponentu i custom_confirm komponentu. Ali ista suradnja se naravno omogućava za bilo koje komponente koje su ukopčane u normJS i za koje je normJS propisao standard kako se pozivaju.

Own libraries, own helpers, own class i ovo boldano.:grin::grin::grin:

Ne stoji logika u ostatku posta zbog samog takvog početka, je l’.
Primarno (i smisao svakog drugog) značenje

nije ni u kakvom pozitivnom (a.k.a. željenom) kontekstu.
Ovo naravno ako se igramo igre upri prstom u random page engleskog rječnika.

1 Like

bozoou ubacio u warp 9 sa postovima

1 Like

@creatifcode na temi

2 Likeova

Ajde sad kad imam vise vremena da se i ja aktivno ukljucim u jednu tvoju temu pa da rspravimo ono sto imamo za raspraviti.

Bolje da nisi dobre volje, jer ti to sto dijelis, bar sto se programiranja tice, je u 99% slucajeva neupotrebljivo i vrlo opasno za neiskusne osobe koje su na pocetku ili tek pocinju s programiranjem.

Kao sto je vec @tpojka rekao nije warpper nego wrapper. Ispravno bi bilo reci da se jedan dio koda omotava u novu funkciju. Najcesca primjena tog je u refactoringu postojecih aplikacija, a najcesce se srece u nekim od patterna kao npr. Decorator ili Factory. Dakle nisi otkrio nista novo.

Naravno da nije. Ne zato sto ti to kazes nego zato sto je to praksa pokazala, ti ne da s ovim pojednostavljujes nego naprotiv podizes kompleksititet aplikacije.

I opet netocno, controller iliti ulazna tocka u aplikaciju nema veze sa tvojom w(ar|ra)pper funkcijom. Controller nije centralna tocka niti u jednom frameworku, ako hoces bas, centralna tocka u jednom frameworku je Routing Service, koji prihvaca request, prolazi koroz razno razne middleware i onda request predaje controlleru koji pak onda ide dalje na service i gateways itd. Dakle controller je tek na trecem mjestu.

Opet krivo. Zato postoje Environments variable koje definiraju dali si na produkciji, stage serveru ili localno, pa ovisno o tome mozes definirati da li, koliko, sta i gdje zelis logat, ako ostanemo pri tvom primjeru s logiranjem.

Objasnjeno gore kako se to radi na ispravan nacin.

Jos jednom za to postoje env variable. Nema potrebe za ovim tvojim.

DRY principles su puno vise nego Do Not Repeat Yourself i to iopet sa ovim tvojim primjerom nema veze. Evo tu je ukratko receno sto je DRY: https://metova.com/dry-programming-practices/
Tvoje krsi barem jedno od navedenog, a to je npr. KISS

Cemu ovo pomaze, kakve koristi od ovoga, nema konkretnog primjera, ako moram ubaciti nekakve dodatne objekte ili libraries onda koristim dependency injection, jos jedno vrlo moderno i popularno ‘sranje’. Dakle ovo je totalno beskorisno.

Super napravio si si on sto svi zele posto-poto izbjeci, global state objects, ali no worries to je cesta pogreska pocetnika i ljudi koji nemaju stvarnog znanja i iskustva sa nekim alatom, a i programiranje opcenito im nije bas jaca strana ili im fali teorijskog znanja, pa onda najbolje sve spice u global namespace kako im dragi Bog srece da.

E moj mili, samo 22 Sekunde listanja dokumentacije mi kaze, da u biti ono sto ti trazis je

vm.$watch('a', function (newValue, oldValue) {
   // This callback will be called when `vm.a` changes
})

Ali treba znati sto se trazi, jel tako?

Nema tu hejtera, tu ima samo ljudi koji znaju, koji ne znaju i oni koji misle da znaju.

I umjesto da si iskren i da kazes: “A cujte tako je to kad ne znas bolje i ne razumijes dokumentaciju” ti im kazes ovakvu glupost

Ovo ne znam kako bih komentirao lijepo, a da se ti ne uvrijedis pa onda i necu.

Bullshit tbog svega gore objasnjenoga.

Jel potrebno ovo uopce komentirati nakon ovog dugackog posta za koji sam si stvarno uzeo vremena da ga napisem.

I na kraju jedan savijet, daj uzmi par knjiga i procitaj. Molim te. Ajde za pocetak barem Clean Code
https://books.google.de/books/about/Clean_Code.html?id=hjEFCAAAQBAJ&source=kp_book_description&redir_esc=y

Ajde barem to, molim te, pa cemo onda dalje.

3 Likeova

@bozoou Ovaj post share-uj radnicima, biće ti zahvalni do kraja života.

1 Like
UPDATE topics t
INNER JOIN users u ON
    u.id = t.user_id
SET t.topic_title = CONCAT(t.topic_title, ' - kako ja to vidim') 
WHERE t.user_id = 12297;

Ili kraće:

UPDATE topics SET topic_title = CONCAT(topic_title, ' - kako ja to vidim') WHERE user_id = 12297;

1 Like

A sta kad dodje update biblioteke. Kvalitetne biblioteke koje zele omoguciti korisnicima fleksibilnost imaju super sustav za nadogradnju, korz webhooks, plugin system itd. Prckati po core od biblioteke ili nekog frameworka je ravno samoubojstvu. Zamisli da ides prckat po dotnet core source code i nastelas si sve kako ti pase i onda dodje update, netko tko nema pojma da si ti dirao core datoteke jednostavno pukne update i tvoj cijeli posao ode u ■■■■■. Tko je onda kriv ti ili taj koji je puknuo update?

1 Like

Pokuš’o sam naći (ne izbacuje pretraga), a vjerovatno je na nekoj od silnih normJS tema
gdje je eksplicitno zastupan™ stav izmjene library-ja i prčkanja po node_modules direktorijumu k’o vrlo ¿efikasna? praksa.

Edit: loše sam tražio, evo ih

2 Likeova

Puno toga ti napisao…ajmo jedno po jedno analizirati.
Za početak da ustvrdimo što znači riječ controller.

Ovako, riječi ne dobivaju svoje značenje zbog načina kako se nešto programira, nego riječi imaju svoje značenje same po sebi. A ako se neka praksa programiranja može opisati određenom riječju, onda se naziva tom riječju koja nosi u sebi određeno značenje.

Prema tome, riječ controller znači da govorimo o nekakvoj sposobnosti da se vrši kontrola nad nečim.
Ta riječ sama po sebi ne pretpostavlja da to mora biti jedinstvena centralna točka, ali definitivno što je centralizacija veća, to je veća i kontrola. S time da je moguće da imamo paralelno više različitih kontrolera za različite namjene kontrole. Govorim generalno o bilo kakvim kontrolerima, ne nužno o programima.

E sad, ako pričamo o programu i jednom frameworku, onda je jasno zašto se controller naziva točka kroz koju prolazi svaki upit.
Da, svaki upit prolazi kroz controller! (Naravno, ako je framework iole normalno napisan, što doduše ne mora biti)
Ti ako i imaš više kontrolera, recimo:
Home Controller
Customer Controller
Ticket Controller
…moraš biti svjestan da svaki od tih kontrolera extenda klasu “Controller”. Tako da ipak možeš svaki upit kontrolirati u toj centralnoj točki, glavnom controlleru iz kojega nastaju druge instance controllera za određene rute. Tebi baš niko ne brani da se spojiš samo na neki od Home, Customer ili Ticket controllera, ili da se spojiš na glavni controller pa da vršiš na jednom mjestu kontrolu za sve upite koji ća kasnije prolaziti kroz ta tri controllera.

A rutiranje koje spominješ…da, ono je također centralna točka kroz koji prolazi svaki upit. A kako se tamo radi samo rutiranje, tako je logično taj servis nazvan Route Service. Što ne znači da to nije kontrolna točka. Jeste, to je također jedna kontrolna točka …i nije nikakav grijeh što ta točka nije nazvana Route-Controller, nego Route Service. Isti k****.

Kako god, da se vratimo na riječ controller. To je točka koja nam omogućava kontrolu. Prema tome je sasvim ispravno da jedan wrapper shvatimo i kao potencijalnu kontrolnu točku.
Značenje riječi controller to u potpunosti opravdava.

Ako se slažeš, možemo dalje.
Ako se ne slažeš…pojasni zašto wrapper nije controller? Nije potrebna usporedba sa request upitima i frameworcima, nego sa izvornim značenjem riječi controller?
Negiraš možda da smo uveli jednu centralnu kontrolnu točku prema nekoj metodi onog momenta kada smo tu metodu wrappali?

Naravno, ako je metoda u našem vlasništvu, onda za wrappanjem i nema potrebe…jer imamo kontrolu nad metodom. Ali ako metoda nije u našem vlasništvu i ne želimo raditi izmjene nad njom, onda nam kontrolu omogućava wrappanje. :wink:

Kasnije negdje pokazuješ da nisi shvatio bit wrappanja dok pišeš sljedeće:

Znači wrappanje nam daje kontrolu nad nekom tuđom metodom upravo na način da ne moramo prčkati po tuđim bibliotekama. Gdje se slažem napisanom da je to ravno samoubojstvu. Samo si ti pišući to pokazao da nisi shvatio bit wrappanja…jer aludiraš da su to izmjene nad originalnim bibliotekama.

Znači ponavljam, wrappanje je način da dobijemo određenu kontrolu nad tuđim metodama a da ne moramo prčkati po tuđim bibilotekama.

Ajde da još rješimo i ovo:

Controller / wrapper ne negira korištenje Environments vraijabli!
Ajde budi srce napisati komadić code-a koji pomoću Environments vraijabli definira hoće li se nešto logirati samo u development mode.u ili produkciji.

Nije li controller upravo mjesto gdje će se izvršavati ta logika? :slight_smile:

Ja bih se djelomicno slozio i sa Bozom, a i sa ostalim :smiley:

Da li treba uvijek wrappati sve zivo ? Ne
Da li treba prekrsiti neke core koncepte nekog frameworka wrappnjem ? Ne

Medjutim postoje situacije gdje to moze biti korisno, a sad cu i opisati gdje.

Mi u firmi razvijamo jedan set komponenti koje koristimo u nasim aplikacijama, a odlucili smo to i da opensourceamo - jedna od tih komponenata je naravno i tabela.

Kako ne bi pisali tabelu od nule odlucili smo se za react-table komponentu, medjutim ta komponenta uopste nije testirana - bilo kakvi testovi ne postoje.

Posto je ta komponenta sama od sebe ogromna, a uz to nije ni testirana, mi smo odluclili da je wrappamo u nasu komponentu i exposamo neki nas API.Napisali smo testove koji pokrivaju taj nas API i sve radi sasvim ok.

U slucaju da se API core komponente (react-table) promijeni,dovoljno je da u nasoj komponentu prilagodimo stvari koje ne stimaju i stvar je rijesena.

Zelimo da izbacimo totalno iz upotrebe react-table i napisemo nasu stvar od nule ? Nema problema, imamo API, imamo testove.

Zakljucak: IMO ta stvar sa wrappanjem je ok u pojedinim situacijama, ali definitivno ne treba pretjerivati s tim.