Component develop tricky problem (JS)

Programiranje
82

Benefiti DRY-a su pretpostavljam jasni, ovdje bi dopunio jednu misao oko DRY-a, koja bi rekla:

“Ako nešto ne može biti po DRY-u, onda mora biti standarizirano”

Tako recimo, <DIV> tag moramo ponavljati svako malo…ali znamo da je to globalni HTML standard i nema problema s time što ponavljamo.
Isto tako, za bilo koju komponentu, koja je možda custom…ali globalno korištena…trebali bi imati neki standardni zapis, koji predstavlja njezin HTML code.
Po istoj logici, trebamo i standarne nazive metoda/propertija…kao što i DIV ima standarizirano div.innerHTML i sve ostale propertije…

Time smo znači rješili svu problematiku zbog koje inače poštujemo DRY princip, PLUS unjeli smo neke značajne prednosti.

Da, zato jer se standardi kreću pisati iz onog smjera kako bi nešto bilo najjednostavnije koristiti. A kako će iza tih metoda developer komponente riješiti da metoda obavlja svoj posao…to je njegov job i to nas ne zanima.
Jednostavnost korištenja dolazi na prvom mjestu kod kreiranja standarda.
Ali nismo standard uveli da bi pojednostavili nešto što bi inače developer možda zakomplicirao…nego zato da poznajemo jezik komponente prije nego ju vidimo. Da znamo s njom “pričati”.
Uz pretpostavku da standard zaista bude šire prihvaćen…dolazi do situacije da svi pričaju istim jezikom…i svi znaju kako će surađivati, bez proučavanja API-a …bez gubitka vremena na implementaciju…intiutivno već znamo za komponente koje prvi puta vidimo koji jezik govore…jer smo naučili sintaksu jezika.

Primjer toga ću pojasniti na metodama .show() i .close(). .
Znači, čim vidimo neku komponentu koja se po svojoj prirodi može paliti i gasiti, ne trebamo nigdje provjeravati u API-u da vidimo koje su metode za to.
(Intuitivno) već znamo da ju manipuliramo metodama show() i .close() …ALI također znamo i koji su standarni parametri koje primaju te metode.
Tako recimo znamo kako ćemo pustiti tu komponentu da se ugasi uz njenu defaultnu animaciju gašenja, ili ćemo zahtjevati trenutno gašenje pozivom:
.close({animation:false})

…također po standardu znamo kako ćemo trigirati callback nakon gašenja…itd. itd.
Sve su to stvari koje se uvijek ponavljaju…bez iznimke. I zato ih je moguće standarizirati.

Dalje, osim što poznajemo jezik komponenti i lakše komuniciramo s njima bez stalnog gledanja u API …dešava se još jedna stvar, a to je: “modularnost”

Znači, tvoja komponenta A “priča” sa nekom drugom komponentom B po poznatom standarnom jeziku. U nekom momentu shvatiš da ti nije dobra ta komponenta B koju ćeš zamjeniti sa komponentom C.
Pošto komponenta C priča isti jezik, ti nemaš potrebe ulagati nikakav dodatni napor da ubaciš komponentu C na poziciju komponente B, dok god su obje komponente istog “type-a”.
No, ako na poziciju komponente B ubaciš komponentu D, koja čak nije istog type-a, opet će postojati veliki zajednički skup metoda komponente C i komponente D, zato jer iako su su C i D različitog typea …one su obje nikle na zajedničkom root typeu tj. imaju zajedničkog “pra-pra-pra-djeda”. Znači, moraju imati nešto zajedničko…kao što recimo čovjek i pas imaju zajedničko “dva oka, dva uha”. …i zaista i čovjek i pas se dobro snalaze u nekoj istoj okolini, jer su prirodno standarizirani za tu okolinu. No ako usko specijaliziramo okolinu, onda će u jednom momentu ta okolina postati ili prečudna za čovjeka, ili prečudna za psa.

Tako i ovdje, komponenta D zbog zajedničkih korjena djeli svašta sa komponentom C. I ti kao developer, u najmanju ruku si siguran i da komponenta D ima metode .show() i .close(), ukoliko je u njenoj prirodi da se upali/ugasi. Tako da će se možda komponenta D upotpunosti uklopiti na poziciju komponente C, iako nisu istog typea. :slight_smile: A ako je pozicija baš jako specifična, onda ćeš eventualno morati raditi neku manju prilagodbu da pripašeš svoju komponentu A sa komponentom D.

Možda, možda ne. U svakom slučaju ništa manje jednostavne nego po trenutnom klasičnom načinu.
Sve što govorim ne oduzima ništa od trenutnog pristupa…samo daje jedan novi sloj na vrh. Što ne znači da bi nestali slojevi ispod, u kojima smo sad. Bili bi isti…ništa se nebi promjenilo. Tko nebi znao koristiti benefite standarda, njemu nebi ama baš ništa drugačije izgledalo. Ni trunku.

Ne…ovo nema puno veze sa tehnologijama. Kao što na početku rekoh…ovo je standard koji bi se ticao svih tehnologija koje su nikle nad javascriptom. Tako da bi se standard provodio na core javascript levelu…tako da bi ga mogle primjenjivati sve tehnologije koje su nikle nad javascriptom. Barem velika većina…moguće da nisam svjestan ako je neka tehnologija se nečim ograničila…al to je onda problem te tehnologije. Nemreš odstraniti od svog izvora :smiley:

A što se tiče server strane…pa standarizirali bi se samo inputi i outputi koje bi komponente slale/primale sa servera. Tako da bi bilo nebitno što je na backend strani…da bi se moglo po standardu komunicirati sa komponentama.

I sve bi moglo biti pokriveno kvalitetno testovima, jer ako imaš standard…lako ga automatski i kontroliraš. :slight_smile:

@krcmar , vidim ti me jedini kužiš, da li je ovaj post tebi razumljiv, ili sam opet nepovezano pretipkao misli? Popravi me slobodno ako sam što nejasan, bit ću zahvalan. :slight_smile: Pogotovo dio sa čovjekom i psom sam sumnjiiv sam sebi jesam li bio jasan…a tamo se upravo skriva najveća čarolija…a graditelj svemir mi pokazuje da upravo tako gradi nas. :smiley:

83

Ako sam dobro skontao, onda danasnji component-based JS frameworci rijesavaju ovaj problem ? Pogotovo ako uzmes nesto poput Angular Material koji ima vec neki svoj zatvoreni standard.

Medjutim onda to dovodi da problema da ne koristi svako Angular, i ne zeli svako includati cijeli Angular zbog jedne komponente.

Znaci, ako sam dobro shvatio Web Components bi mogle rijesiti problem u velikoj mjeri, a i Stencil bi pomogao sigurno.

84

Komponente se i dalje instaliraju na isti način kao i do sad…npm, ručno…kako tko voli.
NPM tu pomaže da rješi dependencyi neke komponente za skripte od kojih ovisi rad neke komponente.

No ovdje se sada pojavljuje da neka komponenta treba za rad neku drugu komponentu, ali joj je potpuno svejedno na kojim skriptama će biti pokretana ta druga komponenta. (Svejedno joj je koji je proizvođač te druge komponente, dok god ona poštuje normJS standard)

Tako da se može desiti da se instalira jedna komponenta, ali da u sustavu ne postoje potrebne komponente za rad te instalirane komponente. Tu bi pomogao normJS, tj. sama komponenta bi javila:

“Gle, za moj rad je potrebno da unutar svog normJS-a imaš registrirane komponente modal i dropdown”

85

Ili možemo koristiti dependencies key u package.json fajlu k’o i dosad?

86

Ako ti ovo nije jasno…onda ti nije uopće jasno što govorim. Ali zaista, jer stvar je u svojoj suštini poprilično jednostavna. (Komplicirano je samo razglabanje oko toga koliko bi to donjelo benefita zajednici…i bili ista prigrlila to ili ne…pa ima li onda smisla ili ne…)

…no tehnički dio je apsolutno jednostavan.
Redom:

  1. Treba prepoznati sve funkcionalnosti koje se konstano ponavljaju po web stranicama … analizirati što im je zajedničko…i te zajedničke osobine opisati nekim standardom. (To je zapravo nazahtjevniji dio…ali ne treba zagrabiti sve od jednom…lagano, metodički…uz feedback zajednice to odrađivati.)

Standard bi trebao opisati kako će izgledati HTML code koji predstavlja komponentu unutar BODY taga. To nije nikako konačan HTML code koji će kreirati komponentu…to je samo tag koji će standarno biti pisan od strane developera. Na svakoj komponenti je da na osnovu tog standarda ugradi u HTML što joj volja i drago da se materijalizira na način koji ona želi…u skladu sa svojim CSS-om.

Znači, input polje sa ikonom bi moglo po standardu izgledati ovako:
<input type='text' left-icon="plus" placeholder="add something" />

…a sada, neka komponenta će to prevesti u zapis:

<div class=“ui left icon input”>
<input type=“text” placeholder=“add something”> <i class=“plus icon”></i>
</div>

…i taj zapis nas u suštini ne zanima. Jedan proizvođač komponente će to prevesti tako…neki drugi drugačije…nas zanima da mi to možemo standarno unutar BODY-a pisati na način, kao što već rekoh:

<input type='text' left-icon="plus" placeholder="add something" />

  1. Drugo što smo standarizirali su metode komponenti.
    Recimo, komponenta koja ima unosivu dinamičnu vrijednost (input polja) …mora imati metode .getValue() i .setValue() (Standard bi to puno detaljnije opisao, ali nema smisla da idem u detalje).

I to je to, samo smo raspisali standard, ništa više. Komponente koje žele biti dio tog standarda, moraju ga ispunjavati. I to je to.
Benefiti kreću od toga što imamo poštivanje standarda…

…nitko ne prčka ni po core JSu…ni po CSS-u …niti se išta drastično mijenja. Samo je raspisan standard, kako za HTML code komponente, tako i za metode komponente.

87

Možemo, nitko te ne spriječava.
Možeš danas tipkati i statični HTML, nitko te ni u tome sprečava.

Dobar korak naprijed ne znači da ne možeš raditi po starim principima.

Inače što se tiče ovoga, u čem je caka…probam još jednom pojasniti.

Danas kada instaliraš neku komponentu koja zavisi od nekog svog modala…ona će ti putem npm i svog dependencya instalirati taj modal u tvoj projekt bez obzira što ti već koristiš neki drugi modal.
Ti naravno ne želiš dva modala u projektu…i onda imaš problem, ili ćeš odustati od te komponente…ili ćeš se namučiti sa raspetljavanjem i prilagođavanjem code-a.

Dok, uvođenjem standarda…ova komponenta koja treba modal za svoj rad…njoj je apsolutno svejedno jel to modal koji već imaš u projektu ili neki njen iz dependencya. Onda normalno da neće niti postaviti u svoj dependency modal, jer što bi te tlačila sa svojim modalom, kada će joj biti ok i tvoj modal.

No nakon što ju instaliraš, ako ona skuži da unutar tvog projekta ne postoji modal…onda će te lijepim glasom upozoriti:

“Gle, ja trebam modal da bi radila”

Stoga, ovo je korak plus…da od komponente dobijemo uistinu samo ono što ona je…a ne da nam zatrpava projekt sa pratećim stvarima (komponentama) koja ona nije u svojoj suštini.

Ovaj način nas vodi ka mogućnosti da miksamo različite frameworke bez nekog teškog loada asseta. (Ne zapravo, jer frameworci trenutno nemaju ispravnu politiku nastajanja…pa su previše zavisni od samog sebe)
Ovaj način nas tako u konačnici vodi da se niti ne stvaraju uopće frameworci…nego da se stvaraju komponente, koje ne zavise od niti jednog frameworka.

Doduše, zavise od toga standarda…i mogli bi kritičari reći:

“Aha, zahebao si se…samo si riječ framework zamjenio sa rječju standard…ali imaš istu stvar”

No nije isto…jer svatko može biti kreator unutar tog frameworka koji zovemo “standard” …dok unutar pravog frameworka nove komponente nastaju malo drugačijim principima.
Ovako, cijeli svijet postaje ta sila koja će stvarati nove komponente untuar frameworka zvanog standard, ili ti ga normJS., kako sam ga već nazvao :smiley:

A niti malo nebitna stvar da različiti proizvođači komponenti postaju međusobni rivali…konkurencija. Njihovo nadmetanje da naprave bolju i korišteniju komponentu za istu svrhu…vodi stvari ka savršenstvu.

I onda se neće više “jadnom” Googleu drowdown raspasti na dva djela…ki da su noobovi koji prvi dan rade sa HTML-om. Nažalost, situacija je danas takva…većina današnjih komponenti se raspadne kada im dio dostupnog width-a oduzme pojavka vertikalnog scrollbara …a stvari s današnjim korakom tehnologije, ima da budu precizne u piksel …ma u desetinku piksela!!!

88

Zašto misliš da ovo nije već uradjeno?

Ako misliš da imaš ideju za širenje ponoviću, ponudi rfc - evo par vezanih (očekujem da ih poznaješ kad pričaš bar o html elementima):

Moguće da ima još neki, smatram da su ovi preduslov za razumijevanje standarda HTML forme.

S kojim dijelom standardizacije input field-a se ne slažeš: input field. Ako se ne slažeš, moraš to da navedeš.

Stvarno misliš da se nešto ubacuje u standard bez detaljne analize pripadajuće zajednice i konzorcijuma (ili nas zezaš iz dosade)? :slight_smile:

Tačno tako.

Ovaj dio svaki put zbrzaš a to je (možda i) najbitniji dio u svemu. Kako misliš ovo izvesti? Rekli su ti ljudi već da bi mor’o upload-ovati svoje CSS fajlove “da bi ona skužila šta imaš a šta nemaš.”.
Vratiću se poslije na ostatak posta ali ovo je najbitniji dio cijele teme za mene da bi’ uopšte mog’o da se uključim u dalju raspravu. Jer, “ako ona ne skuži” džaba ti sva ostala pisanija na temi. Dakle, kako to ona skuži koji modal imaš odnosno da li imaš ili nemaš?

Molba:
možemo li umjesto komponenta pisati paket? Paket može biti komponenta ali obrnuto može a ne mora (tipa paket može da je sastavljen od par elemenata poput input polja) tako da predlažem da tvoj inicijalni paket (package) bude samo to jedno input polje. Čisto da izbjegnemo malo ambigous situacije kad se prepliće npm i komponenta u jednom paragrafu.
Tj. ti kad kažeš komponenta ja je momentalno poredim sa package-om koji ima samo to jedno input polje (za lakšu razradu teme).

(Im’o bi’ par pitanja i na ostatak posta, ali eto pa redom.)

p.s. Javljam se kad uzmognem.

89

[ja se povukoh iz rasprave jer sam shvatio da ništa nisam shvatio, ali svakako je pratim jer mi je zanimljiva - upravo zato jer je nisam još uvijek shvatio. Kad shvatim, samo ću se javit da vas steram u kuki i da vam velim: “Pa šta odmah niste tako rekli?!”]

90

Nije paket vec komponenta.
Pitao sam te gore, kako bi rjesio moj primjer sa npm-om? To nema veze niti s npm-om niti s samim jezikom…

To nije to. To su jednostavne komponente, koje moraju biti nezavisne i bilo koji drugi library ih moze pozvat.

Pogledaj gore sto sam napisao, primjer razvoj plugina i primjr jednostavne implementacije.

91

Tema je otišla u smjeru gdje se zapravo govori o standardizaciji postojećih sintaksi, dok sam u startu shvatio (iz uvodnog posta) da se razmišlja o “evoluciji” js-a.

92

Zato što ta standarizacija nema svoju centralnu kontrolu sprovedivosti.
Ok, imamo standarde…ali

  1. nitko ne spriječava IE da ih ne ispoštuje dobro.
  2. nitko ne spriječava usera da ima IE

I onda ja opet moram mimo tih standarada krpati rupe gdje cure…i taj problem je neizbježan. Jednostavno je ne moguće uskladiti proizvođače browsera da ostanu usklađeni. To se pokazalo problemom kada je pravila bilo manje nego danas…a kako pravila/standardi evoluiraju, tako je razmjer još i veći. I svakim danom će biti veći…zato je ovaj pristup ne održiv.
Još davno se pojavila ideja da se napravi vlastiti checkbox od fundementalnih CSS pravila i od vlastitih ikona…nebi li isti bio jednak vizualno i u Chromeu, FF-u ili IE-u.
Što će reći da su browseri kompatibilni samo na nižim fundementalnijim razinama CSS-a…sve ostalo je utopija.

Kada se postavi standard na razini zajednice, onda si siguran da ako napraviš komponentu unutar tog standarda da će se prikazivati jednako u bilo kojem browseru. Ljestvica je jednostavno pomaknuta za jedan level…i dešava se sljedeće:

  1. Browseri više nisu ti koji moraju slijediti nove standarde trošeći vlastitu energiju. (To je dio koji je energetski ne održiv)
  2. Ukoliko energijom zajednice se krenu slijediti novi standardi, izvor pogonske sila će biti mnogo veći i energetski je to onda održivo.
    Browseri su izgurali koliko su izgurali…doveli su nas na razinu da sa onim što su nam dali dalje sami možemo stvarati.
    Ne ozbiljno bi bilo očekivati da oni, ograničene produkcijske snage…nahrane potrebu zajednice koja je gladna za novim modernim stvarima. A praksa je već odavno pokazala da je zajednica vlastitim snagama otišla dobar korak naprijed,

Gledaj to ovako. Browseri su krenuli od nekih svojih fundemenata, i napravili su još davnih dana jako puno. Stvorili su doslovno nove fundamente: HTML/CSS/JS

Sada će zajednica koristeći te fundamente stvoriti nove fundamente. Neće browseri više sa svojim fundamentima raditi na fundamentima nekoliko levela iznad.

To je hijerarhija i usložavanje…poprilično prirodna stvar.
Recimo, ljudsko biće je fundament koji je nastao na milijon usložavanja ispod sebe samoga.
I sada kada treba krenuti na mars …neće se ti niži fundamenti organizirati i dogovarati da pohode tamo…ljudi su proizvod koji je dobio dovoljno samostalnosti da se organizira i da pohodi na mars. Ili će se taj pohod prenesti na još jedan fundament iznad nas…pa će roboti ići na mars.

No ako roboti dođu na mars…tko je zapravo osvojio mars?
Roboti koji su stigli tamo?
Ljudi koji su organizacijom uspjeli dokučiti mars pomoću robota?
Ljudske stanice koje su organizaijom pomoću bića…pa pomoću robota dokučile mars?
Voda je dokučila mars koja je preduvijet živog bića?
…itd…itd.

Otišao sam malo…ali poanta je bitna:
U nekim momentima, novi layer koji je izgrađen na svojim nižim layerima…dobiva svoju smislenu ulogu.

Ako ti nisi primjetio da ovaj layer koji čini zajednica je već davno daleko moćniji od layera kojeg štrikaju browseri i koji više namaju šanse da isprate sve potrebe…onda si u krivom smjeru gledao. :wink:

S kojim točno djelom se ne slažem:
Što se ovo crveni: https://caniuse.com/#search=input%20date
Browseri ne mogu ispratiti niti najobičniji datepicker…a što je sa kominacijama “date from-to” itd…
A milijon toga se nisu još niti dotakli…
Naravno da je njima problem otvarati nova poglavlja i slijediti trend…jer kao što gore rekoh, postaje nemoguće da ostanu usklađeni, gotovo pa i u teoriji ne moguće, a u praksi sigurno.

93

Sve je evolucija. Ne moraš mijenjati postojeće da bi evoluirao.
Nije se puno promjenila “prva iskra” života, a evolurala je u sav život koji opažamo danas oko sebe. Layeri se jednostavno usložavaju i čine nove smislene layere…itd…itd.

Tako je i sa programskim jezicima…od asemblera pa na dalje.
Ne znači da i danas nemamo na razini procesora asembler koji odrađuje svoj dio posla.
To što ga ne vidimo…svejedno ga trigiramo sa vrha sa nekakvim PHP-om ili C#-om ili JS-om. Sve putuje kroz strukturu od vrha do dna…do samog izvora.

94

Pa vrlo jednostavno.
NormJS će ipak imati jednu svoju skripticu…mali mozak napisan u jednostavnom javascriptu bez dependencya.

Taj mozak će imati nekoliko zadataka:

  • registery, koji će povezivati komponente. Registery će omogućiti developeru da registrira komponente koje ima. Neke će biti “ovorenog tipa” …to znači da će sve komponente imati pristup tim komponentama.
    To je otprilike kao kada bi svim aplikacijma na mobitelu dopustili da koriste galeriju slika.
    U ovom slučaju će najjednostavnije biti dopustitii svim komponentama da koriste komponente poput dropdowna…i sl.

  • Putem registerya će se i dodjeljivati permissioni komponentama za korištenje drugih komponenta.
    Tako recimo ako imaš komponentu za slanje emaila…ne želiš da se neka druga komponenta bez tvog znanja se zakači na email_sender komponentu i da spama okolo. Tako da će na developeru biti odluka kojoj komponenti će dati permission da koristi takve škakljive komponente.
    Kakve sve komponente će se u tom svijetu izgraditi…to nitko ne može znati. :smiley:

  • detektirati će ako ne postoji potrebna komponenta za rad neke druge komponente. Jer jedno od standarada će upravo biti da komponenta mora definirati komponent-dependency.

  • trigirat će određene init metode komponentama na onload stranice, koje će svaka komponenta morati imati po zadanom standardu. (Jedno od toga je prevod standariziranog HTML-a komponente u HTML code koji će ju materijalizirati)

Znači, normJS je ipak skriptica koja će pokrenuti sve na onload.
Ali easy job za napraviti…ništa strašno…niti veliko.

P.S. CSS je gotovo nebitan. Postojat će i normCSS, no on riješava jedan drugi problem…mada slična problematika.
Ovo s komponentama… CSS će biti definiran uz komponente koje imaju svoj vizual . Tu sa CSS-om je sve isto kao sad. Uzmes…prilagodis…tjeraj dalje.
No komponente koje koriste druge komponente…će onda vući i njihov vizual po defaultu. (Točno onaj koji je nastao gornjom prilagodbom…znači točno kakav treba bit)… a opet će se i to moći prilagoditi po želji dodatno…što jedino neće imati smisla tjerati dva dizajna na stranici :slight_smile:

95

Otisao si predaleko…
Registry? Permisioni?
Moje shvacanje je stalo na standardiziranom interfaceu, za standardizirane komponente.
Ti si sad otisao u 5 dimenziju.

Ma ne slusaj bozooua, otisao je predaleko. Dobar mu je ovaj dio sa komponentom koja se moze pozvati i tako ostvariti nativni izgled ili nativno ponasanje. A ovo ostalo mi je malo previse.

96

Ako je do standardizacije postojećih JS komponenti i metoda, to se lako riješi jednim libraryem sa interfaceom i polimorfnim klasama, gdje “normaliziraš” metode nad znanim framewor cima i lako dodaješ nove koji izlaze. Korisnik može library povlačiti sa cdn-a ili skinuti lokalno, i svakako ga može proširiti. Ali kako velim, tu se radi o standardizaciji, i tu nema veze sa stvaranjem komponenti koje bi odmah bile upotrebljive po principima koje su navedeni u uvodnim postovima…

97

Hehe, to skroz prirodno dolazi samo po sebi.
Zamisli da stavljas aplikaciju na mobitel gdje ona zbog standarda zna kako ce pristupiti tvojim SMS porukama, slanju poruka, tvojim slikama, kreiranju poziva…itd …a da ti ne možeš ograničiti što od toga će smjeti raditi?

Ovo upravo pokazuje koliki potencijal se oslobađa kada komponente propričaju zajedničkim jezikom.

A i dalje nije nista komplicirano…nije 2% kompleksnosti npm-a recimo (ne u koristenju, nego sto npm rjesava u pozadini)… fakat je jednostavna ideja.
A moras imati registery…jer upravo putem njega dodajes komponente. Recimo bacas stari dropdown van…i uzimas neki drugi. Tu zamjenu radiš jedino u registeryu, gdje normJS-u na taj način kažeš: “ovo nam je sada dropdown”. A sav ostali code zbog standariziranog HTMLa i JS metoda…se ne mora dirati.
Također onda možeš putem registera jednoj komponenti reći da radi s jednim modalom, a nekoj drugoj da radi s drugim…ako bi baš nastala potreba da rade sa različitim modal-ima.

98

ajde skrati malo pricu. ljudi se gube po ovoj temi. Svedi stvar na sto jednostavnije objasnjenje i sto manju implementaciju za sada.
Ja bi se trenutno drzao samo teorije, bez ulazenja u samu implementaciju. normJS mozes radit tek kad uspijes ljudima objasnit o cemu se radi u jednom twittu…

99

To si u pravu, ali postavljeno je pitanje…da detaljnije pojasnim taj dio oko povezivanja komponenti.

…na koje sam odgovarao.

100

Pa upravo taj pseudo kod koji si postavio postaviš u apstraktnu prototype klasu u npm paketu i importom paketa imaš definicije. Prototyping klasa radi baš to, zadaješ neku vrstu interface-a koji child klase poštuju.
Prototype, constructor, prototype chain.
(Pazi, ja se ne bavim pretjerano JS-om, ali ovo je klasični inheritance klasa.)

@bozoou Ne zezaj. Moje pitanje je bilo konkretno, trebalo je biti shvaćeno. Mislim da si se sapleo u tački 3 (i da se nekim čudom uspiješ konsolidovati sa ostalim tačkama). Dakle

Znaš način koji je nepoznat stotinama hiljada inžinjera ili je plan imati req/res trigger prema vlastitom serveru?
Pitanje je bilo, evo treći put, kako će detektovati sšta moja stranica ima a šta nema? Kako ćeš znati koji su sve objekti aktivni u mom kodu i koji im je state? Jedino ako parsuješ sve skripte sa trenutne stranice pa ti super kompjuter izvrti sve moguće flow kombinacije iz koda da bi na kraju dobio neki true/false (simplifikovano). Da ni ne računamo da (vjerovatno) za većinu bi mor’o posjedovati autentikaciju u radu sa AJAX-om na mojoj stranici (i.e. AJAX request sa CSRF-om čiji rezultat se koristi u ostatku JS koda na stranici).
Nažalost, ne objašnjavaš već se uplićeš k’o pile u kučine.

Da ja odradim gradjansku dužnost dok nije otišlo predaleko:

101

Nemoj me hebat. xd.
Nisam samo skužio jel ti to gore još uvijek rješavaš problem exportanja tablice u excel (xd) , ili tražiš način da indirektno kažeš: “Nemam pojma o čemu se ovdje radi.”

Znam način koji je nepoznat stotinama hiljada inžinjera :smiley: …detektovat će tako što ćeš joj ti reći što imaš što nemaš. xd. Tajna ti je upravo otkrivena, hehe.