znaczacy > comp.lang.* > comp.lang.javascript

Borys Pogorelo (23.03.2017, 22:47)
Dnia Thu, 23 Mar 2017 02:25:54 -0700 (PDT), zpksoft napisal(a):

> Ja dopracowalem sie wlasnych rozwiazan w tym zakresie które zaspokajaja
> w pelni moje potrzeby. Nawet myslalem, zeby spróbowac gdzies opublikowac
> to rozwiazanie tylko na razie nie mam pomyslu na to.


Github stoi otworem, spolecznosc oceni.
Cezary Tomczyk (24.03.2017, 10:53)
On 23/03/2017 21:46, Borys Pogorelo wrote:
> Dnia Thu, 23 Mar 2017 10:41:11 +0100, Cezary Tomczyk napisal(a):
>>> A jaki miales problem z Gulpem? Grunt faktycznie nie jest zbyt elastyczny z
>>> uwagi na deklaratywne podejscie, ale w Gulpie mozesz napisac prawie
>>> wszystko, to w koncu zwykly JS + strumienie.

>> No wlasnie dlatego, ze mam dostepny Promise, to Gulp nie jest mi potrzebny.

> A nie widze, bys go uzywal.


Nie. Aktualnie nie uzywam. A nawet przyznam sie, ze uzywalem Gulpa
bardzo króciótko i przy jednym projekcie. Grunt-a uzywalem przez kilka lat.

> Do tego to by jeszcze bardzo zaciemnilo Twoje
> rozwiazanie, zwlaszcza jakbys musial zsynchronizowac kilka promises.


Promise.all - to wszystko, co jest potrzebne i jest dostepne. Chyba, ze
myslisz o czyms innym.

> Nie wspominajac juz o zabawie z lapaniem wyjatków, itd. Ze strumieniami jest
> znacznie latwiej, do ich scalania i synchronizowania masz gotowe narzedzia,
> a ich uzycie to 1-2 linijki.


"catch" z Promise-a powinien pomóc. Niektóre npm moduly zwracaja Error
object.

>> To zadna kombinacja. Przypatrz sie temu dokladnie. Bierzesz pakiet npm i
>> uzywasz go calkiem normalnie: wejscie -> wyjscie.

> A po drodze odpalasz binarke CLI eslint, musisz ja skonfigurowac,
> samodzielnie obsluzyc bledy i do tego zupelnie nie widac, co jest wynikiem
> dzialania tej funkcji. Cos tam sobie leci w petli i nie bardzo wiadomo, co


A wrapper do G/G to jak dziala?

> sie dzieje i gdzie szukac efektów (co to jest "report" i jak go czytac? co
> to jest "formatter" i czemu pojawia sie dopiero na koncu, choc nazwa
> wskazuje na cos potrzebnego w trakcie procesu?). A calosc jest dluga na dwa


Wszystko jest opisane w dokumentacji:


> ekrany. To nie jest proste rozwiazanie. Idealizujesz je, bo jestes autorem.


Absolutnie nie idealizuje. Z reszta, nie wymyslilem niczego nowego.
Przykladowo eslint
korzysta z tego
samego podejscia do build-a.

Ba! Nawet z samego NPM-a mozesz korzystac:



> Proste rozwiazanie to jest wziac garsc plików, zlaczyc je w jeden strumien,
> wrzucic w eslint z konfiguracja i cos zrobic ze strumieniem wyjsciowym. I
> nie przejmowac sie zanadto obsluga bledów, bo robi to za nas narzedzie.


Jak masz proste kroki w buildzie, to wszystko sie zgadza. Jeszcze raz
podkresle - kazdy uzywa to, co jest dla niego najlepsze albo musi, bo
jest juz to w projekcie od jakiegos czasu. Jezeli laduje w projekcie z
G/G, to nie marudze tylko tego uzywam ;-)

A poza tym, zapominasz o innych argumentach. Przyklad:



>> Osobiscie, po jakims czasie doszedlem do wniosku, ze Grunt/Gulp za
>> bardzo ograniczaja mnie i w zasadzie zdefiniowanie i napisanie kroków do
>> build-a jest banalnie proste:

> Ja mam nieodparte wrazenie, ze gulpa nawet nie spróbowales na dobre, bo
> wczesniej stworzyles to swoje rozwiazanie.


Próbowalem, ale bardzo krótko i przy jednym projekcie. Z reszta,
przeszedlem na inne podejscie, które wedlug mnie, jest bardziej
elastyczne. Moze odrobine wiecej czasu zajmuje napisane zadania, ale nie
jest to tez az tak skomplikowane. Sadze, ze troche przesadzasz w druga
strone ;-)

>> 1. Definiujesz co chcesz osiagnac.
>> 2. Dobierasz sobie pakiet npm.
>> 3. Piszesz kilka linijek kodu, by przekazac parametry do pakietu npm i tyle.

> No popatrz, opisales gulpa ;)


:D

> Hint: nikt Ci nie broni uzywac pakietów npm w procesie gulpa. Prosciej
> jednak jest trzymac sie konwencji.


Trzymanie sie konwencji jest pewnym ulatwieniem w organizacji pracy, ale
jednoczesnie, osobiscie, nie wykluczam indywidualnego podejscia.
Wszystko zalezy od sytuacji i potrzeb.

>> * Usuwam niepotrzebna zaleznosc od Grunt-a/Gulp-a

> To nie jest argument.


W w/w linku sa podane argumenty, a ja takze podalem je w swoim artykule.

>> * Nie musze czekac, az autor pakietu dla Grunt-a/Gulp-a uaktualni mi go

> Pakiety npm tez nie zawsze sa aktualne.


Pewnie, ale pakiety dla G/G jeszcze bardziej ;-)

>> * Nie musze nic hackowac, bo albo korzystam z gotowych pakietów npm
>> (jesli sa wystarczajace), albo pisze sam.

> A czym jest hackowanie, jak nie tym ostatnim? ;)


Hack to obejscie. Ja niczego nie obchodze :-) Ot, korzystam z pakietów
npm i tyle.

> Nawiasem mówiac pakiety gulp nie sa jakies przesadnie skomplikowane.
> gulp-babel to prosty wrapper na modul npm i wyglada tak:
>


No i teraz pytanie po co mi wrapper skoro moge skorzystac bezposrednio z
pakietu npm ;-)

>> * Do konkretnego zadania moge wybrac jakikolwiek pakiet npm, spelniajacy
>> moje wymagania. Majac Grunt-a/Gulp-a musze brac pod uwage to, ze pakiet
>> byl specjalnie dla G/G.

> Nie musisz, ale tak jest wygodniej.


No wiec najpierw musze znalezc cos, co zadziala z G/G, a jesli nie ma,
to pozostaje mi wlasne rozwiazanie, które potem musze podpiac pod G/G.

>> Do minusów:
>> * Trzeba przeczytac i zrozumiec kod :D
>> * Wiecej nie pamietam, ale mozesz dopisac kolejne punkty tutaj ;-)

> * Tworzysz rozwiazanie in-house, z którym musisz sobie radzic sam


I tak, i nie. Po mojej "in-house" stronie jest tylko to, co ja
napisalem. Reszta to pakiety npm. Tak, czy inaczej, wsparcie community jest.

> * Musisz w wielu miejscach wynajdowac kolo na nowo


Nie bardzo wiem, co takiego musze wynajdowac na nowo.

> * Uzyskujesz strasznie rozwlekly kod, bo patrz wyzej


Nie powiedzialbym, ze rozwklekly, ale ok. Za to mam pelna kontrole i
swobode nad tym, co okreslone zadanie ma robic. Poza tym, build piszesz
raz i dziala latami. Nie trzeba do tego codziennie zagladac, jak do
zródel aplikacji ;-)

>>> Widze, ze w komentarzach Ci napisali w sumie to samo ;)

>> Zdania sa podzielone i to jest normalne. Nie oczekuje tego, iz G/G
>> zostanie porzucony czy nagle wszyscy przestana z tego korzystac.
>> Zaprezentowalem swój punkt widzenia.

> Na blogaskach generalnie wypada chwalic w komentarzach, nawet takie
> wynaturzenia jak JSS ;)


:-)

Jednym z plusów takiego rozwiazania, o którym napisalem, jest brak
zaleznosci od konkretnego rozwiazania do builda.

Przy okazji, przypomina mi sie sytuacja historycznie:

* Grunt - tego teraz uzywamy.
* Gulp - Grunt juz je be, teraz Gulp jest super.
* Browserify - nie znasz? Teraz to jest na topie :-)
* Webpack - nie, juz Browserify nie jest dobre.
* Rollup () - teraz Rollup musi byc najlepszy.

Ja wiem, ze sa roznice w tym, co one potrafia, ale to juz inna bajka.
Jivanmukta (01.04.2017, 07:16)
Jivanmukta wrote:
> Problem zamkniety. Dzieki za pomoc.


Jeszcze cos mi nie dziala. Nie rozumiem dlaczego kod:

<input type="text" name="client_mobile1" value="" id="client_mobile1"
maxlength="16" size="16" style="width: 16ex" class="mobile" >

p = document.getElementById("client_mobile1");
if (!p.hasOwnProperty("className")) alert(p.tagName + "#" + p.id + " has no
className");

wyswietla mi alerta: INPUT#client_mobile1 has no className. Uzywam FireFoxa,
ale chcialbym zeby mi dzialalo pod wszystkimi popularnymi przegladarkami.
PawelS cbrbob(at)wbcd(dot)pl (02.04.2017, 11:35)
Wojciech Bancer pisze:
> On 2017-03-17, PawelS cbrbob(at)wbcd(dot)pl <fake> wrote:
> [...]
> Konkretne biblioteki/frameworki maja opisane wsparcie na konkretnych

Czytam. "wsparcie dla przegladarek uzywanych glównie przez ich autorów",
No Comment.

> przegladarkach. Wlasnorecznie dziergany kod nie ma takiego wsparcie i musi byc
> wlasnorecznie wytestowany.

Zgadza sie, tak jak to juz wczesniej / pózniej napisano,
do tego swojego kawalka kodu równiez mam kilka róznych testów napisane.
Niewatpliwie jednak wszystkich mozliwych przypadków nie sprawdzilem,
Biblioteki uzywane przez wieksza grupe osób z pewnoscia
zostaly sprawdzone w duzo wiekszej ilosci przypadków,
wiec prawdopodobnie wiekszosc bledów w nich zostala naprawiona.

> Na 1000 przypadków bledów moze jeden bedzie bledem frameworka, a nie programisty.
> Wiec jeszcze raz, czemu mam bardziej ufac komus kto nie chce uzyc frameworka,
> niz zespolowi ludzi który poswieca mnóstwo czasu i wiedzy by dopracowac jakies
> narzedzie? Bo ten jeden programista uwaza ze jest bardziej nieomylny? :)

Jak chce usmazyc sobie jajecznice do ide do kuchni,
nie musze otwierac marnej jakosci stronki
z tona frameworków, których inicjalizacja i dzialanie,
nawet na calkiem mocnych maszynach powoduje widoczny freeze przegladarki.

Przeczytaj uwaznie kilka razy to co sam napisales
oraz to co ja napisalem (to moze kiedys zrozumiesz).
Nigdzie nie napisalem ani nie zachecalem bys uzywal tego co ktos napisal,
zamiast powszechnie stosowanych frameworków. Uzywaj tego co chcesz.
Co najwyzej podkreslam, ze do prostych operacji, by np: zrobic focus()
na polu tekstowym oraz ustawic background na czerwono
(a po 5 sekundach usunac ten czerwony background),
nie sa potrzebne zadne biblioteki, sam JavaScrit wystarczy.
PawelS cbrbob(at)wbcd(dot)pl (02.04.2017, 11:41)
Cezary Tomczyk pisze:
> On 17/03/2017 22:11, Wojciech Bancer wrote:
> Wlasnorecznie dziergany kod, tak jak i biblioteki czy frameworka,
> powinien zawsze miec unit testy + idealnie e2e testy.
> Cos odnosze wrazenie, ze nikt tutaj nie deprecjonuje znaczenia
> frameworków, a jedynie watpliwe korzystanie z wszystkiego, jak leci.


DOKLADNIE
nic dodac, nic ujac,
Rozumiem stosowanie frameworków przy pisaniu zaawansowanych aplikacji w JS,
która prawie dziala jak aplikacja na Desktopie, po zaladowaniu sie,
dalsza komunikacja z serwerem odbywa sie juz poprzez XMLHttpRequest().
Proste akcje typu focus() na danym polu lub wyswietlenie komunikatu,
mozna zrealizowac w samym JS i zadziala to w wiekszosci przegladarek.
[..]
Wojciech Bancer (02.04.2017, 16:43)
On 2017-04-02, PawelS cbrbob(at)wbcd(dot)pl <fake> wrote:

[...]

> Przeczytaj uważnie kilka razy to co sam napisałeś
> oraz to co ja napisałem (to może kiedyś zrozumiesz).


Ile Ty masz lat, że stosujesz tekst na poziomie przedszkola?
Serio nie jest Ci głupio?

> Nigdzie nie napisałem ani nie zachęcałem byś używał tego co ktoś napisał,
> zamiast powszechnie stosowanych frameworków. Używaj tego co chcesz.
> Co najwyżej podkreślam, że do prostych operacji, by np: zrobić focus()
> na polu tekstowym oraz ustawić background na czerwono
> (a po 5 sekundach usunąć ten czerwony background),
> nie są potrzebne żadne biblioteki, sam JavaScrit wystarczy.


Ani do tego, ani do tego nie trzeba Javascriptu.
Żeby zrobić focus wystarczy atrybut html, a do zmiany koloru tła
wystarczy animacja CSS.

Biblioteki nie są *potrzebne* do niczego, przecież o tym pisałem
wyraźnie. Za to ułatwiają pracę w grupie, standaryzację i pracę
jako taką i to poważnie. Tylko aby to docenić, to trzeba w życiu
napisać trochę więcej niż "proste rzeczy".
PawelS cbrbob(at)wbcd(dot)pl (11.04.2017, 20:43)
Wojciech Bancer pisze:
> On 2017-04-02, PawelS cbrbob(at)wbcd(dot)pl <fake> wrote:
> [...]
>> Przeczytaj uwaznie kilka razy to co sam napisales
>> oraz to co ja napisalem (to moze kiedys zrozumiesz).

> Ile Ty masz lat, ze stosujesz tekst na poziomie przedszkola?
> Serio nie jest Ci glupio?


Tak, jest mi glupio, ze w ogóle Tobie odpisalem.
Zgodnie z Twoim domniemanym zyczeniem:
EOT

> Ani do tego, ani do tego nie trzeba Javascriptu.
> Zeby zrobic focus wystarczy atrybut html, a do zmiany koloru tla
> wystarczy animacja CSS.


Chyba, nie zrozumiales, animacja CSS
prawdopodobnie nie zrealizujesz powyzszego,
ale tak jak wyzej napisalem ... EOT
[..]
zpksoft (12.04.2017, 20:44)
W dniu wtorek, 11 kwietnia 2017 20:43:31 UTC+2 uzytkownik PawelS cbrbob(at)wbcd(dot)pl napisal:
> Wojciech Bancer pisze:
> Tak, jest mi glupio, ze w ogóle Tobie odpisalem.
> Zgodnie z Twoim domniemanym zyczeniem:
> EOT
> Chyba, nie zrozumiales, animacja CSS
> prawdopodobnie nie zrealizujesz powyzszego,
> ale tak jak wyzej napisalem ... EOT


Niepotrzebne sa te przytyki Panowie.

A tak z ciekawosci spytam: jaki to atrybut html wystarcza do zrobieniafocusu?
Oczywiscie mam na mysli aplikacje www, czyli focus na zyczenie programisty :)

Pawel
Wojciech Bancer (12.04.2017, 20:56)
On 2017-04-12, zpksoft <zpksoft> wrote:

[...]

> A tak z ciekawości spytam: jaki to atrybut html wystarcza do zrobienia focusu?


W wielu przypadkach jest to autofocus (html5).

> Oczywiście mam na myśli aplikację www, czyli focus na życzenie programisty :)


A to jakieś atrybuty są dopisywane nie na życzenie?
zpksoft (12.04.2017, 21:29)
W dniu sroda, 12 kwietnia 2017 20:56:12 UTC+2 uzytkownik WojciechBancer napisal:
> On 2017-04-12, zpksoft <zpksoft> wrote:
> [...]
> W wielu przypadkach jest to autofocus (html5).
> A to jakies atrybuty sa dopisywane nie na zyczenie?
> --
> Wojciech Bancer
> wojciech.bancer


Jezeli przy pomocy ajaxa laduje dialog do np. jakiegos diva to autofocus nie dziala. Dziala przy ladowaniu strony. Ale to juz nie jest ajax skoro musimy dla wywolania wlasnegodialogu przeladowywac strone.

Wydaje mi sie ze bez odrobiny JS sie nie obejdzie object.focus();

Pawel
PawelS cbrbob(at)wbcd(dot)pl (21.04.2017, 19:58)
zpksoft pisze:
> W dniu sroda, 12 kwietnia 2017 20:56:12 UTC+2 uzytkownik Wojciech Bancer napisal:
> Jezeli przy pomocy ajaxa laduje dialog do np. jakiegos diva to autofocus nie dziala. Dziala przy ladowaniu strony. Ale to juz nie jest ajax skoro musimy dla wywolania wlasnego dialogu przeladowywac strone.
> Wydaje mi sie ze bez odrobiny JS sie nie obejdzie object.focus();


Dziekuje za doprecyzowanie. Dokladnie o takiej sytuacji napisalem.
Strona zostala zaladowana, teraz ktos kliknal w element
wizualnie przypominajacy Button, ale nie wypelnil niezbednego pola,
wtedy pojawia sie window.alert() z informacja,
nastepnie jest FORM.ELEMENT.focus(),
oraz dodatkowo na 5 sekund FORM.ELEMENT.backgroundColor na czerwowo,
Klikniecie innego elementu wymaga wypelnienia innego pola,
które jesli jest puste powoduje analogiczna sytuacje.

Byc moze HTML5 rozwiazuje powyzsze problemy,
ale niestety zapewne nie bedzie dzialac wszedzie.

Podobne wątki