Component develop tricky problem (JS)

Programiranje
22

Nije ti neka analogija…ti si to sada usporedio na način:
- vizitor ivinog sajta je posjetioc sajta
- korisnik mobitela je posjetioc svog androida
…i onda si povezao te dvije osobe po toj analogiji. Ali to je sasvim nepotrebna analogija…mogao si ih tako povezati po dva uha i dva oka. Znači povezao si nebitno.
Ono što je ključno u analogiji tih osoba je sljedeće:

Naša tražena osoba:

  1. Instalirava komponentu koja mu je potrebna, funkcionalnost koju je on osobno odlučio uključiti.
  2. Ne želi trošiti previše vremena da tu komponentu stavi tamo gdje je stavlja. (u sustav kojega je on administrator)
  3. Odlučuje koje dozvole može imati ta komponenta koju ugrađuje. (Ta odluka je naravno na njemu, pošto je on administrator svog sustava)

Prema tome, u slučaju iz prvog posta …tražena osoba je developer, jer je:
-on korisnik komponente koju ugrađuje. On je birao funkcionalnost koju želi dobiti iz komponente koju instalirava.
-on je želi instalirati na što jednostavniji način. (Primjer s mobitelom pokazuje koliko to može biti jednostavno…a ta jednostavnost je svakako dobrodošla)
-on odlučuje što će dozvoliti toj komponenti da radi unutar njegovog sustava, jer je on vlasnik/admin sustava.

Prema tome, po ispravnoj analogiji se ne trebamo niti taknuti vizitora Ivinog sajta.
A analogija sa mobitelom je tu da se pokaže u kojem smjeru sistem može ići…i da bude hint traženom rješenju problema.

E, tu se već nazire rješenje problema. Ali …nije to nikakvo ograničenje…ispravno postavljeno…to tek otvara puni potencijal…

Evo još jedan hint…
HTML nisu striktna pravila?
Nije li lijepo što svaki developer zna da može koristiti:
HTML_element.innerHTML
HTML_element.outerHTML
…

…kako bi to izgledalo kada bi unutar jednog browsera morao zvati div.innerHTML, a unutar drugoga div.html, a unutar trećega div.text …itd

I onda još da nemamo tri major browsera, nego da ih ima stotinjak?? I da im broj raste svakim danom?
Koliko bi to onda imalo smisla? Nikoliko! Tu smo točno danas sa komponentama. Radi se o apsolutno istoj stvari.

Naravno, praksa je pokazala da se neki standard nije uspio zadržati niti unutar tri glavna browsera: Chrome, Firefox i IE. …pa već imamo varijacije na temu nebi li pokrpali različitost njihovog ponašanja.
I od njihovih “sitnih” razlika već boli glava …koliko onda zapravo boli glava od nedosljednosti komponenti?
Iskreno, nismo ni svjesni te boli…jer toliko boli da niti ne shvaćamo da boli. Pod normalno nam je da boli…pa se niti ne suprostavljamo. Evo, tona mog teksta…tek da shvatimo da postoji problem. A koji je zapravo očit da ne može biti očitiji!

To ti je kao da si rekao:

“Ne možemo izumiti telefon jer ne znamo što će točno ljudi govoriti koji bi njime komunicirali”

Što se mene tiče, problem je 100% jasno lociran i sasvim je nebitno što će koja komponenta raditi…rješenje problema je osigurati njihovo međusobno bezbrižno usložavanje.

23

Što se tiče ovoga, standardi sami po sebi nisu problem. Nema tog aspekta civilizacije gdje na kraju nismo došli do nekih standarada…kada se ukazalo da ih trebamo.
Unatoč ovoj šaljivoj anegdoti:

…no poanta jeste u tome, treba moći ostaviti prostora standardima da evoluiraju. Ako je taj mehanizham ispravan onda se standard neće raspasti.
Ne možemo naravno očekivati da ćemo postaviti neki standard u 15. stoljeću i da će isti biti praktičan u 20.tom.

Konkretno problematika kod browsera, developer nije imao kontrolu nad odabirom standarda.
Standarde je postavljao “w3school” (ili tko već…nebitno) …a na browserima je bilo da ih ispoštuju.
Svaki browser naravno ima svoju politiku…svoje developere…i jednostavno je ne moguće da će svatko od njih odraditi zadatak na istoj razini. Znači, doći će do razlika i nekompatibilnosti prije ili kasnije…kao što je došlo.

Postoji tu i neka negativna povratna petlja što se tiče prirodne regulacije toga…npr. browseri koji nisu poštivali dovoljno standarde, zajednica ih je jednostavno odbacila kao nebitne…pa su propali.
No kako se pokazalo, IE koliko god kaskao za standardima…uspio se gurati među prva tri.
Uglavnom… nema tu mehanizma da se oni usklade i zato niti nisu prešli na išta kompleksnije od onoga što jesu. (Iako u jednu ruku, zadivljuje koliko su zapravo dobro usklađeni)
Realno, pola komponenti koje nastaju u krugu zajednice…trebale bi biti po defaultu ponuđene od strane browsera. …no browseri su najdalje došli sa nekakvim date-pickerima …i tu su sada već ohoho nekompatibilni.
A da ne govorimo da još od običnog checkbox-a nisu imali usklađeni vizualni prikaz, pa je već tada zajednica osjetila sljedeće:

“Ako su browseri barem kompatibilni po najfundementalnijem (Javascript i osnovni HTML) …onda mi možemo napraviti komponentu koja će se prikazivati identično unutar svakog browsera”

…i tako se već odavno i najobičniji checkbox-evi štrikaju na način “Pouzdaj se use i svoje kljuse” …ne bi li rezultat bio gotovo isti unutar bilo kojeg browsera.

I u tom momentu, koristeći najfundementalnije …developeri hvataju dobru poziciju da budu poprilično neovisni o daljnjem razvoju browsera i njihovoj nekompatibilnosti za složenije stvari.

I tu se otvara jedna nova pozicija na kojoj se može izgraditi standard koji:

  • neće biti ovisan o politici različitih browsera
  • neće tako biti ovisan o korisnikovom opredjeljenju na browser s kojim surfa internetom.
  • na koji nitko neće biti prisiljen da ga poštuje
  • ali oni koji će ga poštivati, bit će im višestruko vraćeno…jer će zajahati jedan snažan val unutar kojega će se komponente razumjeti i moći bezbrižno usložavati
  • val bi naravno postao tek snažan kada bi ideja bila dobro formulirana i prigrljena od zajednice …jer tek u tom momentu ono “bačeno” vrijeme koje spominjem u prvom postu će postati produktivno vrijeme na korist cijele zajednice koja prigrli taj standard.
    Tu pak postoji jedna pozitivna povratna petlja…što će reći, kako standard bude prihvaćeniji…više zajednice će htjeti biti dio istoga. Što dovodi do eksponencijalnog rasta…ili ti mogućnosti da se standard otrgne i usisa sve ostale…postane dominantan.

Što je dobra karakteristika za standarde…bilo bi suviše loše da im negativna povratna petlja otežava da zavladaju.

I dalje ostaje problematika na koji način uvesti standarde…ali valjda se sada kuži u kojem smjeru ciljam.
Vratimo se na mobitel…postoji standard kako će mobilna aplikacija komunicirati sa galerijom slika, fotoaparatorm…itd.
…i onda aplikacije koje instaliramo ne moraju izmišljati vlastitu vodu oko toga…dovoljno je da dobiju permission da koriste fotoaparat, dalje je na njima što će raditi sa fotićem. Glavno je da znaju metode koje su standarizirane za kameru i to je to…mogu se usložavati.

24

Čitao nekoliko puta, i ne vidim problem (ili sam problem nisam dobro shvatio).
Kako bih ja riješio problem:

Hub (od kuda se preuzimaju komponente):

  • uzmi naziv komponente
  • uzmi opcije i ugradi u komponentu
  • isporuči komponentu (XML/JSON/string)

Korisnik koji ugrađuje komponentu:

  • zatraži komponentu Z
  • pošalji klase, id, vrijednosti i text za elemente koji se nalaze u komponenti i daj komponenti lokalno i ime (npr: mojaKomponenta)
  • preuzetoj komponenti (mojaKomponenta) dodaj nove funkcije po želji
  • prikaži komponentu u html-u, unutar označenih tagova (npr div id=mojaKomponenta)

Ako sam dobro shvatio problem?

25

Mislim da pokusavas rjesit problem koji zapravo ne postoji. Izgled komponenti unutar nekog browsera nije nikad bio problem, problem je funkcionalnost istih. Izgled je nemoguce pogoditi tako da udovoljava svakome, samim time browseri i ne pokusavaju to napravit. Oni znaju da ce svaka stranica prestrikat izgled onako kako oni hoce, a sve sto oni trebaju napraviti je dati osnovni okvir. Sto je komponenta jednostavnija i “gluplja” to vise prostora ostavlja developeru da ju napravi kako hoce.
To sto ti mislis da ako izgradis komponentu koja ce obavljati nekakve slozenije taskove ( bilo izgled, bilo funkcionalnost) da ces svim olaksat posao, grdo se varas. Sto je komponenta slozenija, to ju je teze modificirati, a samim time teze je s njom napravit originalni dizajn/funkcionalnost.
Ovakve stvari se rjesavaju library-ima poput react-a, gdje ti sam library omogucuje shareanje komponenti medju programerima, lagano pisanje api-a, itd. Ali sam internet time nije ogranicen Tj. oni koji ne zele radit s reactom rade s necim drugim i mirna bosna. Tjerat sve na jedan standard je glupo i ogranicavajuce.

26

Zaista ne kužim kako ne uspijevaš vidjeti problem. Čudim se iskreno. Ne tebi…nego sebi kako vidim nešto tako jednostavno a ne uspijevam objasniti drugima.
Dao sam već toliko analogija…sa HTML elementima browsera …gdje bi pukla zajednica da ima:
div.innerHTML vsdiv.html vs div.text …i sada zamisli tako za svaki property da imaš različite varijante dohvaćanja …i onda da imaš još 100 browsera koje trebaš pokriti…i da im raste brojka svaki dan…

Pa onda analogija sa mobitelima gdje se lijepo vidi koliko komponente mogu biti velike i kompleksne…ali da za zajedničku funkcionalnost moraju moći zajedno funkcionirati…

A ti u startu kažeš: “Ne moj raditi višedimenzionalne komponente…nego max jednostavne”. Time mi već pokazuješ da ne shvaćaš bit problema. Jer komponenta može biti bilo što…kao što je primjer dao, može biti kompletna instaliacija neke aplikacije koja se kači na gotov android sustav i njegove postojeće dijelove s kojima uspješno komunicira.

I s ovime pokazuješ da ne razumiješ o čemu govorim. Ja nigdje ne govorim da izgled treba zadovoljiti svakome! Ali govorim o tome da ako komponenta A koristi dropdown izbornik, onda je red da ga koristi onakvog kakvi već postoji na stranici gdje se komponenta A ugrađuje. Znači izgled dropdowna u potpunosti ovisi o developeru stranice, a ne o komponenti da ona šara kako joj se sprdne…i da stranica u konačnici liči na drlo razlitog UI-a…što je katastrofično za user-experience…za load stranice…itd…tid.

Prvo, mislim da se ne varam. Dobiti veću funkcionalnost na pladnju ne može biti loše.
Što se tiče dobivanja originalnog dizajna…tu me ti ne shvaćaš.
Ovo što zagovaram je analogno MVC-u gdje imaš razdvojen model , view i controller …ovdje u priči sa komponentama imaš razdvojen model i view. Znači, komponenta u stranicu treba donesti samo funkcionalnost koju donosi…koja sama po sebi je u potpunosti razdvojena od izgleda komponente.

Recimo Perina komponenta…onda nema nikakvog, ama baš nikakvog doticaja sa View-om. Funkcionalnost te komponente je samo da prenese poruku korisniku. Ako se ta komponenta ispravno zakači na sustav postojećih komponenti, vizualni identitet prenošenja te poruke će izgledati onako kako to već odrađuje ta stranica s drugim komponentama…a Perina komponenta će samo unesti tu funkcionalnost detektiranja i prenošenja poruke iz server responsea.
Znači, ja pričam o potpunoj razdvojenosti funkcionalnosti i elemenata koji se pojavljuju u vizualnom sučelju…i to što se kačiš na dizajn-problematiku mi samo pokazuje da ne kužiš o čemu govorim.

Iako svi polazimo od istog standarda?..i to nam je omogućilo katapult pod zvijezde? No zatim smo se malo razletili…i sad slijedi moment da se “sabere” ono što je nastalo ne bi li mogli napraviti još veći katapult.
I uvođenje standarda nikoga nebi ograničavalo…tu griješiš. Nema tu zakona ni prisile ni ograničavanja…samo napraviti smjernice …koje bi olakšale život onima koji bi radili unutar tih smjernica. Olakšalo, jer bi podiglo njihovu zajedničku sienergiju…te bi oni nadišli ostatak zajednice koji nisu radili na sienergiji.

27

Onda očito nisi shvatio ako ti ne blješti lampica da bole oči od svjetline :slight_smile:

Ako se dobro sjećam, negdje si pitao da ti nisu najbolje sjele abstraktne klase. Ovo je zapravo ideja toga, da se naprave apstrakcije modela/komponenti koje se pojavljuju i koje čine današnji web.

Recimo, zamislimo jednu apstrakciju:

“Komponenta kojoj user može postaviti proizvoljnu vrijednost i developer očitati tu vrijednost”

Odmah nam pada na pamet, pa to su INPUT polja! … koja mogu biti: text, password, number, checkbox.
…nadalje, to mogu biti dropdowni, autocomplete polja… datumpciker, timepicker …to bi mogla biti i galerija slika gdje user može raditi upload…itd.

Vidimo da ta apstraktna klasa zaista može biti svašta…zato i jeste apstrakcija nečega. Jer mi ne znamo što ona točno može biti, ali možemo napraviti apstrakciju njenog ponašanja. A ona može biti bilo što, dok ima ta svojstva unutar svoga ponašanja. Ajmo ovu apstrakciju zaista nazvati INPUT.

Ajmo sada vidjeti koje su to zajedničke metode toj INPUT klasi: (pojednostavljujem za primjer)

  1. postavi vrijednost
  2. dohvati vrijednost
    ili ti ga input.setValue() i input.getValue()

I da su stvari ispravno postavljene, svi elementi koji spadaju u tu apstrakciju INPUTa bi morali imati te dvije metode.
Tada, nekoj komponenti A koja surađuje sa komponentom B (koja je apstrakcija INPUTa), je poznato da može tražiti od komponente B sljedeće:
KomponentaB.getValue() i KomponentaB.setValue().

Sada dolazimo do toga da su stvari krivo posložene već u startu, jer kada imamo recimo input text polje …onda vrijednost dohvaćamo value = input.value, a kada imamo input checkbox polje…onda vrijednost dohvaćamo value = input.checked
Što će reći, da apstraktne klase nisu najbolje prepoznate od samog starta. No svakako je popravljivo!
Danas situacija je još teža kada imamo toliko komponenti koje spadaju pod iste apstrakcije…ali “sve govore različitim jezicima” …i naravno da onda međusobno ne mogu komunicirati bez konfiguracija (prevođenja) …mada bi bez problema komunicirale samo da se svedu na zajednički jezik. Potpuno izvedivo i čak ne traži puno truda…niti mjenjanje postojećega. Samo warpanje postojećega u standarizirane apstrakcije.

Ono što ja zagovaram je da se globalno uzduž i popreko pročešljaju web komponente i izvedu sve apstraktne klase koje trenutno postoje. (Ili barem krene od osnovnih kao što ja za svoje potrebe jesam) …recimo modal je upravo jedna od njih…itd.
Svaka komponenta koja ima .show() i .close() spada pod apstrakciju (OPENABLE class) …itd…itd.
Nadalje, da bi komponenta ispunjavala apstrakciju PROMPT, morala bi ispunjavati apstrakciju INPUT i apstrakciju OPENABLE.
Tog momenta kada se moja komponenta susretne sa nekom PROMPT komponentom, boli moju komponentu ona stvar kako taj prompt izgleda i kako je u kodu implementiran…moja komponenta zna da može u nekom momentu promptati usera sa prompt.open() …i da u nekom momentu mogu koristiti unesenu vrijednost sa metodom prompt.getValue() …i da mogu predefinirati vrijednost sa prompt.setValue().
Tako da moju komponentu boli ona stvar kakav prompt je korišten od strane developera koji ugrađuje moju komponentu…a moja komponenta će sasvim uspješno koristiti njegov prompt na njegovoj stranici…a neki drugi prompt na nekoj drugoj stranici. I na taj način će se postići da prompt uvijek izgleda originalno kakav je postavljen inicijalno od developera koji pravi stranicu. (Tako da nikakvog problemna sa izgledom oko kojeg je toliko zabrijano unutar ove teme)

I nje mi za to potreban nikakav API te prompt kompnente…dovoljno je da se slijede zajedničke apstraktne klase. …kojima bi naravno bilo dopušteno da evoluiraju i prate potrebe zajednice.
Štoviše, evolucija bi tek nahrlila svom silinom naokn što bi se komponente počele bezbrižno međusobno usložavati…onda bi nastale nove apstrakcije kakve danas ne možemo ni apstraktirati…

28

Pa rekao sam ti prije da sam te izgubio :slight_smile:
Aha, mislim da sam napokon skuzio kaj hoces reci. Ali, iskreno neznam da li je tako nesto moguce na webu. Cak i na mobitelima mislim da bi tesko islo. Stvar je u tome sto ni mobitel ( barem ne android) ni web ne koriste objekte u programerskom smislu za prikaz, vec xml za strukturu, nesto drugo za dizajnt, nesto trece za logiku, itd.
Na webu tako nesto mozes jedino ako uspijes da svi definiraju osnovne stvari na isti nacin, onda sve komponente mogu povuci osnovne postavke i iskoristiti ih.
Najblize kaj sam vidio da rjesava ovaj problem je react. Uzmes tudju komponentu koja rjesava nekakav problem, upucas svoje stilove i imas relativnu bezbolnu integraciju.
Isto brijem da ti neshvacas sto ja pokusav raci. Ti cjelo vrijeme hoces da komponenta “povuce” postojeci izgled stranice/mobitela, ali to je nemoguce ako ne postoji standard koji ce zahtjevat da svi jednako definiraju osnovne stvari. A to se nece desit, barem ne tako skoro. Jednostavno trenutne tehnologije su ogranicene svojom izedbom da bi se slozilo to sto ti hoces…

29

Konačno … postalo je frustrirajuće mumljati sam sebi u bradu :smiley: …i vidjeti se totalno neshvaćenim. Ja inače svoj princip već lagano primjenjujem u praksi…i na malim stvarima sam već osjetio koji boost daje. Ne usudim se ni pomišljati što bi to bilo da dovedem na razinu kako sam to zamislio. A osjećam totalno da ne postoji barijera…

Razmišljao sam i o tome…ali doslovice jedna apstrakcija rješava problem za ovo. Znači, sve komponente koji bi se pojavljivale unutar tog dogovorenog standarda bi morale ispunjavati tu najnižu apstrakciju…root apstrakciju.

Tipa, ugrubo…svaka komponenta bi morala imati komponent.create() …što bi bilo ekvivalent onome document.create(‘div’).
Znači, morale bi se postaviti najniže apstrakcije za dodavanje komponenti, inicializiranje istih i svašta nešto. Pa pogledaj jedan div element…sve njegove attribute i jedan span element i sve njegove attribute.
Upravo su ti attributi apstrakcija komponente HTML_element. I div i span ih moraju imati …da bi bili HTML_element.
Tako bi se i ovdje stvorio jedan set attributa koji bi morala zadovoljavati svaka komponenta da bi za početak postala komponenta tog sustava.
I onda ti je potpuno nebitno kada pozoveš komponent.create() …kojom tehnologijom je taj proces u pozadini rješen. Jel to Vue ili React ili koji vrag…
Zato sam u početku rekao …i Vue i React i Angular…sve su to tehnologije koje su izgrađene na temelju koji je javascript. I poprilično je nebitno kako te tehnologije rade unutar sebe…mogu se svesti na apstraktne klase samog javascripta.

Jedino što će developeru biti ineteres da ukrižava komponente koje su napravljene na istoj tehnologiji…čisto iz razloga da ne mora raditi load različitih tehnologija bespotrebno… …no komponentama neće nikako smetati da komuniciraju ukoliko nisu nikle na istoj tehnologiji.

Dalje kada pogledaš…to ide do tuda da kada se pojavi neki dropdown u igrici na playstationu…i taj dropdown zapravo spada u istu apstrakciju INPUTa, bez obzira što se pojavljuje na sasvim drugačijoj platformi. Kada bi se ispravno i šire poštivale apstrakcije…počela bi komunikacija i “inter-planetarno”,hehe. No to je nebitan korak za sad…prvo da web propriča zajedničkim jezikom.

Nekako mi se čini da me još nisi do kraja shvatio. Ja uopće ne pričam o izgledu kao takvom…
Vrati se na primjer sa PROMPTOM. Sada zamisli da moja komponenta obavlja neki posao sa userom…gdje ga nešto pita modalom…pa ga malo prompta, pa opet modal…pa ga prompta sa dropdownom …pa opet sa modalom…pa ga prompta sa datepickerom…pa opet modal i konačno moja komponenta završava interakciju sa korisnikom.

Kakve je veze imala moja komponenta sa izgledom modala, text inputa, dropdown-a, datepicker-a?
Nikakve!
Moja komponenta je jedino za ugradnju na stranicu posavila uvjet (dependency) developeru da mu mora dati permission da koristi te njegove komponente. I u tom koraku je ona povezana sa tim komponentama koje će koristtii za svoj rad…svoju funkcionalnost.
Stoga, moja komponenta nikako nije utjecala na izgled stranice. Ako moju komponentu ugradi Ivo, onda će “poštivati” elemente kakve već koristi Ivo …ako moju komponentu ugradi Maja, onda će “poštivati” elemente koje već koristi Maja…
U oba slučaja vizualna pojavka moje komponente će u potpunosti odgovarati vizualnom identitetu stranice na kojoj se moja komponenta “materijalizirala”. No moja komponenta nije to što se materijaliziralo…moja komponenta je funkcija koju je ona obavila u interakciji sa korisnikom…ono što se vizualno materijaliziralo i dalje u potpunosti ovisi od developera koji je upogonio moju komponentu u skladu sa svojim već ugrađenim komponentama.

30

@bozoou
Sve skupa je prakticki nemoguca misija.

Jer ima previse js library-a, frameworka i sl.

Recimo poceo sam raditi sa https://www.jqwidgets.com
Imaju sve sto mi treba + integracija za angular, react i sl.

Ako mi treba neka komponenta, a ne postoji sam je napravim.

Ono sto netko rece, react.

31

Pa o tom ti i pricam. Znaci tvoja komponenta mora “povuci” izgled stranice na koju se implementira. Ali posto html ne odredjuje izgled, vec to radi css, znaci i maja i ivo bi trebali postovati nekakav standard po kojem slazu css.
Sto se tice ostalog to se vec moze raditi, ali je problem sto ce komponenta imati svoj css za prikaz koji se moze jako razlikovati od stranice. Ti bi htio da stranica u HTML_inptut postavi css te onda tvoja komponenta nemora postavljat svoj css vec samo pozove HTML_input s te stranice…
Znaci na kraju balade te i dalje muci izgled ( ja se nadam da sam to dobro shvatio) jer funkcionalnost nije tesko slozit s vec postojecim tehnologijama. Ti bi htio da komponenta pozove HTML_modal, koji je vec stranica definirala te da se otvori njen nativni modal, nativni input, itd. I to bi jos htio da bude cross platform pa da mozes programski djelit komponente medju platformama.
Ograniceno gledano, mislim da ideja nije losa. Treba malo razmislit. Napisi kak ti to radis pa da vidimo na cemu si.

32

Naravno, postojat će stvari koje će se uvijek trebati ručno doraditi. Ali poanta je da se to svede na minimum…a ovo bi bio jedan veliki skok u tom smjeru.
Inače, ovaj normativ sam već nazvao normJS. …a osim poznatih apstrakcija u JS svijetu, postoje apstrakcije i u CSS svijetu. (koje sam nazvao normCSS)
Tako recimo u CSS svijetu imaš neke stvari koje se ponavljaju…da započnem:
$input_border_color
$input_border_color_focused
$warning_color
$warning_background_color
itd…itd.
…kada bi se izvele svi logični opisi koji se učestalo pojavljuju u CSSu, onda bi neka komponenta mogla razmišljati ovako:

“Aha, ovo je sada warning boja za ovu komponentu …i neću izmišljati svoju warning boju, nego ću koristiti globalnu warning boju koju mi nameće normCSS”

Pri tome normCSS je preddefiniran skup tih logičnih stilova koji se pojavljuju na stranici…i u praksi to je “samo” skup varijabli koje se mogu inkludati u scss/less file.
I sada kada ti dolazi komponenta koja je deklarirana u skladu sa normCSS…ona jednostavno ne može raditi bez da je se nahrani sa tim file-om koji je normCSS. A kada ju nahraniš sa tim file-om, ona počinje slijediti stil/vrijednosti koje su definirane unutar tog file-a.

Ovdje je dakako teže prepoznati i deklarirati logične cjeline i nazvati ih pravim imenom. Jer oko umjetnika slijedi osjećaj za dobrim izgledom, a ne zna to iskomentirati racionalnim razmišlanjem. (Koje postoji iza tog osjećaja). Mada tu vrlo moguće griješm…dobar dizajner uči svoju struku, a to što uči su upravo ta racionalna razmišljanja zbog kojih je nešto pobojao istom bojom kao nešto drugo. Te poveznice imaju svoje prave veze koje se mogu logički povezati. Upravo kao što se svaki border input polja prikazuje istom bojom…bilo to input text polje ili input dropdown polje…

33

Boldano ne. Ne kužim zašto to misliš?

Moja komponenta može nastati bez ikakvog html-a i ikakvog css-a i dobro funkcionirati sa komponentama koje se zasnivaju na htm/css-u.

Ako je moja komponenta recimo baš modal komponenta…onda je to sasvim normalna stvar da će ta komponenta ostaviti prostora developeru koji ju koristi da ju customizira po svojoj želji.

No kada se pojavi nova komponenta koja koristi taj modal, onda će taj modal izgledati i dalje točno onako kako ju je developer inicijalno kustomizirao.

Osim, ako developer izričito toj komponenti ne da permission prema nekoj drugoj instanci tog istog modala, kojeg je drugačije instancirao…onda bi ta komponenta radila sa drugačijim vizualnim (ili funkcionalnim) modalom. No to je volja developera…a isto tako i komponenta ima neke preduvjete kako modal mora biti instanciran da bi zadovoljio dependency koji on očekuje od te komponente.

34

Nije mi sjelo postojanje apstraktnih klasa i interfacea (nisam vidio razlog njihovog primjenjivanja) DOK nisam krenuo s učenjem polimorfnih klasa - i čini mi se da bi tu više odgovaralo rješenje problema (kojeg si slučajno baš naveo kao problem s input i checkboxom, kojeg bi baš s polimorfnom klasom riješio).
Međutim, meni se lampica i dalje ne pali.
Jedino što vidim jest da bi rješenje za nepostojeći ili jednostavan problem moglo riješiti komplicirano korištenje standardiziranih komponenti :slight_smile:
Daj jedan primjer gdje bi imalo smisla koristiti takav način izrade i korištenja komponenti, možda će većini biti sasvim jasno o čemu je riječ? (A možda se i lampice popale ko na božičnom drvcu)

35

Ne mora biti.

Upravo se taj problem rješava. Da je samo jedan framework…nebi imali ovaj problem. Ali realno je ne moguće imati samo jedan framework…kao što je nemoguće bilo imati samo jedan browser…

Mi ne znamo što sve može postojati, tako da je ne moguće tvrditi da imaju sve što ti treba.
Što kada se netko drugi pojavi sa nečim što nemaš u svom okruženju?

No ne kažem time da je react loš…vjerujem da je više nego odličan.

Naravno, a sada zamisli koliko bi imao da imaš sve ono što će nekome zatrebati pa će si napraviti sam.
Znači imao bi nesagledivo više i ne možeš se sa time uspoređivati.

Ova izjava ti je ravna kao da si rekao: “Meni ne trebaju tuđi WP pluginovi…bum si sam napravio one koje zatrebam”. Sada zastani pa pogledaj koliko funkcionalnosti ti nude gotovi WP pluginovi? Ne možeš pomisliti na nešto da već ne postoji…

Isto tako, vjerovato nitko nije trenutno svjestan koliko bi mogli imati…da smo kao zajednica postigli veći stupanj sienergije…i da sve što smo napravili …da ništa od toga nije išlo paralelnim granama…nego samo prodiralo ka naprijed.

Naravno…100% prema naprijed nije moguće. Ali 100% paralelno je 0% prema naprijed. Mislim da sagledanjem trenutnog stanja je očito da smo malo previše rasuti paralelno…i da to umanjuje efektivnost gaženja prema naprijed.

36

Upravo dok to pises, ti radis jos jednu paralelnu granu koje zeli biti ‘the best approach’, isto ono sto rade ostali react, vue, i ostali FW-ci.

37

Ma da mozda sam zeznuo s tom recenicom. Ovaj modal je najbolji primjer.
U sutini hoces slozit nekakve widgete koji ce drugi moci pozivati na isti nacin bez obzira gdje se nalazili…

38

@bozoou

Wp je primjer kako se ne bi smjelo raditi.
Sto vrijedi kad sve izgleda lijepo, jednostavno, hrpa pluginova, kad je ispod haube goli k.

Bas sam gledao woocommerce, super izgleda, opet ispod haube banana i previse code-a s obzirom sto sve nudi u core instalaciji.

39

Očito nije slučajno, jer to je zoran primjer korjena problema.

Mislio sam da sam dao više nego dovoljno primjera…ali evo jedan malo realniji.
Zamisli da ideš praviti komponentu koja će omogućiti useru totalni CRUD nad nekim modelom u bazi. CRUD je jel: create, read, update, delete.

Za izvesti CRUD trebamo svašta…od ajaxa, modala…do svih mogućih inputa kakvi se mogu pojaviti: text, date, number, checkbox…
Da bi to sve na nešto ličilo, trebamo te inpute posložiti u nekakve forme…koje se možda pojavljuju i na onim steper formama koje imaju step1 -> step2 -> step3.
Nadalje, ako je pošten CRUD, trebao bi raditi i na mobitelu…

I sad?
Ako pogledaš malo ta komponenta CRUD-manager nema doticaja sa niti jednim vlastitim HTML elementom, mada mora koristiti sve gore navedene.
Tako reći, ti bi za implementaciju tog CRUD managera trebao samo toj komponenti reći koji model u bazi managira…te bi joj kroz konfiguraciju objasnio koje permissione korisnik ima (a vrlo vjerovatno nebi ni to objašnjavao, jer bi već nastala komponenta koja bi mogla obavljati taj zadatak)…i ona bi dalje sve mogla odraditi koristeći tvoje INPUT komponente koje ti već imaš implementirane na stranici. Naravno, morao bi i komponenti dati permissione prema drugim komponentama koje će ona moći koristiti…i koje će ona zahtjevati od developera.

Stoga, tvoja priča sa tom CRUD komponentom nakon što si je inicijalizirao bi započela tako da bi ju kreirao unutar nekog elementa na već standaran način: CRUD.Create(). (Što smo negdje gore rekli da svaka komponenta bi morala imati root apstrakciju, gdje bi se nalazila i .Create metoda)

Ako bi se napravila i apstrakcija CRUD komponente…neka još složenija komponenta bi mogla koristtii taj CRUD-manager u svoje potrebe samo tako (onako od šale)… a ti kao developer bi počeo usložavati jedne puno veće funkcionalnosti i tako bi kreirao puno veće i složenije stvari. Izašao bi konačno iz toga layera da konstanto rujemo po dnu i mulju …i slažemo neke bazične stvari. Koje tu trebaju biti…onako doslovno što “pomislimo” na njih da nam se stvore…
A s vremenom da nam se stvaraju i puno kompleksnije stvari na jednako jednostavan način.

Ono što je također prednost ovog pristupa je modularnost… znači, danas sutra shvatiš da neki drugi CRUD-manager je bolje posložio user-experince u svom zadatku. Ti pri tome trebaš samo zamjeniti svoju postojeću CRUD komponentu sa tom drugom…i ništa se nebi smjelo raspasti!

Danas sutra uočiš neki inovativniji dropdown, koji se bolje recimo prikazuje na mobitelu…zamjeniš samo svoju dropdown komponentu sa tom novijom…i sve ostale komponente od CRUD-managera do svih drugih koje su koristile dropdown…automatski su prešaltane na taj novi dropdown. With no pain.

To bi u jednom globalnom smislu konstantno tjeralo da se komponente nadmeću…da budu bolja jedna od druge, a zajednica bi u većinskoj mjeri uvijek koristila onu komponentu koja najbolje rješava neki zadatak.

Recimo, cijeli svijet bi koristio jedan CRUD-manager, dok se nebi pojavio neki bolji. Tada bi se brzo svi prešaltali na taj bolji…itd. …itd.
A sve komponente bi bile naganjane na isti način ka naprijed.
Konačno, developeri bi dobili kvalitetne alate…a proizvođači komponenti bi neki svoje naplaćivali…neki ne…baš identično stanju pluginova koje možemo naći u WP svijetu.

40

E vidiš…ja nigdje nisam rekao da i ispod haube treba biti izvedeno na isti način.
WP je stoga lijep primjer kuda stvar može otići čak i ukoliko je ispod haube kaos.

Sada zamisli kuda stvar ide ukoliko je ispod haube ok posloženo. Svemir je granica.

41

Na ovo nitko nece pristati jer je u pitanju lova, milijarde koje se okrecu.

Sad zamisli da imas crud, menu componentu, trazilicu i da su komponente napravljene po dogovorenom standardu, doslo bi do toga da bi svaki drugi developer napravio komponentu koju bi prodavao po $ 0.01 i imao bi na ponudi par milijuna menu i sl. , i tako za svaku komponentu.

Ogromna konkurencija, a nitko ne bi zaradio.

Pogledaj komponente gore, stavio link, pogledaj cijenu i broj korisnika koliko ih imaju, neka ih pola plati, a ostali koriste open source, izracunaj koliko je to minimalno love.

Milijuni godisnje.