Component develop tricky problem (JS)

Programiranje
62

@dmitrecic

…i sada pogledaj od kuda smo krenuli:

Ovo je znači HTML koji definira komponentu DIV:

<div id='elementID' class='class1 class2' anyAttributName='name' >neki tekst</div>

…neovisno od tehnologije, ovo je potpuno standarizirano i nema nikada potrebe da jednog dana napišeš gornju sintaksu, pa da kasnije nešto moraš mijenjati nebi li dobio isti rezultat. Znači iako je DRY kršenje, nije problematično jer je standarizirano.

To se piše tako…to je zacementirano…i to vjerovatno nikada nećemo promjeniti.
Možemo eventualno samo taj postojeći standard nadograditi sa novim pravilima… što je sasvim logično. Jer velim, ne možemo se zacementirati u nekom stoljeću i cijelu viječnost ostati na istom.

Nadalje… kada s tim istim DIV-om komuniciraš sa JS-om, poznat je standard da ćeš “neki tekst” dohvatiti na način:

var div = document.getElementByID('elementID'); 
var tekst = div.innerHTML;

Znači, jedan od propertya tog DIV-a je .innerHTML i to je također zacementirano kao standard.

Zaključak, krenuli smo od standarada…zato smo i uspjeli napraviti sve što smo napravili. Da smo u startu krenuli tako da je nekome DIV bio <div>, nekome <block>, nekome <box> …i da se innerHTML svojstvo pozivalo na načine tipa:

div.innerHTML
div.html
div.INNER_HTML
div.content
div.content()
…itd.

…došli bi puno teže do točke do koje smo došli.
Stoga, valjda je logično očekivati u ovom koraku, kada su se iskristalizirale sve komponente koje čine jednu modernu web stranicu, da zastanemo malo…i postavimo neke norme za dalje …kako bi opet zajedničkom sienergijom dosegli jedan sasvim novi level.

1 Like
63

Inače, nije bilo tako davno kada sam zatekao Google da mu se dropdown prelomio ko g.ovno na dva djela nasred ekrana.

Velite sve je ok, a takve greške se mogu desiti Googleu?

Ono što me više zanima, da netko od vas sutra napravi najnapredniji dropdown ikada, koji nema šanse da tako pukne ni pod kojim uvjetima… kolik bi trebalo Googleu da se kompletno preseli na taj dropdown?

Ako bi mogao to napraviti bezbolno i u tren oka…onda se slažem, nemamo problem.

64

Hehe, ok.
Ja te shvatih da su backendaši pravi majstori koji rade pravi posao…
…a frontedndaši, gospoda u odjelima, oni jel…prodaju maglu…što bi očekivao od nekoga tko se više fokusirao na svoje odijelo…nego na ostatak priče.

Tako me asociralo odijelo…da su fejk majstori :slight_smile:
Krivo sam te shvatio onda …

1 Like
65

Ovaj dio mi ne liježe.
Da sam lead Jutarnjeg, odgovaralo bi mi upravo da mi se šalju novi oglasi u formi JSON-a, XML-a ili slično na moj (Jutarnji) API URI koje bi rasporedjiv’o na svojim stranicama sa svojim HTML-om, CSS-om i JS-om.
Mene (lead-a Jutarnjeg) prosto zanima dohvatanje podat(a)ka u bazu oglasa a prezentacijski level rješavam zajedno sa svojim dizajnerom, to nema nikakve veze (i ne treba da ima) sa DB layer-om.
Ako pak naidje (se pojavi negdje) neki super ultra cool dropdown ili bilo koji drugi element, uzeću taj CSS fajl ili paket. Možebitno kroz npm i predstaviću novi izgled svojim čitaocima. Tako trenutno funkcionišu stvari i ne vidim u čemu je loše.
Predstavljanje (Perinog™) CSS paketa ili bulk CSS i JS uopšte nije ometeno trenutnim sistemom već je upravo podržano.
Peru™ treba da zanima samo izgled dropdown-a i uradi ga tako da je identičan na svim korišteni(ji)m browser-ima. Ko će da ga koristi zavisi samo od afiniteta Ivinih™ i inih.
Pero™, ako želi da mu funkcija radi u twb-u i Zurb-u može da postavi višeuslovni blok i provjeri da li je (ili nije) objekt definisan. Zurb je tu uradio bolji pos’o od twb-a jer ima Foundation apstraktni objekt dok twb se može provjeriti putem typeof([?]) !== undefined gdje je token neka funkcija iz twb js fajla.
Plašim se samo da Pero™ misli kako prezentacijski nivo treba da se miješa sa logičko-funkcionalnim i očekuje da zajednica uvidi benifit pristupa.
Ja drugo ne vidim ovde. Da slikovito sažmem:

66

Nisi skuzio.
Ajde drugi primjer.
Ajmo reci da wordpress forsa nekakave globalne objekte, tj. da tema mora definirati npr. button_object. To je button koji koristi tema. Ima pripadajuci css, mozda zakacen nekakav js ( ripple efect recimo).
E sad, svaki kreator pluginova moze pozvat button_object kada mu treba gumb. Ovime si dobio da ce gumb iz plugina izgledati identicno tvojem gumbu ( gumbu iz teme) i pluginovi nece trebati raditi svoj css za gumb. U principu svi dobivaju. Trenutno stanje je takvo da ufuras plugin i onda moras ili css plugina mjenjati ili overridat da bi dobio izgled koji odgovara svojoj temi.

1 Like
67

Biće.
Nije mi jasno da li je generalna ideja mijenjanje CSS core-a, JS core-a ili nešto treće.

Jasno mi je da postoje predefinisane varijable/objekti. Možemo se (s tim u vezi, a na nivou datog primjera) dohvatiti shortcode-ova u WP-u.
Ali nije li iluzorno očekivati da WP po default-u ima svu funkcionalnost potrebnu svima - u takvoj konstelaciji WP bi bio težak $nameIt gigabajta. Zato i postoje plugin-i da se instališe/upotrijebi baš onaj koji ima potrebnu funkcionalnost i ništa više od toga.

68

Pa nije to neka posebna funkcionalnost. To je nesto sto tema odradi za nekoliko cesto upotrebljavanih komponenti. Za jedan gumb ti treba doslovce par linija koda. I mozda imas takvih komponenti 20ak. A rjesi te problema overridinja pluginova.

69

Tako je. Evo još jedan koristan primjer.
Radiš sa nekom komponentom…i sada želiš putem te komponente dati korisniku neku svoju funkciju koju može trigirati, recimo export tablice u excel.
U suštini moraš na tu komponentu negdje zakačiti gumb …i svoju funkciju povezati sa tim gumbom…i to napraviti tako da korisniku bude uočljivo i da ok izgleda.
I koji je sad klasični način? Moraš sam smišljati način kako da zakeljiš gumb na tu komponentu…i da ga vizualno prilagodiš izgledu komponente…

…no da su stvari standarizirane i da ta komponenta extenda klasu koja mora ima toolBOX, trebao bi napraviti samo sljedeće:

komponenta.toolBox.Add({name:“Moja Funkcija”, description:“Exportaj ovu tablicu u excel”, icon:‘someIcon’, funkc:exportToExcel(data)});

…i sada, koristeći gornji standard, nas baš briga kako je ta komponenta osigurala gdje joj je toolBox i kako je rješen UI.
Ali znamo da je u interesu komponente da je to odradila maksimalno dobro…i vjerujemo joj.
Ona će najbolje znati uklopiti u svoj vizual gdje će staviti taj gumb, te kako će korisnika informirati sa description-om koji je naveden uz ime funkcije…itd.
Naravno i toolBox-a može biti više na komponenti, pa na nama ovisi hoćemo li ugraditi funkciju u nekakav primary-toolBOX ili secondary-toolBOX …sve ostalo je na komponenti.

Sada da potegnem analogiju sa mobitelom i aplikacijama (koje su komponente unutar androida).
Što mislite, kada netko instalira vašu aplikaciju…jeste li vi taj (ili autor komponente) koji mora razmišljati kako će ugraditi gumb te aplikacije u vizualni okvir androida??
Naravno da ne…android je taj koji je predvidio gdje je najbolje smjestiti gumb koji otvara dodanu aplikaciju. Korisnik eventualno može taj gumb pomaknuti iz jednog slide-a ekrana na drugi,
a to je upravo samo odabir primary-toolBox-a ili nekog drugog. No originalno UI odrađuje android.

70

Koliko sam ja skužio, stvar bi trebala (zamišljena) je ovako:

  1. u skladu s DRY principom, da se koriste elementi/komponente kako bi se princip poštivao
  2. elementi/komponente bi trebale biti jednostavne za korištenje i jednostavne za proširivanje
  3. elementi/komponente bi trebale biti kompatibilne sa JS/PHP/ASP.NET i ostalim web tehnologijama
  4. (naravno) nazivi i korištenje komponenti bi trebalo biti standardizirano

Ako dobro shvatih (nakon 2 dana :smiley: )
U ovome vidim prednosti, pogotovo ako se svi elementi/komponente nalaze na jednom centralnom repositoryu, pa sa njega vučeš što ti treba.

71

Naravno da ni teme ni plugin-i nisu identični kad se uporede sa pandanima.
Recimo odem na themeforest i isprobam 5 tema da bi se odlučio na kupovinu jedne.
Šta je poenta ideje: da sve teme imaju iste shortcode-ove?
Neka svaka tema koristi 4/20 ja ću uzeti onu koja ima 4 koji meni trebaju, zar ne?

To smo već riješili kroz npm. :smiley:

I dalje mi je “zašto kažeš benzin kada misliš voda”. Polako kroz pitanja i odgovore kristališem problematiku koja se uglavnom svodi na presentation layer i stil što se rješava svojim CSS fajlom.
Ako napraviš drugi paket koji ima neku JS (ili AJAX server-side) funkcionalnost daješ mu requiring dependency prvobitno napravljenog CSS paketa. Pošto stvari tako i sad funkcionišu, kad kažem da se analiza problematike polako kristališe stvarno mislim polako. :blush:

72

Polako, ni ja nisam siguran da sam shvatio :smiley:

73

E ovo ti je (za moj pojam) extra paket. Nije mi dosad ni pad’o na pamet.
Mada sam momentalno pomislio na upotrebu kroz browser ekstenziju.
I svakako da - postoji.

Ako ne bi’ pogriješio kad pretpostavim da bi ti želio da ti ovakva funkcionalnost radi u svim browser-ima, samo ću reći da firme/developeri upravo to i rade - razvijaju paket za sve browser-e da bi postojala ekstenzija/add-on (i konsekventno funkcionalnost) na različitim browser-ima - dostupno svima ili najvećoj većini koja koristi 4-5 glavnih browser-a.
Kod primjera sa telofonima tj. OS/aplikacijama za iste je identičan slučaj: ista kompanija proizvodi aplikaciju i za Android i za iOS.

Edit: evo i web paketa (nisam prob’o) koji se instalacijom sa npm-a dobija u obliku JS + CSS.

Ostajem pri pitanju: šta je ovde tol’ko problematično da mora mijenjati sveukupan pristup web-u koji se razvija već 25+ godina?

74

Pa nije to bas mjenjanje cijelog pristupa web-u, vec definiranje nekih komponenti tako da i tebi i drugima olaksas posao…

Da li si upoznat s principima OOP-a? Jel znas kaj je klasa, interface?

75

Ja neznam jesi li ti uopće pročitao moj zadnji post?
Ti kao da si pročitao prvu rečenicu…i ostao u glavi sa idejom

Exportaj ovu tablicu u excel

Post uopće niji bio o tome. Kilometrima daleko od toga je bila poanta!

Funkcija u postu se mogla zvati: “Upute kako obrisati dupe, sa što manje utroška papira” …i poanta posta bi ostala ista. Ne čitaš uopće … i ne razmišljaš.

76

Naravno. Kroz PHP, doduše: interface, trait, final, abstract - sve koristim po potrebi. Dakle - jesam.
Jedino tako i funkcioniše (sada) kako sam opis’o - uzimam sa packagist-a repo koji mii je potreban.
Vrlo sličan princip se dešava i sa npm-om.
Ja u @bozoou -vim postovima mogu pročitati tek apel da se core JS i core CSS prošire (iako mi nije još najjasnije čime jer benifit trenutno rješavamo ovim gore - PHP packagist, JS/CSS - npm).
Ali ni to nije problem. Napiše se jedan slastan rfc koji w3c ne može da odbije i riješeno.

Evo ti prva rečenica.

Da stvar bude grdja, ja sam pohvalio konkretnu ideju. :laughing:
Samo mislim da je put ka realizaciji pogrešan.

77

Jel se ti zezaš ili? Iza riječi recimo je moglo pisati bilo što. Zato i iskoristih riječ “recimo”

Da si razumio ostatak posta, vidio bi da nema nikakve veze sto ce ta funkcija raditi…nego kako cemo ju integrirati u UI (user interface, jel)

78

Svašta. evo i tebi jedan:

  1. vlasnik (developer) sajta koristi twitter bootstrap
  2. želio bi imati alert popup koji nije JS default
  3. include-a bootbox.js (recimo)
  4. (?developera iz tačke 1. ne zanima da li 99% sajtova koristi Bulma/Materials i kako im izgleda alert popup)

U čemu je razlika, šta je konkretan problem?

Jesam li blizu?
Ako je odgovor da, rješenje je u narednoj rečenici iza citata.

79

Ne treba se zapravo jako puno toga mjenjati u samom nacinu na koje rade stranice.
Sve sto treba standardkoji ce definirati interface i onda svaki web majstor mora napravit klasu.
Ajmo opet primjer gumba:

buttonInterface = {
classes (string)
setOnClick(function)
getHtml(function)
...
}

(JS nema interface, ali i ovako virtualno definiran ce posluzit)
Webmaster onda mora postavit taj gumb da bude dostupan svima

class myButton extends Button {
constructor(c){
this.classes='my-button-css-class';
}
}
window.button = myButton;

I sad bilo koji plugin samo pozove

var pluginButton = new window.button().setOnClick(nekaFunckija).getHtml()

i dobije isti gumb kakav koristi tema.

U sutini nema nekog prevelikog posla, posebno zato sto realno nema tak puno stvari koje mozes predefinirat ( gumbi, modal, eventualno nekakav bordered div,…).

Ja neznam kak ti, ali ja kad uzmem plugin za WP, ja promjenim njegov css ( ili ga overridam sa !important, ili nekim drugimnacinom), ali tezim tome da mi plugin dio bude sto slicniji mojoj temi. Pluginove trazim po funkcionalnosti, a ne po izgledu, samm time vecinu puta moram nekaj overridat.

80

Proljetos sam radio sa WP-om i nadam se nikad više.
Po tome što pišeš, mislim da je ispravno to što radiš, vjerujem da bi’ slično/isto.
Recimo da sam često znam ubaciti (prazan) objekt u header koji nadogradjujem (npr var domEn = {} ).
Tipa, ubacujem neki csrf token ili nešto slično što bi se trebalo iskoristiti u load-ovanim skriptama iz footer-a.
Pa bi taj tvoj button ovde bio recimo

domEn.pluginButton = new window.button().setOnClick(nekaFunckija).getHtml(); // call after interface load

Samo kažem da se taj interface™ dio rješava npm-om, vrlo efektno.

E sada, ako nadovežem @bozoou -ovu ideju, da li to znači da bi’ ja treb’o korsititi neku njegovu nomenklaturu naziva ili on apeluje da se širi core JS-a novim nazivima?

81

Ma nemora se nista mjenjati u samom JS/CSS/HTML-u.
Neznam kak bi npm rjesio ovaj problem iskreno…