NormJS - root Class

NormJS root Class je apstraktna klasa sa određenim metodama koje će morati naslijediti svaka komponenta koja ispunjava normJS standard.
Ova klasa se zapravo ne zove root Class, nego upravo normJS, kao što se zove cijeli standard.

Komponenta koja extenda normJS klasu, mora imati sljedeće metode, propertije:

component.normJS = true
component.setDevice(int|string deviceType)

Pojašnjenje:
.normJS = true je properti koji odaje da se radi o normJS komponenti
.setDevice() je metoda koja definira komponenti na kojem uređaju se prikazuje.

Ulazni parametri:
0 | “destkop” | “D” -> prikaz na destkop računalu
1 | “tablet” | “T” - prikaz na tabletu
2 | “mobile” | “M”- mobilni prikaz

Nakon što pozovemo:
komponenta.setDevice(2) ili komponenta.setDevice("mobile") , zadali smo komponenti da se prikazuje njena mobilna verzija.
Što znači da mi ne moramo ništa znati o komponentama koje koristimo unutar normJS standarda da bi ih mogli jednostavno po ovom standardu koristiti u mobilnom ili destkop načinu rada. Sada možemo tvorcu komponente prepustiti da on na najbolji način svoju komponentu prilagodi za mobilni ili destkop prikaz, a na našoj kontroli je da uvijek isporučujemo mobilnu ili destkop verziju stranice, ili pojedine komponente.

Ukoliko nije trigirano komponenta.setDevice() , ista mora po defaultu koristiti ono stanje koje je definirano komponentom: normJS - device ->device.getType() (Kasnije ću polinkati kada opišem tu device komponentu)

Ukoliko ne postoji komponenta normJS - device i nije trigirano komponenta.setDevice(), komponenta se mora sama prilagoditi prema veličini ekrana:
Za sljedeće širine ekrana vrijedi:
širina < 500px -> mobile
širina >= 500px && širina <800px -> tablet
širina >= 800px -> destkop

HINT:
Da bi komponenta mogla ispunti logiku .setDevice(), css pravila koja opisuju njen izgled nije poželjno definirati na sljedeći način:
@media only screen and (max-width: 600px) ...
Pravilan način bi bio definirati css klase koji opisuju mobile, tablet ili destkop view, te ih pravilno aktivirati prilikom poziva .setDevice() metode.

Oke, u ovom momentu nisam siguran kako ću to najljepše dokumentirati, ali tu će mi valjda netko dati dobre sugestije.
Možda neki alat za kreiranje dokumentacije, i neki standard po kojem bi se ovakve stvari opisivale? Ono, da bude pregledno. Budem ja već našao šprance…no ne sumnjam da će @tpojka mati neki dobar izvor.
Ovo sam sada malo nabacao…čisto da vidite u kojem smjeru ide. A ne mora iz prve ispasti lijepo dokumentirano, bit neće uteći nikuda.

Također, ako postoji već neki normativ za širine koje definiraju mobile, tablet, destkop…može te i to sugestirati.
Isto tako, ako primjetite da sam neku metodu nespretno nazvao … budite slobodni dati svoje prijedloge i za ime metoda i parametara i za ime komponenti Neka to ne ovisi od mene, nego od svih nas koji ćemo sudjelovati u kreiranju ovog standarda.

Također, putem će se sigurno ukazati još potrebnih metoda za normJS (root) klasu…ali putem će se to sve fino iskristalizirati. Cilj će sam pronaći svoj put. :slight_smile:

Vjerujem da će vam to sada izgledati malo komplicirano za developera komponenti koji bi morao ispoštovati sva pravila. Ali normJS prilikom kontrole standarda će moći precizno sugestirati developeru koje je pravilo zaboravio poštivati na svojoj komponenti. Tako da će kontrola standarda biti veliki helper onima koji će praviti komponente…da naprave sve tip top po standardu.

Prve dvojbe. Da li bi bilo bolje omogućiti da vrijedi i jedno i drugo i treće:

komponenta.setDevice("mobile");
komponenta.setDevice("Mobile");
komponenta.setDevice("MOBILE");

Znači da je string input parametar case insensitive ?
Mislim, ako bi se na to odlučio…onda bi kroz cijeli normJS dosljedno to slijedio da string parametri ovog tipa budu case insensitive. Ili je bolje da se slijedi strogo neki format, npr. da se takvi parametri zadaju isključivo velikim ili malim slovima?

Također, odmah primjećujem da svugdje gdje se definira ovakav tip string parametra, da to povlači neke zajedničke osobine. Koje bi trebale biti definirane na jednom mjestu u skladu sa poštivanjem DRY-a.
Recimo, ako neka metoda prima sljedeće moguće parametre:

.metoda1(x) ; gdje je predviđeno da x može biti “MOBILE” , “TABLET” ili “DESTKOP”

i neka sasvim druga metoda,recimo
.metoda2(y) -> gdje je predviđeno da y može biti tipa: “LEFT” , “RIGHT” , “CENTER”

…i to su neke sasvim različite nepovezane metode…ali što ih povezuje?
Povezuje ih da im je input parametar definiran unutar unaprijed predviđenih gabarita.
Stoga taj input parametar je string, to je očito. Ali je još nešto osim stringa. Mogli bi ga nazvati tipa: “stringScope” type, što govori da se taj string nalazi unutar nekog predefiniranog scope-a , a ne da može biti bilo koji proizvoljni string.
Što će reći da i .metoda1 i .metoda2 za slučaj da prime neki nepoznat parametar …tipa:
.metoda1(“PHONE”) …gdje je “PHONE” očito ukucan zabunom developera. Onda bi metoda1 trebala generirati nekakav erorr: input type out of scope

I to je zajedničko svojstvo i metodi1 i metodi2, da bi trebale provjeravati input parametar jel ima smisla ili ne.

Gdje bi to i kako definirali, da ne kršimo DRY? Ako me kužite.

To bi u konačnici omogućilo developeru da bez prateće dokumentacije sazna koji su mogući input parametri. I da ga sustav generiranjem greške upozori ako je koristio input parametar koji nije smio.

komponent.dependency = [];

Komponent dependeny je proizvoljni parametar normJS (root) komponente.
Ukoliko je definiran, on govori o kojim komponentama je vaša komponenta zavisna.

Recimo, ako definirate:
`komponent.dependency = [“modal”];

…to znači da vaša komponenta zavisi od normJS - modal komponente. (dijalog)
Sada vi u miru možete razvijati vašu komponentu koja koristi modal, bez da se zamarate time koji modal će biti korišten u projektu u koji će biti uključena vaša komponenta. Znajući da će taj modal poštivati normJS standardizirane metode, vi možete koristiti sve metode modala za koje je definiran standard.

Prvo, ako želiš održati ozbiljnost svog tona molim te da prestaneš ponavljati DRY jer to nije ništa novo već barem šest decenija. Bar bi trebalo da je tako. Bar se sjećam u BASIC-u GOSUB naredbe. A uvjeren sam da je princip postoj’o i prije mog rodjenja. Hvala.

Ja ću krenuti redom (kako šta hvatam u postovima) i potrudiću se u svojoj moći i vremenskoj ograničenosti da preskačem što manje (a valjda će mi i drugi priskočiti u pomoći).

Trebaš znati dvije stvari ovde a to su:

  • Definicija NormJS root klase (imaš ovde nekih par propertija i metoda, zašto ne postavljaš kod na github - niko nije naučio da pamti to ili kroz postove da ide i gleda da li nešto jeste ili nije)
  • Egzamplar component klase (potreban je bilo kakav primjer component klase da bi se u toku razvoja na vrijeme uočile slijepe ulice)

Nisam im’o sreće dosad u odgovorima ali mogu ti dati jedan savjet koji se tiče razvoja projekta a to je: ne rasplinjavaj se.
Ovo ti ne treba

0 | “destkop” | “D” -> prikaz na destkop računalu

već ovo

0 -> prikaz na destkop računalu

Prvo dolazi u nekim naknadnim verzijama razvoja. Riješićeš sebe muka kad budeš testir’o kod.
Što se tiče alatke za dokumentaciju, neko drugi bi ti više mog’o pomoći jer ne koristim JS 8h/d - možda usejsdoc.org ali provjeri još (sa nekim) da li je to to što tražiš.

1 Like

Nema veze što nije ništa novo…ako želim dati naglasak da neko svojstvo želim imati opisano na jednom jedinom mjestu, onda mi je najlakše na to asocirati korištenjem izraza “a da poštujemo DRY”. Nego da trošim više riječi a da kažem isto.Nema tu ničega osim toga.

Ma neće biti s time problem, samo ako se elegantno definira na jednom mjestu 0 = [0, “destkop”,“D”] …onda će se sva stanja iz arraya aproksimirati u nulu…a lako se i testira. A na nama je da nabacamo u array sve što vrijedi za input parametar = 0. …i lako se onda pomoću istog arraya i provjerava da li je input slučajno izvan zadanog scopea.
Samo velim, treba onda zadati negdje da normJS mora poštivati tipove input parametara. Isto tako treba uvesti novi tip input parametra, jer kao što rekoh…iako je input parametar string, nije isto ako može biti bilo koji string i ako je string unutar zadanih preddefiniranih okvira.
Kada se to definira, onda će svaka metoda normJS-a morati baciti error: input type invalid (Za neodgovarajući input type parametar)
i error: input value out of scope (za te scope parametre, koji mogu biti samo neke preddefinirane vrijednosti)

I kod testiranja komponenti…neće biti nikakav problem napisati sve testove za nametnuti standard. Puno veći će biti problem testirati vizualni dio da li se što raspada… za što će ipak trebati ljudsko oko.

Ali kada bi ovo zaživilo na većoj razini, dala bi se složiti image analiza, koja bi dosta dobro mogla uočiti ako se nešto raspada ili ne. Ta tehnologija obrade slike jako napreduje…i to sigurno neće biti prepreka danas sutra da nekakav algoritam po automatizmu ispita da li se vizualni dio raspada ili ne. Ali to je već…malo dalji korak :slight_smile: . Samo velim…koje tu sve mogućnosti ima. :slight_smile:

To i dolazi u naknadnoj verziji. To ti i kažem, ne treba ti zamor sa tim nizom uopšte kad još nemaš ni oblik parent klase. A ti tjeraj.

Bez uvrede, naučio sam kroz bitbucket/github/gitlab da pratim razvoj koda. Jira i Trello da ne pominjem.
Tako da je ovo za mene nemoguća misija (samo o iščitavanju koda govorim i praćenju šta koja linija treba da radi).
Github ti je dobra stvar jer se tamo puno radi a malo priča i sav kod je na jednom mjestu.
Ti ovde imaš 10 linija koda u 5 postova visine 3000px.

Edit:

Ovo mi je promaklo:

Ovo u programiranju ne postoji. Ja nisam naučio dosad.

Istina, primjetih to. Ali to će tako biti samo dok se ne iskristalzira način kako ću dokumentirati.
Forum je ionako tu da mi se pomogne da mi se to iskristalizira…a konačna dokumentacija je ta koja će biti tip top uredna.

Forum je tu prvenstveno jer nebi ja htio nositi teret da moram smišljati imena metoda. Tu će biti sigurno boljih prijedloga iz perspektive “mase”. Koja će uočiti da sam nešto nespretno nazvao.

13 posts were split to a new topic: GitHub - zašto koristiti?

Ako bi želio nešto mijenjati/dodavati u JS-u, mislim da bi ti ovo trebala biti adresa:

https://www.w3.org/standards/webdesign/script#specifications

a ono bar da (pred)vidiš koji su planovi. Ne može ti odmoći (iako smatram da je to jedini [ispravan?] način postavljanja standarda).

P.S. Iluzorno je (meni) očekivati da ćeš pročitati sve u vezi tekućeg standarda i trenutnih prijedloga za izmjene i dopune ali kad napraviš vremeplov vrati se pa pročitaj sve linkove tamo. :smiley:

To nije standard na istoj razini egzistencije.

Asembler ima svoje standarde…jezici koji su nastali nad njim imaju svoje. Nije to isto.
Ja ne mijenjam standarde HTML-a niti JS-a. To bi bilo suludo.

Ja kreiram standard za jedan novi sloj … za alate koji su nastali od tih jezika.

Ali zar nije suludo tako nešto raditi ukol’ko ne poznaješ barem >90% standarda i sintakse samog jezika za koji pokušavaš napraviti podstandard?

Možda i nije.
Jer želim standarizirati komponente koje niču u JS frameworcima. To me baš ne povezuje gotovo nikako sa JS-om.

Bitnije je da poznajem što sve te komponente moraju moći raditi. Jer netko treba od tih komponenti jedno…netko drugo…netko treće.

Ako sam se ja u svom iskustvu susreo samo sa prvim i drugim, a nisam svjestan trećeg …onda ću tu faliti da ne razradim dovoljno standard da omogućim sve potrebno.

ALI, ja ovako i onako neću iz prve moći raspisati sav standard.
-em ću negdje falit
-em će nastati značajke nad komponentama u budućnosti, koje zajednica još nije ni uočila, tako ni kreirala.

Tako da je najbitnije da dobro osmislim koncept standard, kako bi se u budućnosti mogao razvijati dalje kategorizirano po verzijama i da bude backward kompatibilan.

Ovo što se tiče “verzioniranja” standarda. To bi moglo biti još najviše tricky…jer verzije ne nastaju linearno, nego kriš kraš unakrsno. Moguće sam opet nerazumljiv…ali eto, mumljam si u bradu gdje su potencijalne zamke. Koje se ni meni još nisu najbolje iskristalizirale, ali njušim problemčiće.

Uglavnom, hoću reći da je bitnije postaviti ispravne temelje…nego pokrit iz prve sve savršeno, što je teoretski ne moguće.

A da pokrijem što bolje iz prve…napravit ću jednu analizu komopnenti uzduž i porijeko nekih većih framework-a …i od tamo pokušati osvijestiti ono što mi nije na pameti. To zapravo zamjenjuje ovo štivo koje mi ti gore savjetuješ…samo što ja moram čitati ono štivo koje standariziram.
Ti si mi sa istom idejom gurnuo taj gore link…samo velim, to je druga stvar.
U pravom smislu si mi trebao gurnuti sve frameworke koji postoje na webu i reći:

“Prvo moraš dobro proučiti što te komponente sve mogu napraviti, da bi sve to mogao znati svesti na jedan standard.”

Ja i pričam o tome. Trebalo bi znati većinu karakteristika jezika da bi se ispravno postavio temelj.
Meni bi nerealno bilo za očekivati da ljudi pristupe nečem što ne podržava 90% trenutne sintakse ili obrnuto što podržava tek 10% (uslovno rečeno, banalizujem) - vrlo puno bi’ (lično) mor’o znati u trenutnoj nomenklaturi da bi’ pristupio tako nečem. (Tipkam naglas.)

1 Like

Tipkam ja kostur normJS a u najobicnijem editoru, pa cu ga onda prenesti na neki online dokument.
Btw…otkrio sam jedan jako zanimljiv novitet.
Zamisli klasicni pristup i sada imas Perinu i Ivinu skriptu. I Perina i Ivina skripta trebaju trim() metodu. No Perina skripta tu metodu dobiva preko jQuery.a a Ivina preko Lodasha…neka treca skripta preko nekog treceg librirya. Sto se desava? Nastaju tri nepotrebna dependencya i projekt je zagušen sa suviše nepotrebnog smeća.

Realno, sve tri trim() metode koje oni koriste su isti opažajni prirodni objekt. Jer objekt nosi neku svrhu…a ovdje imamo samo jednu svrhu. Te iako imamo tri librarya koji omogućavaju tri trim metode, to je jedna funkcionalnost. Stoga, i trim metodu možemo opisati standardom. Standarizirati input, output i što body mora odraditi. Tu nam to postaje komponenta, isto kao sto je i dropdown. Ha-ca!

Što smo postigli? Unutar normJS.a bilo koja komponenta se može pozivati na trim metodu kao da je to dio sintakse normJS-a. NormJS će omogućiti da trim bude includan. A tko će biti proizvođač trim komponente, to je nebitno. To upravo ostavlja mogućnost proizvođačima trim komponente da se takmiče da njihova bude najbolja…najoptimiziranija…drugim riječima, da trim komponenta, isto kao i svaka druga…evoluira ka beskonačnom savršenstvu kroz nadmetanje tj.evoluciju.

Sve metode koje je Lodash uočio da su korisne, su upravo samo dio cijelog skupa metoda/komponenti koje se mogu standarizirati…i time omogućiti i da taj bazen komponenti evoluira kroz utjecaj zajednice.

Ovo je tako sick. :slight_smile: Na jednoj razini to onda rješava problem da te iste metode uočavamo i unutar različitih programskih jezika. Jer trim ne egzistencira unutar JSa, on svoje mjesto pronalazi i u PHPu i u C#…i u svakom drugom algoritamskom jeziku koji je evoluirao određeni stupanj od asemblera. Stoga, trim ne smije biti ograničen različitosti sintakse!

Trim je u ovom primjeru samo predstavnik bilo koje metode koju uočavamo da smo je već standarizirali načinom korištenja. Tj. da se standarizirala potreba za njom.

Može li objašnjenje u čemu se tačno ogleda prednost ovog gore u odnosu na ovo dole? Koja je to superiorna karakteristika prvog citata koja izbjegava posljedicu u drugom citatu?

1 Like

Baš sam neki dan naletio.

@bozoou ovo rješava 100 % tvoje probleme na .netu, obratite se sa povjerenjem :smile::smile:
https://blazor.net/

Izgleda da Bozo nije jedini koji ima ovu ideju :grinning:

1 Like

Copyright © 2020 WM Forum - AboutContact - Sponsored by: Mydataknox & Webmaster.Ninja