- Samsung Galaxy A54 - türelemjáték
- Poco X6 Pro - ötös alá
- iOS alkalmazások
- iPhone topik
- Apple Watch Ultra - első nekifutás
- Yettel topik
- Milyen okostelefont vegyek?
- Motorola Moto G24 Power - hol van az erő?
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
Hirdetés
-
A Video AI lehet a One UI 6.1.1 ütőkártyája
ma Vagy hogy fogja a mesterséges intelligencia manipulálni a mozgóképeket?
-
Premier előzetesen a Wrath: Aeon of Ruin konzolos változatai
gp A PC-s változat után a minap PlayStationre, Xbox-ra és Switch-re is elérhető lett a program.
-
Miniképernyős, VIA-s Epomaker billentyűzet jött a kábelmentes szegmensbe
ph A megfizethető, szivacsokkal jól megpakolt modell ötfajta kapcsolóval és kétféle színösszeállítással/kupakprofillal szerezhető be.
-
Mobilarena
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
-
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.
[ Szerkesztve ]
-
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>
);[ Szerkesztve ]
-
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?
[ Szerkesztve ]
-
Jim-Y
veterán
Ez egy olyan tool ami lehetővé teszi, hogy node/iojs környezetben CommonJS-ben írt modulokat tudsz browser környezetben használni. Ezt igen úgy éri el, hogy a require direktívákkal behúzott modulokat egy bundle fájlba "csomagolja".
Igen ezek ES6-os újítások.
[ Szerkesztve ]
-
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[ Szerkesztve ]
-
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
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
[ Szerkesztve ]
-
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[ Szerkesztve ]
-
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.
Sk8erPeter
-
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.
-
Jim-Y
veterán
válasz Sk8erPeter #4813 üzenetére
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 :/
-
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ő.
Én kérek elnézést!
-
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.
[ Szerkesztve ]
-
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
[ Szerkesztve ]
-
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.
-
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.
Én kérek elnézést!
-
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?
[ Szerkesztve ]
-
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.Sk8erPeter
-
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.
[ Szerkesztve ]
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
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 ).
Sk8erPeter
-
PumpkinSeed
addikt
válasz Sk8erPeter #4824 üzenetére
Amikor fel se kerülnek.
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
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.
[ Szerkesztve ]
-
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
Napi humor?! Ha már volt, akkor bocs.
-
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;
}[ Szerkesztve ]
-
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.
[ Szerkesztve ]
-
-
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.
-
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?[ Szerkesztve ]
Sk8erPeter
-
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.but without you, my life is incomplete, my days are absolutely gray
-
Zedz
addikt
válasz Sk8erPeter #4837 üzenetére
Csak honda meg ne lássa. Lenne itt olyan káosz.
-
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.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
Zedz
addikt
De ha már lekerült a régi kép, akkor valami új jöhetne is.
-
dqdb
nagyúr
válasz Sk8erPeter #4845 üzenetére
Igen, pontosan ez volt a javaslatom mögötti ötlet.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
Jim-Y
veterán
Ajánlott olvasmány.
Nekem is egyébként a komponens alapú megközelítés tetszik legjobban a Reactban. Főleg nagy cég szintjén előbb utóbb előjön az az igény, hogy ugyanazt a technológiát használó projektek között jó lenne kódot megosztani.
[ Szerkesztve ]
Új hozzászólás Aktív témák
- Samsung Galaxy A54 - türelemjáték
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- exHWSW - Értünk mindenhez IS
- Kés topik
- Skoda, VW, Audi, Seat topik
- Milyen TV-t vegyek?
- Übergyors Samsungnak próbál látszani egy hamisított NVMe SSD
- Poco X6 Pro - ötös alá
- A régi node-okra koncentrál a szankciók miatt Kína
- Borotva, szakállnyíró, szakállvágó topic
- További aktív témák...
- Üzletből,DELL garanciával, Dell XPS 9310 2in1 ultrabook, i7-1165G7/32RAM/1TBSSD/13,4"UHD TOCH
- Üzletből, gyártói garanciával, Lenovo Yoga Slim 7 Pro, i5/16GBRAM/512GBSSD/14,1" 2,8K OLED
- Realme GT Neo2 5G 256GB
- M.2 2280 256GB SSD-k eladók Ingyen posta
- DELL WD15 Type-C Fekete +130W Töltő Ingyen szállítás