- Brogyi: CTEK akkumulátor töltő és másolatai
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Asszociációs játék. :)
- Elektromos rásegítésű kerékpárok
- gban: Ingyen kellene, de tegnapra
- Azonos árketegóriájú (105-110.000 Ft-os) relatív olcsó telefonok kamerái
- Pajac: tpm.msc
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Szevam: „Rendszerleállás” – egy AI képzeletbeli halál utáni élménye
- Parci: Milyen mosógépet vegyek?
-
LOGOUT
JavaScript != Java (A JavaScript nem összekeverendő a Javával, két különböző programozási nyelvről van szó!)
Új hozzászólás Aktív témák
-
#4900
Sk8erPeter
nagyúr
Mentiii
#4899
Sk8erPeter
nagyúr
válasz
Mentiii
#4899
üzenetére
Persze, megoldható. Az onbeforeunload eseménykezelőjében egyből visszatérsz, ha bizonyos feltételek nem teljesülnek. A példában null-lal tértem vissza, de az implicit undefined-dal való visszatérés is jó lenne, számomra ez így egyértelműbb, és működik az összes népszerű böngészőben, IE9-től kezdve legalábbis biztosan. Ha az egész megerősítős mókát csak akkor szeretnéd aktiválni, ha be van jelentkezve a felhasználó, akkor először is megvizsgálod, hogy be van-e jelentkezve, és ha igen, csak akkor iratkozol fel eseménykezelővel az onbeforeunload eseményre - vagy magában az eseménykezelőben is vizsgálhatod a feltételt, ez egyéni döntés kérdése.
Jelen esetben a document.activeElementnek vizsgáltam a tagname attribútumát, hogy amennyiben az egy <a> tag, akkor anchorró/linkről van szó, arra kattintva váltódott ki az esemény. Emlékeim szerint ez ilyen esetben simán megfelelő lehet.Itt a demo:
https://jsfiddle.net/9eb5p6o6/1/ -
Mentiii
tag
Hellótok!
Szeretnék csinálni egy kilépés megerősítés popup ablakot a wordpress oldalamra, amire meg is találtam a megoldást itt: [link]
A baj az, hogy minden alkalommal megkérdezi (mindegy, hogy X-re vagy linkre kattintok
).Nekem olyanra lenne szükségem, ami a linkekre kattintva nem jelezne.
Továbbá valahogyan megoldani azt, hogy csak azoknak ugorjon elő ez a megerősítő ablak, aki be van jelentkezve
Szerintetek megoldható?
-
tick
aktív tag
Ezer és egy éve hoztam létre utoljára authentikációt és akkor is csak PHP-ben sessiont használva. Még nem tiszta hogy milyen adatot tud küldeni a kliens (user és pass kivételével) amiből a szerver tudja hogy a: ki az user; b: be van jelentkezve; c: valóban a megfelelő személyről van szó (pl nem egy lemásolt cookie);
Utána fogok nézni a javaslatoknak. Köszönöm mindenkinek -
martonx
veterán
válasz
Cathfaern
#4892
üzenetére
"NodeJS-en alapból nem lenne session" - persze nem is alapból van benne Session, pontosabban nem magában a NodeJS-ben, de feltételeztem, hogy ha valaki komolyabban veszi a NodeJS-es irányt, akkor azon is elkezd framework-öket használni.
Azokban pedig, ahogy most gyorsan utána gugliztam valóban van Session / Authentikáció kezelés. Más kérdés persze, hogy ennek a fizikai megvalósulása mennyire egyezik meg a "klasszikus" Session + authentication cookie-s megoldással, de funkcionalitását tekintve végülis megegyeznek. -
Cathfaern
nagyúr
De miért akarsz kliens oldalon jelszót tárolni?
Felhasználó bejelentkezik => szerver oldalon (akár db-ben) eltárolod, hogy a X user bejelentkezett 2015.02.12 8:30-kor. Legközelebb ha X user kérést indít hozzád, akkor megnézed, hogy mikor jelentkezett be utoljára. Ha ez régebbi, mint az eltárolt idő + 30 perc, akkor újra kérsz tőle jelszót. Amit írsz az ugye arra jó, hogy ne a user id-ját tárold le, hanem generálj egy egyedi azonosítót, ami minden bejelentkezéskor megváltozik.
Vagy arra hogy már bejelentkezéskor se kelljen jelszót küldeni (sose utazzon csomagban jelszó), nem vagyok benne biztos, hogy melyik verziót írod.martonx:
Igazából nem lepne meg, ha NodeJS-en alapból nem lenne session (fél perc googlizás ebben meg is erősített). Ugye a NodeJS alapból arra lett kitalálva, hogy egyszerűen és könnyen lehessen API-kat gyártani. Ahhoz pedig nem kell session. -
tick
aktív tag
Sziasztok,
Node-on futó API-t szeretnék létrehozni. Ezzel nem is lenne probléma, ott akadok el, hogy authentikáció után nem tudom megtartani az usert. Van valami PHP Session szerű megoldás? Nem szeretnék cookieban jelszót tárolni, még enkriptálva sem.Olvastam szép megoldásokat, hogy a jelszó soha (authentikáció után) ne legyen elküldve, helyette egy publikus kulcs, értékként pedig valamilyen azonosító. Kliens oldalon az adatok halmazából (beleértve a jelszavat) checksumot készíteni, majd mindent (jelszó kivételével) elküldeni (post/get/etc). Szerver oldalon a fogadott adatokból és a tényleges jelszóból egy új checksum, ha a kettő egyezik, akkor mehet a response.
Ez szép, okos és praktikus, de még mindig nem tudom hogy tároljam kliens oldalon a jelszót úgy, hogy azt egy általános iskolás srác ne tudja kiszedni.Bármi útbaigazítást köszönök előre is (akár kulcsszó, cikk, prezi)
-
#4889
daninet
veterán
Sk8erPeter
#4888
daninet
veterán
válasz
Sk8erPeter
#4888
üzenetére
nagyon köszönöm
-
#4888
Sk8erPeter
nagyúr
daninet
#4887
Sk8erPeter
nagyúr
válasz
daninet
#4887
üzenetére
Van ez a rész:
jQuery.colorbox({
overlayClose: true,
opacity: 0.5,
width: '600px',
height: '150px',
href: false,
html: json['success']['message']
});egyszerűen ezutánra dobd be ezt:
window.setTimeout(function () {
jQuery.colorbox.close(); // rövidebben: $.colorbox.close(); (de a konzisztencia kedvéért maradt ez is jQuery-vel kezdődő)
}, 3000);Ez így működni is fog.
Korábbi bedobott kódot átalakítva: http://jsfiddle.net/eyza6aw8/1/ -
#4887
daninet
veterán
Sk8erPeter
#4883
daninet
veterán
válasz
Sk8erPeter
#4883
üzenetére
Megtaláltam hova kellene begyógyítani ez a sort, de az elégtelennél is kevesebb ismeretemmel nem tom megoldani.
[link]
Egy kis segítséget megköszönnék
-
#4885
adam_
senior tag
Sk8erPeter
#4878
adam_
senior tag
válasz
Sk8erPeter
#4878
üzenetére
Köszönöm szépen a tanácsokat!
Egy másik kérdés: Azt mivel lehet megoldani, ha pl. kicsinyítem a böngésző méretét, tegyük fel, hogy pl. csak tablet nézetnél aktíválódik egy JQuery. Pl. hasonlóképp mint itt a jobb felső sarokban a menü? Szintén waypointssal?
-
#4884
daninet
veterán
Sk8erPeter
#4883
daninet
veterán
válasz
Sk8erPeter
#4883
üzenetére
ejj mindig ezek a problémák
akkor túrom még kicsit a kódot -
#4883
Sk8erPeter
nagyúr
daninet
#4882
Sk8erPeter
nagyúr
válasz
daninet
#4882
üzenetére
Pedig műxik az: http://jsfiddle.net/eyza6aw8/
Szóval ennyi alapján nehéz lesz kitalálni, nálad miért nem működik... -
daninet
veterán
Sziasztok!
A javascript kicsit kiszalad a tudáskörömből, szeretnék némi segítséget kérni.
Colorbox-ot használok, és szeretném ha egy ablak bezáródna 3mp után. Így néz ki az üzenet:$message = '<div>' . sprintf(JText::_('MESSAGE'), $viewProductLink, $product->product_name, $viewCartLink, 'jQuery.colorbox.close();', $viewCheckoutLink) . '</div>';
$json['success']['message'] = $message;Próbáltam ezt de nem csinált semmit, szerintem nem jól alkalmaztam:
window.setTimeout(function() { $.colorbox.close(); }, 3000);Bárminemű segítséget megköszönök
-
#4879
Jim-Y
veterán
Sk8erPeter
#4878
Jim-Y
veterán
válasz
Sk8erPeter
#4878
üzenetére
+1
Nem is értem -őszintén-, hogy mi visz rá valakit, hogy ne angolul programozzon. Attól még a termék/oldal nyílván lehet német, olasz, vagy akármi. Aki így tesz annak nem tűnik fel, hogy a
function
for
switch
new
..stb
sem németül, olaszul, egyéb nyelven van? -
#4878
Sk8erPeter
nagyúr
adam_
#4874
Sk8erPeter
nagyúr
"cookiesokkal"
Ez picit furán hangzik.
Az egyesszám a cookie. Akkor már cookie-kkal. Nem tudnád ezt a kódot úgy mellékelni, hogy a gomboknak legyen már felirata, a képek helyén meg legyen ott valami kitöltő kép?
Kitöltő képek:
http://lorempixel.com/
http://placehold.it/
stb.A gombok meg legyenek ellátva valami segítő szöveggel például az accessibility miatt. Például egy keresőrobot vagy egy screenreader sem igazán tud mit kezdeni az üres értékekkel ellátott gombjaiddal.
Aztán ezeket a korábbi tanácsokat megfogadhatnád (tele van ezekkel a hibákkal a kódod, most még több ilyen jellegű hibával is, mint korábban, amire írtam ezeket), plusz ami a mostani kódodban még extraként nagyon gáz, hogy tele van okádva a kódod ilyenekkel:<script>
$('#zoom_01').elevateZoom({
easing: true
});
</script>
......
<script>
$('#zoom_02').elevateZoom({
easing: true
});
</script>
......(A pontok helyén folytatódik a kód.)
Ez iszonyatosan béna, pont arra találták ki az osztályokat és a selectorokat, hogy általánosan lehessen hivatkozni alapvetően azonos jellemzőkkel bíró elemekre.Ennek a függvényednek nem sok értelmét látom:
function entfernCookie() {
document.cookie = "cookiesEuro=" + cookiesEuro;
"path=/; expires= 0";
document.cookie = "cookiesChocMenge=" + cookiesChocmenge;
"path=/; expires= 0";
document.cookie = "cookiesLieferung=" + cookiesLieferung;
"path=/; expires= 0";
alert("Sie haben alle Cookies erfolgreich gegessen! :)\nSie können es mit Cookies-Status-Button kontrollieren.")
}Az "entfernen" tudtommal azt jelenti, hogy eltávolítani, akkor itt miért is adsz háromszor is tök különböző értéket a document.cookie-nak?
Aztán az objektumos résznél:
var cookies = {
.........
cookies : document.cookie,
.........
entfernCookie : function () {
cookies.document.cookie = "cookiesEuro=" + cookies.cookiesEuro ; "path=/; expires= 0";
cookies.document.cookie = "cookiesChocMenge=" + cookies.cookiesChocmenge ; "path=/; expires= 0";
cookies.document.cookie = "cookiesLieferung=" + cookies.cookiesLieferung ; "path=/; expires= 0";
},
...............Ennek a cookies.document.cookie-nak semmi értelme, ne csodálkozz, hogy ez nem is működik.
"Viszont nekem most perpill németbe kell ezt megírnom a beadandóm miatt"
Lehetne a kurzus nyelve akár szuahéli is, tök mindegy, a programozás nyelve az angol. A kommentjeid akár lehetnek azon a nyelven, amit preferálsz (bár a nemzetközi csapatmunkát ez is nehezíti - nem kell igazán komoly projektekre sem gondolni, elég egy GitHubon megosztott open source projektecske, amit a nagyközönség elé társz), de a változóneveknek, attribútumértékeknek, id-knak, egyebeknek angol nyelven kellene szerepelniük. Csak jótanács. (#4875):
"nem szeretnék más editort használni, mert nagyon megszerettem már a Notepadet"
Majd rájössz. -
adam_
senior tag
Notepad++ -hoz létezik normális plugin projektek kezelésére?
Itt írnak egy bizonyos NPP-ről, de egyik link sem aktív már nálam, vagyis épkézláb megoldást még nem találtam. Ez miatt pedig nem szeretnék más editort használni, mert nagyon megszerettem már a Notepadet.
Van valami aktuális megoldás a témára?
Előre is köszönöm,
Ádám
-
adam_
senior tag
Közben sikerül a cookiesokkal megoldani az adatok rögzítését, amely a honlap elhagyása után következik be. Erre első körben három funkciót írtam (cookies létrehozása, cookies törlése, és cookies megjelenítése), ezek működnek is, viszont az itt mellékelt kódban, a Cookies wie Object komment után a kódban megpróbáltam összehozni egy objektbe a három funkciót, de valamiért úgy nem megy, ezért egyenlőre kikommenteltem. Kérlek ránézne közületek valaki, hogy miért nem megy objektben a három funkció?
Valamint a Cookies bei Neuladen komment után a kódban kísérletet tettem arra, hogy a lementett cookiekat, ha az oldalra visszatér a felhasználó, a kosár tartalmak továbbra is megmaradjanak, viszont ezt egyenlőre csak console.loggal teszteltem, ott persze nem ad vissza eredményt...
Nagyon szépen köszönöm a tanácsokat előre is,
Ádám
Ui: Ha valakinek problémás lenne a német miatt, kérlek szóljatok, és részletezem az adott sort, ha valamely változó, komment ... nem lenne érthető. Viszont nekem most perpill németbe kell ezt megírnom a beadandóm miatt.
Sk8erPeter: Közben pont nézem a kommented, köszi szépen a hasznos tanácsokat. Igyekszem még átvariálni a kódot.
-
#4873
Sk8erPeter
nagyúr
adam_
#4871
Sk8erPeter
nagyúr
"A jelenlegi tanárommal erről beszélgettem, szó volt a local/sessionStorage lehetőségéről is. Azt mondta, hogy elsősorban ezek a módszerek az IE-nél nem alkalmazhatóak, ezért jobb módszer lehet a cookies az adatok tárolására."
Hát a tanárod akkor kissé le van maradva, vagy megmaradt az IE6/7-re fejlesztős korszakban (asszem 2015-ben ezt nyugodtan meghagyhatjuk egészen speciális (pl. vállalati) területek "kiváltságainak"), mert ahogy martonx már leírta, még az IE8 is támogatja a localStorage/sessionStorage használatát:
http://caniuse.com/#search=localStorage
http://caniuse.com/#search=sessionStorageSzóval hogy most cookie-t, localStorage/sessionStorage-ot használsz, azt ne támogatottság alapján döntsd el (hacsak nem akarsz még őskövület böngészőkre is fejleszteni), hanem az alapján, hogy melyikre van szükséged.
Pár gondolat:
- felesleges egyesével minden gombot külön-külön beregisztrálni egy eseménykezelőhöz id szerint, értelmesebb lenne valami általánosabb struktúrába szervezni, pl. hozzájuk rendelni egy osztályt, és pl. .querySelectorAll használatával kigyűjteni őket, végigmenni a listán, és hozzájuk csapni az eseménykezelőt (az elemen kiváltódó adott eseményre feliratkozni).
- az előzőhöz kapcsolódóan próbálj általánosabban gondolkodni, nem mindenhez bedrótozni az id-t, és aszerint végezni vele valamit (nyilván esetfüggő, lehet olyan elem, hogy csak és kizárólag ahhoz akarsz valamilyen viselkedést rendelni), mert ez nehézkessé teszi a kódodat, nehezebben tudsz azonos viselkedésű elemeket lazán hozzáadni a HTML-kódhoz anélkül, hogy a JavaScript-kódot módosítanod kéne
- JavaScript-kódba nem írunk CSS-kódot! Tehát a stílust nem szabad JavaScriptből definiálni, hogy ilyen kerete legyen, olyan színe, stb., hanem erre szépen létre kell hozni egy CSS-osztályt, és magát az adott class-t az elemhez hozzáadni vagy épp levenni róla szükség szerint. Pl.:
http://stackoverflow.com/questions/2155737/remove-css-class-from-element-with-javascript-no-jquery/18492076#18492076
- most nem nagyon van időm leírni a hogyanját, de a kosárba pakolt elemeket tárolhatod egy változóban, úgy, hogy csak azok a függvények érjék el, akiknek szabad is, hogy hozzáférése legyen, tehát legyen egy kosárba hozzáadós, eltávolítós, adatfrissítős függvényed (meg ami még kellhet) - hogy hogyan rejtsd adott scope-ba, az nem feltétlenül kezdő feladat, de addig is megoldhatod sima globális változóval (de tudnod kell, hogy ez veszélyes módszer, mivel bárki hozzáférhet)
- lehetőség szerint kerüld el az ismétlődő metódushívásokat, értem ezalatt azt is, hogy a natív metódusokat hívogatod újból és újból adott kódban, mert egyrészt csak csúnya code bloat, másrészt plusz időt vesz igénybe ezek újbóli végrehajtása (még ha nem is dob észrevehetően a kód futási idején egy document.getElementById újbóli hívogatása - pl. az eseménykezelődben kétszer is szerepel a document.getElementById("zahlungsMethod"), pedig ezt elég lett volna egyszer leírnod, és eltárolni egy változóban, ez persze csak egy példa); szóval azt, amire később úgyis szükséged lesz újból, tárold el egy változóban"»» A kosárba pakolás során egy jó UI esetén nem frissül újra az egész oldal, mert tök felesleges.
Ezt nem teljesen értem, ezt "kódügyileg" hogyan képzeljem el?"
Úgy, hogy nem megakadályozod az alapértelmezett viselkedését az űrlapnak, hogy az adatok szerveroldalra küldésével együtt újrafrissüljön az egész lap, erre írtam már korábban az event.preventDefault()-ot például (van még az event.stopPropagation() is, de most egyelőre hagyjuk).Na most ennyire volt idő.
-
martonx
veterán
"Azt mondta, hogy elsősorban ezek a módszerek az IE-nél nem alkalmazhatóak"
Híjnye bakker, akkor sürgősen keress új tanárt, mert a session storage / local storage az egyetlen!!! HTML5-ös feature amit már az IE8 is támogatott. Az pedig akárhogy is nézem 6 évvel ezelőtt jött ki.
-
#4871
adam_
senior tag
Sk8erPeter
#4869
adam_
senior tag
válasz
Sk8erPeter
#4869
üzenetére
Másrészt nem perzisztens módon tárolod az adatokat, így érthető, hogy a lapújrafrissülések esetén minden elvész.
Tárolhatnád mondjuk sessionStorage-ben vagy localStorage-ben (hogy melyikben, az felhasználásfüggő) a kosár tartalmátA jelenlegi tanárommal erről beszélgettem, szó volt a local/sessionStorage lehetőségéről is. Azt mondta, hogy elsősorban ezek a módszerek az IE-nél nem alkalmazhatóak, ezért jobb módszer lehet a cookies az adatok tárolására. Próbálkoztam [link], hogy a végén kikalkulált értékeket átadom egy másik funkcióba cookiesba, közvetlen akkor amikor a user elhagyja az oldalt, így amikor majd később visszatér az oldalra, megmaradnak a kosárba pakolt dolgok, ha még nem véglegesítette a vásárlást. Egyenlőre a JSFiddlebe kikommenteltem a legvégéről a cookiesos részt, mert egyáltalán nem megy sajnos. Egyenlőre csak rögzíteni akarom az egyik funkcióba a kijött értékeket a másik funkcióba, a cookiekba, majd egy másik funkció törölni is tudja azokat (tervezek még egy harmadikat is, ami visszaolvassa majd, és ezt a három funkciónalítást mondjuk egy objektumba szeretném behelyezni majd a legvégén..) Rátudnál vezetni, hogy mit rontok el, egyáltalán ez a fajta megoldás is jó lehet/lenne? Szóval elsőkörben tanulásképp kliensoldalon szeretném megoldani az adatok eltárolását, majd ha már megy a JS jobban, akkor szeretnék szerveroldali tárolással is foglalkozni.
A kosárba pakolás során egy jó UI esetén nem frissül újra az egész oldal, mert tök felesleges.
Ezt nem teljesen értem, ezt "kódügyileg" hogyan képzeljem el?
HTML-kódba bedrótozott onclick-attribútumokat és társait pedig kerülni kell, szépen szeparáltan legyen a JavaScript-kódban az eseménykezelés, a kettő legyen jól elválasztva. .addEventListener() segítségével tudsz hozzáadni egy adott elemhez eseménykezelőt.
Most már a HTML kódom teljesen JS mentes, ahogy kell, viszont magát a JS kódon még egyszer átfutnál, és megmondanád, hogy te mit változtatnál rajta (elrendezés, vagy az egész felépítettsége), mert sajnos még erre nem éreztem rá igazán, hogy mikor szép/jó egy komplett szkript. Talán még jóópár projektet kell majd látnom ahhoz, hogy ezt érezzem. Mert sok kis apró dolgot külön funkciónalításokba (ha néha tákolmány is), de sikerül felépítenem, viszont így komplexbe a végén még van mit csiszolni rajta. Gondolok itt például olyanokra, hogy a változókat mikor deklarálom jól (etc. lokálisan, vagy publikusan), mindenre hozok létre külön funkciókat (bár lehetne egy komplex objektumba is ezeket belepakolni..stb..)
Még ezekhez jóó pár hónapot kell gyakorolnom gondolom, hogy átérezzem, mert minél több nüansznyi dolgot tudok, annál több mindent akarok belepakolni egy projektbe, és persze annál bonyolultabb perpill számomra.
Húh ez sok volt, de kíváncsi vagyok a véleményedre.
Ádám
-
#4869
Sk8erPeter
nagyúr
adam_
#4868
Sk8erPeter
nagyúr
Tudok németül, szóval nekem nem gond, de annak, aki nem tud, idegesítő lehet. Mondjuk nekem is idegesítő még úgy is, hogy értem, mi van odaírva.
Az is szokott zavarni, ha valaki magyarul kódol (lehet sznobizmusnak tekinteni, de akkor is az az elfogadott szokás, hogy angolul kódolunk).Egyrészt jsFiddle-ön át kell kattintani "No wrap - in <head>"-re vagy "No wrap - in <body>"-ra a bal fölső panelnél. Ez azt határozza meg, hogy hova fogja beágyazni a JavaScript-kódot a <script>-tagekkel. Ha megnézed a böngésző webfejlesztő eszközeivel a generált kódot, akkor ezt pontosan tudod követni. De múltkor pontosan ugyanez volt, ami miatt nem működött nálad.
Másrészt nem perzisztens módon tárolod az adatokat, így érthető, hogy a lapújrafrissülések esetén minden elvész.
Tárolhatnád mondjuk sessionStorage-ben vagy localStorage-ben (hogy melyikben, az felhasználásfüggő) a kosár tartalmát, itt egy egyszerű példa:
http://stackoverflow.com/questions/2010892/storing-objects-in-html5-localstorage/2010948#2010948Harmadrészt semmivel nem akadályoztad meg, hogy lapújrafrissülés történjen azonnal az alert után, akármi is volt az eredmény, például ha tök üresen hagyom a mezőket, kapok figyelmeztetést, de ettől még megköszönöd szépen a rendelést, aztán el is mennek az adatok szerveroldalra.
Itt ráadásul tök felesleges minden alkalommal alerttel megköszönni a rendelést, hiszen még meg sem rendeltem, csak kosárba pakoltam.A kosárba pakolás során egy jó UI esetén nem frissül újra az egész oldal, mert tök felesleges. Az egyéni döntés kérdése, hogy a kosár tartalmát el akarod-e küldeni szerveroldalra is, vagy csak kliensoldalon tárolod. A szerveroldal mellett az szól, hogy eltárolhatod későbbre is a kosárba pakolt tartalmat, és akárhol máshol jelentkezik be, akkor megint előkotorható a korábbi kosártartalom, hogy mondjuk később folytatni tudja a vásárlást. De legtöbbször csupán kliensoldalon intézik el az egész kosárba pakolgatást, az adatok tárolását, például az előbb említett módszerekkel.
Az űrlap elküldését pedig az eseménykezelőben kell megakadályozni. Például event.preventDefault() segítségével.
A HTML-kódba bedrótozott onclick-attribútumokat és társait pedig kerülni kell, szépen szeparáltan legyen a JavaScript-kódban az eseménykezelés, a kettő legyen jól elválasztva. .addEventListener() segítségével tudsz hozzáadni egy adott elemhez eseménykezelőt. Példa (a többi hibát nem javítottam, csak ezt szemléltetem!): http://jsfiddle.net/r4s0ef87/2/ -
#4868
adam_
senior tag
Sk8erPeter
#4866
adam_
senior tag
válasz
Sk8erPeter
#4866
üzenetére
Elnézést, javítottam, mellékelve ezúton html is. Bár fiddleben egyáltalán nem megy a script úgy nézem...
most az van, hogy egyszerűen adott mezők alapján kiszámolsz kosárba pakolandó értékeket, megjeleníted őket, de ha módosul az űrlap, nem tudod utólag kideríteni, hogy a vásárló milyen termékeket is rakott be a kosárba?
Igen, jól gondolod. És valamiért a végén az alert ablak "leokézása" után elveszik minden, holott én a végén a bevitt értékeket (etc. megvásárolt termékek adatait (darabszám, fizetési mennyiség, áruk...) meg szeretném jeleníteni a honlapon, továbbra is a "result" divben / és paralell az eredetileg kiírt kosár résznél is.
Legközelebb ígérem angolba írom, és ha most végképp nem megy az értelmezés átírom az egészet angolra, azon ne múljon.
-
#4866
Sk8erPeter
nagyúr
adam_
#4864
Sk8erPeter
nagyúr
Semmilyen HTML-kódot nem mellékeltél hozzá, azt sem írtad le, hogy egyáltalán mikor hívódik meg a függvény, minek kellene történnie, nem értem, milyen módon szeretnéd változókban tárolni a kiszámolt értékeket (mert nem tudni, mi a cél).
De megpróbálom valahogy értelmezni: most az van, hogy egyszerűen adott mezők alapján kiszámolsz kosárba pakolandó értékeket, megjeleníted őket, de ha módosul az űrlap, nem tudod utólag kideríteni, hogy a vásárló milyen termékeket is rakott be a kosárba?Amúgy lehetőleg angol változóneveket használj, angolul programozz, simán azért, mert ez a bevett és elfogadott szokás, a programozás (és általában az informatika) nyelve angol, akár tetszik, akár nem.
Nem beszélve a csapatmunka lehetőségeiről, amit így korlátozol. Ha odaadod vagy megmutatod ezt a kódot olyannak, aki nem tud németül, az esélyes, hogy meg sem próbál elgondolkozni rajta, vagy pedig anyázni fog. -
adam_
senior tag
Sziasztok!
Az alábbi kóddal kapcsolatban lenne kérdésem. A kód szépen le is fut, ha a júzer kiválasztja az adott termékeket, szépen a skript összeadja az áraikat, darabszámát, extra szállításként hozzáadja az extra költségeket stb. A végén egy alert ablakban megjelenik, hogy köszönjük a rendelését, és a header jobb felső sarkába szépen ki is írja a kosár tartalmát. Viszont ha a júzer leokézza az alert ablakot, minden elveszik.
Ezt orvosolva szeretném a kiszámolt adatokat változókban tárolni, majd az alert ablak továbbléptetése után is megjeleníteni a megvásárolt termékeket, és a hozzá tartozó infókat (ár, darabszám...stb.) egy külön divben az oldalon (vagy ha már a kosár résznél az eredeti helyén a headerben megmaradna, már annak is örülnék) Erre tettem többek között próbálkozásokat a script alján, de valamiért továbbra sem megy, hogyan lehetne ezt orvosolni, mit rontok el?
Amúgy ha pl. a végéről az utolsó alertet kiveszem a scriptből, a kód egyáltalán nem fut le.
Esetleg külön kellene szednem a különböző funkciókat? Mit tanácsoltok?Előre is köszönöm a válaszokat,
Ádám
-
Zedz
addikt
Gulppal watcholtatok egy könyvtárat, amiben JSX fájlok találhatóak. Írtam egy olyan taskot, hogy fájl mentésekor a JSX fordítsa át plain JS-re a kódot. Olyan problémám van, hogyha a JSX fájlt úgy mentem el, hogy szintaktikai hiba van benne, akkor a Gulp leállítja a watch folyamatot, és sipákol, hogy gondok vannak. A sipákolása nem zavar, csak az, hogy ilyenkor indíthatom újra a watch-t.
Gruntban is így működik ez?
-
#4862
Jim-Y
veterán
fordfairlane
#4861
Jim-Y
veterán
válasz
fordfairlane
#4861
üzenetére
Akkor jo, bocs
-
#4860
Jim-Y
veterán
fordfairlane
#4858
Jim-Y
veterán
válasz
fordfairlane
#4858
üzenetére
Hat, ha most ez csak egy beszolas akart lenni a typo miatt, akkor arra nem tudok mit valaszolni
De tenyleg, akkor csak -.-Ha nem, hanem egy kerdes, akkor: http://jscoercion.qfox.nl/. Implicit type coercion-nek nevezik azokat a helyzeteket ahol a nyelv szemantikaja hatarozza meg a kiertekelendo kifejezes tipusat. Ilyen tipus kikovetkeztetes tortenik amikor valaki az == operatort hasznalja a === operator helyett. Ilyenkor a nyelv szabalyainak megfeleloen az egyik argumentumot mas tipusra konvertalja amit mar ossze tud majd hasonlitani a masik argumentummal. Ezek a szabalyok eleg bonyolultak, vagy nem is bonyolultak, de nehez megjegyezni oket, ezert nem szabad az implicit type coercion-re tamaszkodni, hanem mindenhol explicit megmondani, hogy mit szeretnenk.
Pl az x == null, nem csak azt ellenorzi, hogy az x az null-e, hanem egyben azt is ellenorzi, hogy undefined-e. Megsem ajanlott ezt irni, hanem explicit kiirni, hogy
if (x === null || x === void 0)
Mashol is elojon type coercion -> http://speakingjs.com/es5/ch08.html#type_coercion
-
#4859
Sk8erPeter
nagyúr
fordfairlane
#4858
Sk8erPeter
nagyúr
válasz
fordfairlane
#4858
üzenetére
Valószínűleg csak következetesen rosszul írja a "coercion" szót...
-
Jim-Y
veterán
válasz
martonx
#4856
üzenetére
Nem is kifejezetten neked cimeztem a valaszt, hanem ugy altalanossagban a temahoz. Legtobbszor en is olyanoktol olvastam az ilyen jellegu "cikkeket", akik egy kicsit sem konyitottak a temahoz, frissen talalkoztak a JS-el, majd szornyulkodve kezdtek azonnali posztolasba az ilyen frucsa viselkedesekrol. Onnan veszem, hogy akik ilyeneket irnak sokszor (nyilvan nem mindig) nem ertenek hozza, hogy altalaban el szoktam olvasni a hozzaszolasokat is, ahol mindig be szoktak nekik linkelni a referenciabol a coersion szabalyokat, es mindig az a valasz, hogy azt se tudtak, hogy van ilyen referencia
Meg hogy az X nyelvben amiben ok programoznak ez mennyivel logikusabb, es hogy pfuj.. na szoval az ilyenekre ezert nem adok sokat, sot egy kicsit engem is duhit, mert aki kezdo, az azt hiszi, hogy a nyelv egesz egyszeruen szarul mukodik, pedig nem igy van, csak furcsa konverzios szabalyai vannak. -
martonx
veterán
Én az egészet poénnak fogtam fel. Pont az a típusos programnyelveket kedvelő programozó vagyok, aki a javascriptet, php-t is kimondottan kedveli, napi szinten használja.
Ettől függetlenül mindig jót mosolygok ezeken az extrém konverziós példákon, nem cseszem fel magam rajtuk. -
#4855
fordfairlane
veterán
Sk8erPeter
#4854
fordfairlane
veterán
válasz
Sk8erPeter
#4854
üzenetére
Azon húztam fel magam, hogy kábé ötmillió ilyen vicces programozót láttam már, aki az implicit type konversion-on pojénkodott. Tipikusan valami erősen típusos nyelvet tanult meg először, és ez olyan meghatározó élmény volt az életében, hogy mást már elképzelni sem tud. Egyébként is idegesítő a sok félhülye degenerált, amelyik, mint az látszik, gépelni sem igen tud.
Crockfordtól elfogadom a Javascript kritikákat, egy ilyen porbafingó kis senkiházitól nem.
"ja, most nézem, valszeg a * helyett = jelet akart írni..."
Hát igen, kábé ez az a szint, amikor nem fogadom el, hogy őkelmének nem tetszik a Javascript.
-
#4854
Sk8erPeter
nagyúr
fordfairlane
#4853
Sk8erPeter
nagyúr
válasz
fordfairlane
#4853
üzenetére
Szerintem ezek pont nem annyira szórakoztató példák, de nem tudom, minek húzzátok fel magatokat ezen ennyire.
Legalább ilyenkor az ember elgondolkodik picit rajta, hogy mi miért is úgy működik (és itt speciel mindegyikre van elég gyors magyarázat, de ezt ti is vágjátok ), vagy épp lehet, hogy kicsit agyal, hogy ez így logikátlan, de az itteni példák erre nem túl jók. Egyszer linkeltem én is egy ilyet, amiben sztem ennél viccesebb példák voltak, gondoltam 1-2 perc agykikapcsolásnak jó lesz, és akkor engem oltottál le egészen érthetetlen stílusban, mai napig nem értem, miért: [link]. Itt még mindig megnézhető a videó: [link].
Itt szerintem a [] + [] === empty string, []+{} === [object Object], {} + [] === 0, {} + {} === NaN nem annyira kapásból rávághatóak, hogy miért is vannak így...Ja, viszont a twitteres példában a var x * 3; sort nem igazán értettem, mivel az nem túl meglepő módon SyntaxErrorhoz vezet, innentől kezdve az értelmetlen. Szerk.: ja, most nézem, valszeg a * helyett = jelet akart írni...
-
#4853
fordfairlane
veterán
martonx
#4851
-
Jim-Y
veterán
válasz
martonx
#4851
üzenetére
Mennyi ilyet lattam mar.. ilyenkor mindig az az erzesem, hogy ha valaki nem erti a nyelvet, akkor ne hasznalja, ha pedig ugy latja, hogy az implicit coersion-ok fuck logiccal mukodnek, akkor ne hasznaljon implicit coersion-t. Ezek a posztok egy az egyben polgarpukkasztasra mennek.
-
#4847
dqdb
nagyúr
Sk8erPeter
#4845
dqdb
nagyúr
válasz
Sk8erPeter
#4845
üzenetére
Igen, pontosan ez volt a javaslatom mögötti ötlet.
-
#4845
Sk8erPeter
nagyúr
Karma
#4843
-
#4840
dqdb
nagyúr
Sk8erPeter
#4837
dqdb
nagyúr
válasz
Sk8erPeter
#4837
üzenetére
Szerintem a topik címét kellene módosítani JavaScript/ECMAScript topikra, az ES megnevezés jelenléte eléggé jó szűrő lenne.
-
#4838
Zedz
addikt
Sk8erPeter
#4837
Zedz
addikt
válasz
Sk8erPeter
#4837
üzenetére
Csak honda meg ne lássa. Lenne itt olyan káosz.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#4837
Sk8erPeter
nagyúr
DNReNTi
#4836
-
#4836
DNReNTi
őstag
Sk8erPeter
#4835
DNReNTi
őstag
válasz
Sk8erPeter
#4835
üzenetére
"a mostani topiclogónál a Java (és nem JavaScript) gőzölgő kávéscsészéje van"
Nekem is pont ma tűnt fel. Még rá is kerestem hogy ez az offical, aztán kiderült elvileg nincs is neki. Hozzáteszem a keresési eredmények között többször megfordul a csésze. -
#4835
Sk8erPeter
nagyúr
Jim-Y
#4833
Sk8erPeter
nagyúr
Fú nem tom, számomra ezek a return console.error(...) és hasonló kerülő megoldások olyan metódusoknál, amik valójában nem adnak vissza semmit (OK, "implicite" undefined-ot adnak vissza, de érted), nagyon tákolásszagúak.
(még ha alkalmazzák is)
Semmi gond nincs egy egyszavas return; sorral sem. Igazából ha valaki lefelejti a returnt, akkor így is-úgy is lefelejti, szóval a két sor egybevonása sztem sok mindent nem old meg (bár lehet, hogy valakinek ad egyfajta megszokást, csak így meg ronda).Amúgy fura ez a figyelmeztetés, hogy a return false az event handlereknél deprecated, legalábbis ha a Reactet használod, kiíródik ezek szerint, ez nekem is új. (Szóval hogy explicite kell használni az e.stopPropagation() és/vagy e.preventDefault() metódusokat, simán a return false nem jó ezek helyettesítésére, hanem egyértelművé kell tenni a dolgot, hogy melyikre van szükséged.)
================
Más:
basszus, most látom, hogy a mostani topiclogónál a Java (és nem JavaScript) gőzölgő kávéscsészéje van, miért?
Így is eléggé keverik a JavaScriptet a Javával, adjuk alájuk a lovat? -
Jim-Y
veterán
De, a sima return-nek bőven van haszna, ugyanis a segítségével lehet idő előtt megszakítani a metódus interpretálását.
Ezek mind-mind ugyanazt eredményezik> (function(){ return void 0; })();
undefined
> (function(){ return; })();
undefined
> (function(){ return undefined; })();
undefined
> (function(){ return console.log('returned'); })();
returned
undefinedAnnyi, hogy az utolsó esetben egy kis "trükkhöz" folyamodunk, ezt általában node esetén használják, ugyanis ott van egy "error first"-nek nevezett stílus, így lettek a core modulok megírva. Ezt azt jelenti, hogy:
ORM.find({}, function successCallback(err, datas) {
if (err) {
console.error('Error happened, returning', err);
}
response.send(200, datas);
});Ez a példa hibás, ugyanis nem sikerült az adatbázisból való lekérdezés, hiba történt, így vissza kéne térni a függvényből, hogy a response.send ne futhasson le, ugyanis a datas adatoknak nincs értékük. Ezt kéne írni:
ORM.find({}, function successCallback(err, datas) {
if (err) {
console.error('Error happened, returning', err);
return;
}
response.send(200, datas);
});De az emberek sűrűn elfelejtik kiírni a return;-t így inkább ezt szokták javasolni:
ORM.find({}, function successCallback(err, datas) {
if (err) {
return console.error('Error happened, returning', err);
}
response.send(200, datas);
});==================================================
Amit a konzolban kaptál az pedig szerintem csakis annyiról szól, hogy az emberek ne a return false;-t használják az e.preventDefault() helyett.
-
-
Jim-Y
veterán
Szia, belinkeled légyszi, ahol ezt írták, hogy "elveszik a támogatottságát"? Furcsa lenne.. ez nem olyan amit ki lehet védeni.
Az event.preventDefault () és return false- ról egy csomó stackoverflow thread szól: pl, pl2
A return; így simán visszatér a hívóhoz egy undefined értékkel. JavaScriptben return-t írni a függvény végére azért nincs értelme, mert lexikálisan a záró kapcsos zárójel után amúgy is visszatér a vezérlés a hívóhoz, és JavaScriptben ha nincs explicit visszatérési érték megadva, akkor undefined lesz a visszatérési érték.
Egyébként ezzel a résszel nincs gond:
handleSubmit: function(e) {
e.preventDefault();
var author = this.refs.author.getDOMNode().value.trim();
var text = this.refs.text.getDOMNode().value.trim();
if (!text || !author) {
return;
}Egy eseménykezelőben sűrűn hívunk először egy prevDef-et, hogy a kilőtt event alapértelmezését felül tudjuk írni. A függvényből való vezérlésvisszaadás nem megfelelő értékek esetén is egy bevált gyakorlat.
-
Zedz
addikt
Sziasztok,
Forkolgatok pár apró dolgot a React segítségével, és egy olyan dologgal találkoztam amit nem teljesen értek.
Írtam egy egyszerű kódot, ami fogadja egy input értékét. Ha az inputot üresen küldték el, akkor return false-szal megszakítottam az adott function futását. Teszt során a log-ban viszont szólt maga a React, hogy a return false támogatottságát ki fogják venni a következő verzióból, így használjam inkább pl. a preventDefaultot.
Ezzel eddig nincs gond, megfogadtam a tanácsot, de érdekelt miért veszik el a támogatást? Az oldalukon is szerepel egy ilyen:
if (!text || !author) {
return;
}Utánanéztem de érdemli választ nem találtam, így gondoltam megkérdem itt.
+ Érdekes még számomra, hogy a function végén is ott szerepel magában a return; . Miért?
handleSubmit: function(e) {
e.preventDefault();
var author = this.refs.author.getDOMNode().value.trim();
var text = this.refs.text.getDOMNode().value.trim();
if (!text || !author) {
return;
}
this.refs.author.getDOMNode().value = '';
this.refs.text.getDOMNode().value = '';
return;
} -
adam_
senior tag
Napi humor?! Ha már volt, akkor bocs.
-
wis
tag
Azért nem működik, mert bár úgy tűnik, hogy globálisan hozod létre a függvényt a jsfiddle még belerakja egy onload-ba így az kívülről nem lesz látható. Ezt baloldalt lehet kikapcsolni.
Nyílván ez összefügg a visibility:hidden-nel
Ezt jól látod, még sem állítottad vissza visible-re.A regexnél match helyett test-t használd, az booleant ad vissza.
-
adam_
senior tag
Sziasztok! Egy sima validálós formot szeretnék létrehozni, ami ellenőrzi, hogy a nevek, valamint az e-mail mező kivan-e töltve, és hogy helyesen van-e kitöltve. Ehhez már csináltam egy scriptet. Itt található. Nem tudom, hogy miért nem működik JSFiddlleben, nálam a helyi gépen megy a script, szépen módosítgatja a div konténerben a szövegeket, és az alert ablak is felugrik amikor kell. Szóval most ezektől függetlenűl lenne két kérdésem. (Bár érdekelne, hogy JSFiddleben miért nem működik..)
Amikor egy / kettő esetleg mindhárom inputboxot nem töltik ki, alul szépen felugrálnak a hibaüzenetek, hogy "Tölts ki a kereszt / vezetéknevet / e-mail mezőket. Ha mindet kitölti, ez szépen el is tűnik, és a küldés gombra kattintva megköszöni a kitöltést. Viszont ha másodjára töltene ki a formon egy mezőt, és az egyik kimarad, akkor már nem írja ki a msg konténerbe a hibaüzenet. Nyílván ez összefügg a visibility:hidden-nel, de hogyan lehet elérni, hogy addig amíg másodjára se tölti ki szépen az összes mezőt, ne engedje elküldeni az adatokat?
A második kérdésem, pedig a kikommentelt regexekre vonatkoznak. Hogyan tudnám még ezeket a regex feltételeket is bekapcsolni az egyes mezőimhez? Írtam lentebb az első "vorname" if rész után egy kikommenteltet, ahogy szerintem mennie kellene, mégsem megy.
Előre is köszönöm a rávezetéseket, hogy hogyan oldhatnám ezt meg.
-
#4825
PumpkinSeed
addikt
Sk8erPeter
#4824
PumpkinSeed
addikt
válasz
Sk8erPeter
#4824
üzenetére
Amikor fel se kerülnek.
-
#4824
Sk8erPeter
nagyúr
PumpkinSeed
#4823
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#4823
üzenetére
"az internetre feltett kódok jobb esetben azonnal elvesztik licencüket"
És mi a rosszabb eset?Amúgy ja, abban igazad van, hogy komolyabb eseteket leszámítva itt azért etikai szempontok is erősen érvényesülnek (ti. hogy más tollával ékeskedni forrás-megjelölés nélkül nem szép dolog; persze nyilván ezt is mértékkel, nem kell minden kétsoros kód forrását is feltüntetni
). -
#4823
PumpkinSeed
addikt
Sk8erPeter
#4822
PumpkinSeed
addikt
válasz
Sk8erPeter
#4822
üzenetére
Függhet a liszensztől is, hogy mennyire szerencsés sima copy-paste-tel felhasználni külső kódot egy az egyben...
Nekünk az ilyenre azt mondták, hogy az internetre feltett kódok jobb esetben azonnal elvesztik licencüket, mert teljes mértékben visszanyomozhatatlan hol mikor használják. Persze, ha egy teljes fizetős lib-et nyúlnak le az más. Hogy ha akárhonnan is szedünk le terjedelmesebb kódot legalább megjegyzésbe tegyük oda a készítőt.
-
#4822
Sk8erPeter
nagyúr
adam_
#4821
Sk8erPeter
nagyúr
Az agyatlan copy-paste nyilván nem jó, mert nem tudhatod, mennyire megbízható vagy erőforrás-takarékos egy kód, ahogy az sem jó, ha egy nem igazán ismert library-t/plugint/frameworköt/egyebet kételkedés nélkül felhasználsz. A Te megközelítésed jó, hogy tanulmányozod a kódot, megpróbálod megérteni, aztán ha jónak találod, felhasználod. Lehetőség szerint módosítod. DE természetesen van bőven olyan eset is, amikor nem akarod tudni, hogy egy többek által is javasolt és tesztelt kód/library/plugin/framework/akármi mitől működik jól.
Egyszerűen mert sokszor nem éri meg az időbefektetést. (Amúgy lehet olyan is, hogy felfedezel egy hibát/rossz megközelítést egy publikus repository-ban, forkolod a projektet, végrehajtod a módosítást, küldesz egy pull requestet, jelzed a szerző felé, hogy figyelj, itt van a javított kód, az meg szarik rá (és mondjuk annyit sem ír, hogy ezért és ezért nem fogom elfogadni). A hátránya, hogy neked minden kódfrissítésnél patch-elned kell a kódot a saját javításoddal.)
Függhet a liszensztől is, hogy mennyire szerencsés sima copy-paste-tel felhasználni külső kódot egy az egyben, ha az mondjuk simán kiderül kifelé is (ld. kliensoldali kód vagy mások által is látható repository, ilyesmik).
De ha különösebb akadálya nincs, megismerted a kódot, és azt tényleg jónak találtad, semmi gond nincs azzal, ha felhasználod. Simán előfordul, hogy az ember akár egy rövid kódrészletet talál Stack Overflow-n vagy máshol, amit egy az egyben fel tud használni. -
adam_
senior tag
Most egy abszolút szubjektív kérdés következik.
Mennyire jellemező a szakmában (ez most lehet Frontend, backend ...) meg úgy szerintem a programozásban dolgozóknál, hogy egy kisebb avagy nagyobb feladatot googlezással, majd copy pasttel oldalanak meg oszt csókolom?
Nem tudom, én eddig úgy voltam vele, hogy ami eddig nekem kellett, arra vagy keresgéléssel, majd az adott kód személyre szabásával sikerült elérnem egy probléma megoldását, és még kifejezetten JS berkeken belül nem igen volt olyan, hogy magam írtam volna hosszabb kódokat, a kisebb módosítgatásokat leszámítva. Természetesen ez lehet azért is van, mert frontendbe gondolkozva nem annyira elvetemült kódokra van (volt eddig) szükségem, mint pl. a szerver oldalnál. Valamint ha egy kódot találok, ahhoz megpróbálok mindig még jobban utánanézni, a működését megérteni (ez is egy tanulási módszer számomra), nem szeretem úgy hagyni, csak bemásolva, aztán működik, és azt se érti az ember, hogy hogyan.
Ti erről mit gondoltok?
-
martonx
veterán
Mi a java-s standalone verziót sokáig használtuk, de a Visual Studio a 2013-as verziója óta annyira jó beépített tool-okkal rendelkezik, hogy már csak azokat futtatjuk automatikusan (igaziból minden egyes js mentéskor újra és újra fut out-of-the-box, a végeredményt már csak automatizáltan fel kell tolni CDN-be publishkor - nem szerver oldalról beszélek). A build utáni legelső http requestkor pedig generálódik egy hash, és amíg nincs új publish, addig azzal megy a js, css.
Én tök szívesen eszmét cserélnék veled (bár szerver oldalon nem js-ezek), és még értem is amit írsz, de annyira homlokegyenest eltérő fejlesztői környezetekben dolgozunk, hogy mégis kb. nincs miről beszélni. Mindenesetre jó látni amiket írsz, legalább jobban képben maradok a másik vonalat is látva.
-
Zedz
addikt
Édes istenem, ha a felét érteném már boldog lennék.
Amúgy a Googlenak mi volt a célja a Darttal? Tényleg úgy gondolják, hogy le tudják vele váltani a Javascriptet? Prog.hu-n volt egy cikk, hogy a JS népszerűsége egyre csak növekszik, akkor mégis mit akar a Google? Ráadásul nemrég beszéltük az ES6 újdonságairól, ami nem lesznek rosszak. -
Jim-Y
veterán
Na hat akkor en el is kezdenem rogton egy kerdessel.
Bevezetes: A Dart (dart2js) compiler automatikusan csinal tree shakinget, amit azert tud megtenni, mert a kod nem valtozik dinamikusan compile utan. Tehat pl classokhoz letrehozas utan nem lehet nyulni. Ezt egy nagyon jo dolognak tartom, marmint a tree shakinget, es azon gondolkoztam, hogy vajon van e mar ilyen javascripthez is.
Innen jutottam el a Google Closure Compilerhez. Kerdeznem, hogy van-e valakinek ezzel tapasztalata? Peldaul mennyire jo otlet a production build-be egy olyan lepest tenni, ami lefuttatja a bundle fajlt a g.c.c-en?! Production build alatt most nem munkahelyi kornyezetben levo prod buildet kell erteni, hanem mondjuk a sajat kis applikaciodnal, amikor csinalsz egy full dist-et, akkor mennyire lehet ennek letjogosultsaga? Ugy tudom, hogy egyreszt nem lehet akarmennyiszer hasznalni a g.c.c-t, illetve nem is a sajat gepeden fut, hanem talan a Cloudon?!
TreeShaking ~dead code elimination: Kiszuri a kododbol azokat a reszeket amikre nincs referencia, ezaltal optimalizaltabb kodot kapsz eredmenyul.
Udv,
Koszimegj: van egy standalone java alkalmazas is ra, ezt megtalatam kozben
-
Zedz
addikt
"Egyik haverom mondta tegnap, hogy majd nézzem meg a JS topikot, mert valami hülye mindig linkelgeti a fass***it, és, hogy tök jól elbeszélget magában."
Na neee.
(#4816) martonx: Nem feltétlen kérdéseknek kell itt lenniük. Én például szívesen olvasnék eszmecserét nálam jobbaktól, biztos sokat lehetne belőlük tanulni. A nemrég írt toolokról, ki hogyan old meg 1-1 bonyolultabb dolgot, ilyenek.
-
martonx
veterán
Szvsz nem attól lesz jó egy topik, hogy mennyire pörög lásd PHP topik elképesztő szinvonaltalansága, vagy webfejlesztős, CSS-es topikban a honda nevű hülyegyerek trollkodásai.
A fórumok egyébként már csak ilyenek. Aki ért hozzá, és nagy néha felmerül benne 1-2 mélyebb kérdés, az már inkább magától utánajár, utána olvas, nem pedig ezekben a fórumokban kérdez utána. Szükségképpen inkább az egyszerűbb kérdések jönnek elő.
-
#4815
Jim-Y
veterán
Sk8erPeter
#4813
Jim-Y
veterán
válasz
Sk8erPeter
#4813
üzenetére
Asszem, thx ->
Amúgy egyetértek, mit sem ér a sok új syntactic sugar, ha még nem érti valaki az alapokat, vagy nem kódolt eleget ahhoz, hogy értékelni tudja például a spread operátort. Nekem például ez már többször is előjött, hogy de jó is lenne, ha egy tömböt szét lehetne robbantani pozícionális argumentumokra még mielőtt megjelent volna az ES6-ban. Persze ott volt erre az apply, de akkor is
Zedz: "Nagy kár hogy mondhatni halott ez a topik, nem "pörög" annyira." Egyik haverom mondta tegnap, hogy majd nézzem meg a JS topikot, mert valami hülye mindig linkelgeti a fass***it, és, hogy tök jól elbeszélget magában.
Nekem inkább az a bánatom, hogy legtöbbször a betévedők kérdései kimerülnek a frontendes kérdésekben, minthogy hogyan lehet 10pixellel lejjeb mozgatni valamit javascripttel és hasonlók, és ritkábban jönnek elő olyan témák, amire még ezen kívül használják a JS-t.Pl:
* szerver oldal
* IoT
* Canvas -> játékok, animációk
* Desktop appok és widgetek
* ilyesmikEzért szoktam néha ilyen témákból is linkelgetni ^^ Bár az utolsó 2-3 ponthoz eddig még nem sok közöm volt :/
-
#4814
Zedz
addikt
Sk8erPeter
#4813
Zedz
addikt
válasz
Sk8erPeter
#4813
üzenetére
Köszönöm a tanácsot! Az alapokat ha mondhatom akkor egy stabilabb szinten már elsajátítottam, például az objektumokkal való munka már nem okoz különösebb gondot. Egy ideje már jobban érdekel a JS, szeretnék benne minél jobb lenni és ebben fognak nekem segíteni ezek az eszközök, amiket Jim-Y is felsorolt.
Elolvastam az oldalukon található leírásokat, githubon található írásokat, próbálgatom őket. Broswerify például nagyon tetszik, a 6to5 érdekességnek jó, de nem tudom mennyire tudnám kamatoztatni még a benne rejlő lehetőségeket.
Nagy kár hogy mondhatni halott ez a topik, nem "pörög" annyira.
Na majd szólok honda haverunknak, lesz itt kérdés bőven. -
#4813
Sk8erPeter
nagyúr
Zedz
#4809
Sk8erPeter
nagyúr
Ha adhatok egy tanácsot, ne az újításokkal kezdj foglalkozni, hanem sajátítsd el rendesen a JavaScript-alapokat, aztán mélyítsd a tudást olyan feladatokkal, amikkel hétköznapi feladatokat oldasz meg. Ne olyan dolgok megértésével kísérletezz kapásból, amikhez az is szükséges, hogy értsd az alapokat ahhoz, hogy értékelni tudd és értsd is az újdonságokat. Ha a relatíve stabil alap megvan, utána mehet a többi.
Szerintem Jim-Y tudása már elég speckó dolgokra terjed ki, sokszor már nekem is totál ismeretlen és új, amikről beszél.
De Jim-Y kolléga a melója meg saját elhivatottsága miatt sokkal intenzívebben foglalkozik a JavaScripttel. Az, hogy honnan hova jutott ezen a területen, az egyébként szerintem elég példamutató, elég rendesen látszik a belefektetett energia.Jim-Y: remélem elpirultál.
-
Jim-Y
veterán
Lejárt...
Amúgy még én sem ástam bele az ES.next-be magam, mert azért jelenleg az ES5 még sokkal, sokkal elterjedtebb, de az a véleményem, hogy lassan már itt lenne az ideje, megismerkedni az újdonságokkal. Én kezdésnek ezeket fogom majd megismerni, mert az iojs ezeket támogatja alapból. Eddig ha pl csináltam egy szerber-api-t, akkor ahhoz node-ot használtam, de most már nem szól mellette semmi, tehát iojs-t fogok használni, amiben ezek támogatottak:
Which ES6 features ship with io.js by default (no runtime flag required)?
Block scoping (let, const, and function-in-blocks) (strict mode only)
Collections
Generators
Binary and octal literals
Promises
New String methods
Symbols
Template literals -
Jim-Y
veterán
Igen, bár azt nem tudom sajnos, hogy akkor attól kezdve, hogy a modulok támogatottak lesznek minden olyan böngészőn, amire fejleszteni szeretnénk, azok a toolok, amiket ma használunk modulokra bontásra, teljesen feleslegessé válnak-e vagy sem. Szerintem az igény akkor is meglesz arra, hogy összecsomagoljuk a fájlokat, de nyílván arra egy sima concat tool is elég lesz. Szóval
1: igen, ES6-ban lesz "natív" modul támogatás
2: nem, sajnos nem tudom, hogy ez a browserify, webpack, UMD, AMD toolokra milyen hatással lesz :/Annyi biztos, hogy nem most lesz, amikor ezeket biztonságosan el lehet majd hagyni
-
Zedz
addikt
Főiskolán volt egy óra, fél évig mondjuk azt "tanították" a JS-t, de mivel annyira unalmasan adták elő, nem is igazán érdekelt a dolog. Aztán főiskola után úgy voltam vele illene megismerni, és elkezdtem kicsit jobban utánanézni. Ez volt nyár eleje, akkor magamra szedtem egy minimális tudást + jQuery használatot, az elmúlt 1-2 hétben pedig ismét nekifeküdtem a dolognak, mert szeretném komolyabb szinteken űzni a dolgot.
Olvasom azt a pár könyvet amit még a múltkor ajánlottál valamelyik topikban az egyik fórumtársunknak, illetve ismerkedem ezekkel a toolokkal, keretrendszerekkel.
(#4808) Jim-Y: Így már érthetőbb a dolog!
-
Jim-Y
veterán
Gondoltam megmutatom, hogy hogy működik a browserify, mert viszonylag egyszerűen be lehet mutatni:
Vannak a forrás fájlok:
.
├── app.js
├── index.html
├── module1.js
├── module2.js
└── node_modules
└── browserifymodule1
======='use strict';
module.exports.hello = function(world) {
return 'hello, ' + world();
};module2
======='use strict';
module.exports.world = function() {
return 'world!';
};app
==='use strict';
var module1 = require('./module1.js'),
module2 = require('./module2.js');
document.querySelector('body > div > p').innerText = module1.hello(module2.world);Majd itt használjuk fel a browserify-t egy bundle készítésre, terminálban a gyökér könyvtárban ki kell adni ezt a parancsot:
browserify app.js > bundle.js
index.html
========<!DOCTYPE html>
<head>
<title>Browserify</title>
</head>
<body>
<div>
<p></p>
</div>
<script src="bundle.js"></script>
</body>
</html>Tehát a html-be már csak a bundle-t húzzuk be, illetve a webszerverre/CDN-re is már csak a bundle-t kell feltenni.
A bundle pedig ezt tartalmazza:
(function e(t,n,r){function s(o,u){if(!n[o]){if(!t[o]){var a=typeof require=="function"&&require;if(!u&&a)return a(o,!0);if(i)return i(o,!0);var f=new Error("Cannot find module '"+o+"'");throw f.code="MODULE_NOT_FOUND",f}var l=n[o]={exports:{}};t[o][0].call(l.exports,function(e){var n=t[o][1][e];return s(n?n:e)},l,l.exports,e,t,n,r)}return n[o].exports}var i=typeof require=="function"&&require;for(var o=0;o<r.length;o++)s(r[o]);return s})({1:[function(require,module,exports){
'use strict';
var module1 = require('./module1.js'),
module2 = require('./module2.js');
document.querySelector('body > div > p').innerText = module1.hello(module2.world);
},{"./module1.js":2,"./module2.js":3}],2:[function(require,module,exports){
'use strict';
module.exports.hello = function(world) {
return 'hello, ' + world();
};
},{}],3:[function(require,module,exports){
'use strict';
module.exports.world = function() {
return 'world!';
};
},{}]},{},[1]);Sok-sok olvashatatlan dolog, de látszik, hogy végső soron a te fájlaidat rakja össze.
Üdv -
-
Zedz
addikt
ES6 bocsánat, elírtam.
Ezt a "Browserify"-t már többször láttam említve, most gyorsan kicsit utánanéztem. Ez egy olyan tool, ami segít elszeparálni a JS kódunkat? Majd a végén egy bundlebe rakja őket?
Köszi a tippet, ez a 6to5 szimpatikusnak tűnik.
(#4803) Jim-Y akkor ezek már ES6 fícsörök?
-
Jim-Y
veterán
Például ha Reactos projekte van az embernek, és használ JSX-et és reactify-al buildeli, akkor ezeket a harmony feature-öket használhatja:
reactify transform also can compile a limited set of es6 syntax constructs into es5. Supported features are arrow functions, rest params, templates, object short notation and classes. You can activate this via --es6 or --harmony boolean option:
Mozillában tesztelve, próbáldd ki őket, scratchpadben mindegyik megy
arrow functions
============document.body.addEventListener('click', event => console.log(event.target));
rest params
=========function sum(a, b, ...rest) {
return Math.max(...[a,b].concat(rest));
}
console.log(sum(1,2)); // 2
console.log(sum(1,2,4,1,5,6,12,2,3)); // 12templates
========console.log(
`The max out of 1 and 2 is ${sum(1,2)}`
);
// "The max out of 1 and 2 is 2"object shorthand notation
===================var myModule = function() {
var newMax = function(a, b, ...rest) {
return Math.max(...[a,b].concat(rest));
};
var oldMax = function() {
return Math.max.apply(Math.max, [].slice.call(arguments));
};
// old syntax
// return {
// oldMax: oldMax,
// newMax: newMax
// };
return {
oldMax,
newMax
};
};
console.log(
myModule().oldMax(1,2,3,4,9,3,4,5)
); // 9classes
======// In iojs/node
class Topic extends EventEmitter {
constructor() {
super();
}
publish() {
this.emit('article');
}
subscribe(subscriber) {
// subscribe
}
}És nincs felsorolva, de a destructuring is műküdik:
destructuring
==========var React = require('react'),
{ Route, DefaultRoute } = require('react-router'),
{ AppComponent, Contact, Content } = require('./components/Screens'),
baseUrl = require('../appConfig.json').app.baseUrl;
module.exports = (
<Route name="home" path={baseUrl} handler={AppComponent}>
<Route name="contact" path="contact" handler={Contact} />
<DefaultRoute handler={Content} />
</Route>
); -
Jim-Y
veterán
Ha az ES6-ra gondolsz, akkor úgy vélem, hogy az elterjedése folyamatos, és csak a projekt karakterisztikái határozzák meg, hogy már ma is használhatod-e, vagy sem. Például ha olyan a projekt, hogy folyamatos buildelést kíván, mert például browserify-t, vagy webpacket használsz, akkor akár már most is használhatsz olyan eszközöket, mint a 6to5, vagy a Traceur, és szerintem ilyen esetben ajánlott is használni valamit. Én például mostanában React-os projeketeket csinálok, browserify-t használok, kifejezetten ES6 to ES5 transpilerem nincs, de a reactify miatt van 1-2 ES6-os feature amit "ingyen" megkapok. Ezeket előszeretettel használom már most is.
Szóval, 100%-os támogatottságra még biztos várni kell, szerintem minimum egy évet, de a migráció folyamatos a vendorok részéről, így az idő előre haladtával mind több és több ES6-os feature-t lehet használni.
megj: illetve mivel az iojs ilyen jó ES6 támogatottsággal rendelkezik, ezért szerver oldalon már ma is lehet használni az újdonságokat.
).
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Az egyesszám a cookie. Akkor már cookie-kkal. 
Amúgy a Googlenak mi volt a célja a Darttal? Tényleg úgy gondolják, hogy le tudják vele váltani a Javascriptet? Prog.hu-n volt egy cikk, hogy a JS népszerűsége egyre csak növekszik, akkor mégis mit akar a Google? Ráadásul nemrég beszéltük az ES6 újdonságairól, ami nem lesznek rosszak.
De Jim-Y kolléga a melója meg saját elhivatottsága miatt sokkal intenzívebben foglalkozik a JavaScripttel. Az, hogy honnan hova jutott ezen a területen, az egyébként szerintem elég példamutató, elég rendesen látszik a belefektetett energia.Új hozzászólás Aktív témák
Hirdetés
- AMD vs. INTEL vs. NVIDIA
- Kerékpárosok, bringások ide!
- PlayStation 5
- Milyen légkondit a lakásba?
- Debrecen és környéke adok-veszek-beszélgetek
- Xbox Series X|S
- Linux kezdőknek
- A fociról könnyedén, egy baráti társaságban
- Xiaomi 14T - nem baj, hogy nem Pro
- One otthoni szolgáltatások (TV, internet, telefon)
- További aktív témák...
- JBL Tour One M2 - Champagne
- AKCIÓ!!! GAMER PC: Új RYZEN 7 5700/5800X +RX 6600/6700XT/6800/9060XT +Új 16-64GB DDR4! GAR/SZÁMLA!
- Sword 16 HX 16" FHD+ IPS i7-13700HX RTX 4070 32GB 500GB NVMe magyar vbill gar
- Apple iPhone 7 128GB, Yettel függő, 1 Év Garanciával
- ZBook Power 15 G10 15.6" FHD IPS i7-13800H RTX A500 32GB 512gb NVMe ujjolv gar
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: Promenade Publishing House Kft.
Város: Budapest