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š.
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 . Samo velim…koje tu sve mogućnosti ima.
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.
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.
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.)
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. 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?
Poceli ljudi uvidjati da jedan dio toga ne valja ili veci dio.
Izmislili ljudi funkcionalno programiranje, koje bas i nije prihvaceno u 21.st, izmislili objektno programiranje da se rijese problemi koje su imali kod proceduralnog programiranja, iako je c jos uvijek kao jezik dosta koristen.
Onda njim nije bilo dovoljno OOP, pa su izmislili design patterne da se uvede reda. Ni to nije bilo dovoljno pa su postale popularne razno razne arhitekture kao mvc, mvvm i sl, nadalje, ekipi ne valja sql, pa izmisljaju orm i sl.
Ni to nije bilo dovoljno, pa se izmislilo domain driven development i hrpa slicnih arhitektura, i sad sve dalje, sve se vise komplicira.
Da se odma ogradim, ucim design patterne, znam OOP, proucavam domain driven development itd.
Npr. Sto se tice JS i ostalog, najradije bi za projekte koristio cisti JS.
Ponovit ću samo najbitnije.
Kada se izvede na dobar način validacija standarda tih konponenti koje treba standarizirati, onda će to biti cross browser kompatibilno bez specijalnog angažmana od strane browsera, što trenutno nemamo.
A da je potrebno, sigurno da je potrebno…štoviše, neizbježno je… vrijeme će pokazati.
. Samo velim…koje tu sve mogućnosti ima. 
