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 
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.
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
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
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. 
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? 
Ja bih se djelomicno slozio i sa Bozom, a i sa ostalim
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.
Nisam ni sumnjao da stojiš na strani svjetla / istine.
Dobro ste iskusili koje prednosti vam daje wrappanje.
Tako je. Wrappanje drastično olakšava održavanje, a ne da ga otežava kako su neki pisali iznad.
…također, ovo ti je glavni koncept normJS-a Samo preštekavanje komponenti po potrebi…
U ničem se ne treba pretjerivati. Sve treba raditi po potrebi, a onda ne može biti pretjerivanje.
Neće se raditi wrappanje nečega zato jer tako negdje piše…nego zato što u datom momentu nastane potreba za wrappanjem. A taj moment se jako lijepo vidi / osjeti, kada se oko nečega pojavljuje ponavaljajući code…koji krši DRY rule…vrijeme je da te ponavljajuće patterne negdje smjestimo.
Tada je to vjerovatno prilika da se taj code smjesti u wrapper funkcije oko koje se počeo ponavljati taj code. Tada slobodno može nastati wrapper, jer je tada zatrebao.
To samo poneki ovdje kucaju code koji ima ne treba. Ako je baba Vanga rekla da mora ići tako…oni ponavljaju to ko glavom kroz zid. Kad ih pitam zašto tako radite? Muk …“zato jer su drugi rekli da je to dobro…”
Oni koji tako razmišljaju, logično će završiti u pretjerivanju…jer neće činiti djela iz vlastite potrebe,nego zato što misle da treba nešto raditi. Takvi ako zabriju da je wrappanje potrebno, wrappat će sve živo i neživo
Bemu miša, nebumo valjda wrappali if statement, haha. Ili for petlju…
Dobro for petlju budemo wrappali, barem ja jesam.
Evo @creatifcode -u se već diže kosa na glavi kako sam se to udostojio. Pa da mu odgovorim prije nego pita.
Zato jer je postojala potreba. Da nije postojala potreba, nebi naknadno došao wrapper for petlje u nativni code, koji se naziva forEach.
Nadalje, wrapp je u ovakvim slučajevima bolji i od nativnog codea, zato jer novi nativni code vrlo često nije podržan u svim browserima, dok wrapper je bez problema, ako se dobro zada.
.
.
.
@belmin -e, jedino mi nije jasna jedna stvar:
Kako pobogu djelomično, kada ne znam da sam na išta drugo ukazao poantu nego na to isto što si i ti?
I kako se pobogu onda djelomično slažeš sa ostalima, kada su svu svoju energiju uložili da popljuvaju tu moju poantu koju si ti sada ponovio?
Ok, razumijem…želiš biti pristojan prema njima. To je isto ok. Doduše, ja ne volim hraniti laži i pustiti ljude u ne znanju.
Je l’ to ustvari forked repository git submodule?
Mozda bih znao kad bih znao znacenje tog termina 
Forked? repository? Ili submodule? Ili razumiješ pojedine riječi, ali cijeli termin zajedno te zbunjuje?
Teško je pogoditi koja riječ ti fali.
Vjerovatno forked? …pošto su ove dvije učestalije?
Pogleda’ opet.
Ustvari imate taj UI napunjen paketima/komponentama.
Jedna od njih je izmijenjena react-table komponenta ili tačnije komponenta kojoj je osnova react-table.
Ustaljena je to praksa - pa pola Laravel-a je Symfony.
Nego sam ja mislio (dok nisam pogled’o strukturu repo-a) da ste napravili:
- fork react-table
- napravili izmjene/dodatke koje ste naumili
- a zatim uključili taj (svoj novi, baziran na react-table{-u}) repo u neki postojeći veći sistem (npr. Ampel-UI [opet, dok nisam pogled’o strukturu]) putem
git submodule
Ostavlja mogućnost nekom drugom da koristi, recimo Webtrekk/react-table, naravno u zavisnosti od dependencies-a. Ali shvataš šta 'oću reći.
Tako da bi jedino preostalo da koristiš core Webtrekk/Ampel-UI i po potrebi dodaješ submodule (Webtrekk/react-table npr).