- Honor 200 Pro - mobilportré
- iPhone topik
- Megérkezett a Google Pixel 7 és 7 Pro
- Samsung Galaxy Watch7 - kötelező kör
- Samsung Galaxy Watch6 Classic - tekerd!
- Mobil flották
- Milyen okostelefont vegyek?
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- Google Pixel 9 Pro XL - hét szűk esztendő
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
-
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
-
Lacces
őstag
Hello!
Valaki próbált már NVM-el telepíteni nodejs-t?
Én ezzel próbátalm:
# Node Package Manager: NPM
curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.25.4/install.sh | bash
source ~/.nvm/nvm.sh
nvm install node
nvm alias default node
de ez használhatatlan, valahányszor kilépek a szerverről, már el is tűnt a nodejs... nem jegyzi meg, újra kell installálni az nvm-en keresztül. (Mintha csak session-ben létezne) -
#5499
Sk8erPeter
nagyúr
cocka
#5494
Sk8erPeter
nagyúr
Uhh, ezt én is de tudom utálni, régen ilyet a prog.hu is csinált, hogy automatikusan frissült a lap, de nem csak frissült, át is irányított, így hiába volt későbbi olvasásra félretéve pár cikk, ránéztem egy idő múlva, és már csak a címlapot láttam. Gratula annak, aki kitalálta...
Írtam is nekik levelet ezzel kapcsolatban, hogy emiatt szoktam le a cikkjeik olvasásáról, hogy azóta is van-e ez a jelenség, fogalmam sincs, mert tényleg nem olvasom őket. 
A kérdésre amúgy most érdemben nincs időm reagálni, de látom, kaptál már ötletet, csak hát JS-hez értés nélkül nehéz lesz ezekkel bármit is kezdeni... Amivel hozzákezdhetnél, az az, hogy megnyitod a webfejlesztő panelt, és az ottani keresővel minden, oldalról letöltött forrásban elkezded keresgélni (Blink-alapú böngészőkben (pl. Chrome, Opera) a Ctrl+Shift+F segítségével!) az említett "setInterval" és "setTimeout" szavakat. -
dqdb
nagyúr
A kódot tartalmazó .js fájl blokkolása valószínűleg nem lesz jó, mert más funkciót is kinyírhatsz vele. Neked egy olyan user JS vagy extension kell (böngészőtől függ, melyik), ami document_start vagy DOMContentLoaded eseménykor (böngészőtől függ, melyik) lefut, és lecseréli a window.setTimeout vagy window.setInterval függvényeket (a weboldaltól függ, melyiket használja). De ezt is ésszel kell tenni, hogy tényleg csak azt a kérést blokkold, amelyik az újratöltésért felelős.
Most lusta vagyok összedobni egy pontosan ilyet, de íme egy Chrome/Opera extension, aminek hatására a böngésző letagadja, hogy tud WebM videót lejátszani, kiindulási pontnak tökéletes:
manifest.json
{
"content_scripts":
[
{
"matches": [ "http://*/*", "https://*/*" ],
"js": [ "content.js" ],
"run_at": "document_start"
}
],
"manifest_version": 2,
"name": "Test Script",
"version": "1.0.1"
}content.js
var patch = document.createElement("script");
patch.type = "text/javascript";
patch.innerText =
"HTMLVideoElement.prototype.canPlayType = function(type) { console.log('HTML5 video', type); return type.substr(0, 10) === 'video/webm' ? '' : this._canPlayType(type); };";
(document.head || document.documentElement).appendChild(patch); -
-
cocka
veterán
Sziasztok!
Nem nagyon értek a javascripthez, de azt nagyjából sejtem milyen irányban kell keresgélnem.
Van ez a csodálatos honlap, hogy mno.hu. Ennek megvan az a jó szokása, amit rettenetesen utálok, hogy ha órákig meg van nyitva, akkor automatikusan lefrissül és ha pl. cikket olvastam és mondjuk elkattintottam máshová vagy vmi elterelte a figyelmem, mire visszatérek már le is frissült.
Van egy olyan sejtésem, hogy a millió js fájl egyikében rejtőzik az a settimeout függvény, amit keresek, csak kérdés, hogy melyikben. Az időtartamra sem tudok rájönni.
Régen ezt megoldották egy meta refresh taggel, aztán kész, ahhoz volt meta refresh blocker, de gondolom javascriptnél nem ilyen egyszerű a helyzet.
Ha valaki esetleg tud segíteni, megköszönöm.
-
_ak_
addikt
Utólag is köszönöm mindenkinek a segítséget, bevallom eszembe sem jutott a SPA gondolata, pedig, magam is akartam barkácsolni gyakorlásképp, de ezek szerint annó nem sikerült az alapvető koncepcióját felfognom.
Pechemre most egyedül vagyok webes, úgy hogy erősen csillagközi invázió állapot van, de így legalább tudom, hogy az esetleges szabadidőmben érdemes foglalkozni a kérdéssel és nem akartam hülyeséget.
-
jetarko
csendes tag
Az értéket az angular kódja változtatja meg egy kb 30soros loopban ami nagyon sokszor fut le. Így hát nincs kedvem végignyomogatni, de valszeg átírom majd a kódot és vmi if-et teszek bele.
A keresés közben ráakadtam erre a csodás kommentre:
// Insanity Warning: scope depth-first traversal
// yes, this code is a bit crazy, but it works and we have tests to prove it! -
Karma
félisten
Szerintem nem szükségszerű, hogy a rossz érték beállítása után azonnal olvassa is valahol, így a stacktrace-ből nem sok látszik. Mondjuk az is egy jó kérdés, miért vannak pőrén változók, amit többen is állítgathatnak?
Egy darabig filóztam, hogy az Object.observe-vel nem lehetne-e megoldani a dolgot, de sajnos ott is csak a változás tényéről jön értesítés, a kiváltó ok nem látható.
-
inf3rno
nagyúr
Még régi msie-kben volt ez gond, amikor az enumerable nem volt implementálva és állandóan betette a konstruktort meg az Object.prototype-ban lévő dolgokat a for-in-be. Ma már van ES5 support, és hasOwnProperty nélkül is rendesen elmegy a for-in. Olyasmivel próbálkoztam, hogy enumerable: false-ra állítom a metódusokat, hogy néhány örökölt property-t be lehessen járni for-in-el. Ezeket kiszűrné a hasOwnProperty. Sajnos nem jött be a dolog a már említett böngészők közti eltérések miatt.
Igen, tisztában vagyok vele, hogy vannak erre callback-es megoldások, de én jobban szeretem a hagyományos ciklusokat, leginkább azért, mert sokszor elfelejtem kitenni a bind-ot a végére a callback-nek.
-
inf3rno
nagyúr
Ha van szabadidőd, akkor a helyedben beleolvasnék a "ddd strategic design" részébe egy-két cikknek, könyvnek, ilyesmi, hátha találsz valamit, amit erre az esetre lehet alkalmazni. Rosszul megírt projekteken is lehet vele javítani valamennyit. Azért csodát ez sem tud tenni az eddigiek alapján.
A tesztek nélküli refaktorálás meg nem egy ajánlott dolog. Érdemes lenne legalább 1-2 e2e tesztet beletenni így utólag a main feature-ök tesztelésére, hogy nagyon fontos dolgok ne törjenek el, ha átírtok valamit. Ez azok alapján, amit elmondtál, bármikor megtörténhet, amikor hozzányúltok a kódhoz.
Sajna a legacy-val ez van általában. Egy idő után túl nagy erőfeszítés megjavítani, az ember legszívesebben újraírná az egészet, de azért meg nem fizet senki, mert hát a mostani a rendszer is "jól" működik. A refaktorálásért sem fizetnek, hacsak nem sikerül elmagyarázni nekik, hogy minél többször nyúltok hozzá a kódhoz ilyen formában, annál valószínűbb, hogy széthullik az egész.
Úgy emlékszem, hogy for-in-el próbálkoztam a bejárással, és az Object.defineProperty-nél az enumerable: false eltérően öröklődik az egyes böngészőkben. Valahol nem kerül be bejárásnál a listába az öröklött tulajdonság, valahol meg bekerül. Azt hiszem ugyanígy hibák voltak a setter, getter, congfigurable terén is, de ezt nem mondom biztosra. Küldtem mindegyik major böngészős cégnek bug report-ot, hogy jó lenne közös nevezőre jutni ezzel kapcsolatban, de egyik sem reagált, úgyhogy én inkább nem használom többet azt a függvényt meg a for-in-t bejárásra (kivéve config objecteknél, meg 1-2 helyen). Sugar syntax-hoz kellett volna csak, megoldottam másképp, úgyhogy nem lényeges.
-
Jim-Y
veterán
válasz
inf3rno
#5483
üzenetére
Sajnos amikor keszult a projekt akkor nem igazan gondoltak fejlesztesi modszertanokra azota pedig annyira kinotte magat a projekt hogy eleg nehez (khmmm ain't noone will pay for this) akar csak egy TDD-t is bevezetni. Az eddig megirt kodbazis 90% nem tesztelheto modulokban lett megirva nem olyan szempontok szem elott tartasaval, szv fck
De azert probalkozik az ember mert igeny (most mar) lenne ra. Legalabbis fejlesztoi oldarol.Async-hez sima jQuery -> AJAX/Deferred, legacy product es mint olyan jQuery-t hasznal, sajnos
A nativ hiba az mi volt?
-
inf3rno
nagyúr
A BDD-t és a DDD-t próbáltátok már, vagy ahhoz meg még túl kicsi a projekt?
Én most olvasom a Vaugh Vernon könyvet DDD-vel kapcsolatban. Elég jól leírja, hogy hogyan lehet szétszedni kezelhetőbb méretű részekre óriás alkalmazásokat. Szerintem kliens oldalra is használható az elv, ha már akkora lenne a kód.
A BDD-ehhez többé-kevésbé szorosan kapcsolódik. Nálam kb annyiról szól, hogy cucumber-ben megírod a use case-eket a domain model nyelvén, utána ezeket lefordítod tesztekre step definition-ökkel. Aztán teszteled vele az alkalmazást. Lehet csak a domain model-t is tesztelni, amiben a business logic van, de akár e2e teszteket is lehet írni, és a kliens oldalról megközelítve tesztelni az egész alkalmazást (ez jóval lassabb). Elég széles a tárház, hogy mit tudsz tesztelni, és nagyon rugalmas, mert a step definition-ök szabadon cserélhetőek úgy, hogy közben a use case-ek ugyanazok maradnak felettük. Ha változik a megrendelői igény a logikát tekintve, akkor változik a use case is, ellenkező esetben viszont csak a step definition-höz kell hozzányúlni, ha éppen gombra kell kattintani link helyett vagy ilyesmi egy űrlap küldéshez. Egyelőre ezzel is csak kísérletezek, de egyre inkább úgy tűnik, hogy be tudom venni hagyományos TDD helyett a napi rutinba.
A kliens oldalon örök szopás, hogy 1000 féle környezetet kell megtámogatni. Nem új dolog. Én futottam már bele mostanában natív js bug-ba is. Nagyon kellemetlen, mert órákon át lehet keresni a kódodban, hogy hol a hiba, miközben nem ott van, hanem a js motorban... Ha nem TDD-vel írtam volna a kódot, akkor elkapálhattam volna magam, mert debug-nál még nehezebb egy ilyet leszűkíteni pár sor kódra. TDD-nél azért képben vagy, hogy éppen mire írtad 1 perce a tesztet.
Async-hez te milyen lib-eket használsz?
-
Jim-Y
veterán
válasz
inf3rno
#5481
üzenetére
A kliens altal tamasztott kovetelmenyekkel altalaban. A business logic neha-neha annyira bonyolult es a specifikacio annyiszor valtozik menet kozben, hogy eleg nehez egy tenyleg jol mukodo feature-t osszehozni.
Illetve a oldalak kozti navigaciot sokszor eleg nehez hibamentesen osszehozni mert a kapcsolati halo eleg bonyolult es a statemanagement is problemassa valik(hat).
Ami mar inkabb programozas kozeli az a kulonbozo platformok tamogatasanak igenye es az ebbol fakado gondok. Kulonbozo WebView verziokat kell tamogatni es kulonbozo Oprendszereket es nem minden mukodik ugyanugy ezeken. Ezekkel nagy szivas van. Erdekes nyelvi szinten ebbol nincs problema. Szinte minden tamogatott environmenten mar olyan WebView van ami az Ecma 5.1-et teljes koruen tamogatja szv ebbol nincs gond.
Kb ugy ennyi..
-
Jim-Y
veterán
válasz
inf3rno
#5479
üzenetére
En Dartoztam egy darabig es nagyon tetszett, tenyleg, jo kis nyelv az, csak nem talalta meg a helyet a vilagban, de maga a nyelv az fasza
Ennek ellenere most egy baromi nagy JS heavy projekten dolgozom es latom, hogy a tenyleges problemak csak egy baromi kis szeletet jelentik a tipusossagbol adodo gondok?. Nem neveznem gondoknak oket..mondjuk ugy hogy baromi ritkan van abbol gond, hogy a JS dinamikusan tipusos az esetek kb 1%-ban szamit. Es ha azt vesszuk alapul, hogy jo JS fejlesztoink vannak akkor egesz egyszeruen nem lenne elonye egy TypeScriptnek egy vanilla JS-hez kepest :/ -
inf3rno
nagyúr
"inf3rno: typescript, dart, coffee, elm.. egyeni preferencia kerdese, szerintem ezek csak akkor hasznosak ha Java-n nevelkedett embernek kell JS kodot irnia. <tapasztalat>"
Személy szerint én annak idején js-el kezdtem, mint script kiddie, és nekem tetszik a TypeScript. Java-t tanultam egy keveset, de inkább az erős oo alap, ami miatt bejön, nem pedig a Java tudás miatt. Te funkcionálisan programozol js-ben, legalábbis a kódjaid alapján, ahhoz gondolom megfelel az a validálási forma, amit használsz. Én inkább az oo fele hajlok, ahhoz meg más eszközök a jobbak, pl TDD, vagy újabban BDD az alap, meg hogy minden sor kód tesztelve van. Ennél a megközelítésnél nekem kifejezetten zavaró, ha típusellenőrzésre kell teszt kódot fecsérelni. Nagyjából ennyi a különbség.
-
inf3rno
nagyúr
"This may not make sense at first but when you start dealing with multiple frames or windows in your script and pass objects from one context to another via functions, this will be a valid and strong issue."
Nekem továbbra sincs értelme. Mármint persze elfogadom, hogy nem működik, mert a böngészőket így tákolták össze, de ez sajna jellemző a kliens oldali fejlesztésre, hogy nekünk kell alkalmazkodni mások hülyeségéhez. Eléggé conformist viszonyban vagyunk a böngészőgyártókkal, nem customer-supplier-ben, hogy DDD-s szavakat puffogtassak. Ez már a kezdetek kezdete óta így van sajnos. Nem véletlenül utáltam meg a kliens oldali fejlesztést, és mentem át inkább szerverre.
-
Jim-Y
veterán
válasz
inf3rno
#5475
üzenetére
Nem szabad kizarolag sem typeof -ot sem instanceof -ot hasznalni type checkingre. Van amire ez jo, van amire az. Univerzalis megoldas nincs, peldaul amire te hasznaltad az instanceof-ot arra nem valo es nem ajanlott mert hibakhoz vezethet.
instanceof and multiple context (e.g. frames or windows)
Different scope have different execution environments. This means that they have different built-ins (different global object, different constructors, etc.). This may result in unexpected results. For instance, [] instanceof window.frames[0].Array will return false, because Array.prototype !== window.frames[0].Array and arrays inherit from the former. This may not make sense at first but when you start dealing with multiple frames or windows in your script and pass objects from one context to another via functions, this will be a valid and strong issue. For instance, you can securely check if a given object is in fact an Array using Array.isArray(myObj)
Epp ezaz, hogy nem muszaj mindig tipusellenorizni, ezert is irtuk itt tobben is, hogy a !x es tarsai hasznalata javvallott!
De asszem mar boven korul lett ragva a topic
Udv
inf3rno: typescript, dart, coffee, elm.. egyeni preferencia kerdese, szerintem ezek csak akkor hasznosak ha Java-n nevelkedett embernek kell JS kodot irnia. <tapasztalat>
-
Jim-Y
veterán
válasz
inf3rno
#5471
üzenetére
Amugy hogy miert nem ugyanaz.
null == false vs. !null
null == false
=========1. http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3
If Type(y) is Boolean, return the result of the comparison x == ToNumber(y).2. assert(typeof null === 'object')
3.
If Type(x) is Object and Type(y) is either String or Number,
return the result of the comparison ToPrimitive(x) == y.4. ToPrimitive(null) http://www.ecma-international.org/ecma-262/5.1/#sec-9.1
-> Null The result equals the input argument (no conversion).5. http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3
10. Return false.!null
===1. !ToBoolean(null)
2. Boolean(null) -> false
3. !false -> true -
inf3rno
nagyúr
1.
Hja, meglepődtem. Leginkább a null-on... Ezt a validációs részét a js-nek már 10 éve is újra kellett volna írni szerintem. Az egész egy jó nagy katyvasz. Elég hasonló a PHP-hez ilyen téren.2.
Erre mondtam, hogyha annyira a típus validálással akarsz molyolni, akkor érdemesebb TypeScriptet használni.Én személy szerint így oldanám meg a dolgot sima js-el:
function doStuff (inputArray) {
if (!(inputArray instanceof Array))
throw new TypeError("Array required.");
return inputArray.map(makeChange);
}aszinkron esetben meg
function doStuff (done, inputArray) {
if (!(inputArray instanceof Array)) {
done(new TypeError("Array required."));
return;
}
done(null, inputArray.map(makeChange));
}Primitíveknél is ugyanúgy jó a typescript, vagy ha nem szeretnél compile-t, akkor valóban írhatsz olyat, hogy
if (utils.typeOf(value, String))
és hasonlókat.
Szvsz. nem muszáj minden esetben ennyire szigorúan típusellenőrizni. Attól függ, hogy mire fejleszted a kódot. Ha valami kisebb projekthez kell gyorsan összeszórni olyasmit, amit ránézésre átlátsz, akkor felesleges erre időt pazarolni.
Leginkább az a hátránya ennek a nem beépített típusellenőrzésnek, hogy TDD-vel a teszt kód nagy része erre megy el, ahelyett, hogy a tényleges funkciókat tesztelné az ember.
-
Jim-Y
veterán
válasz
inf3rno
#5472
üzenetére
Ezeknek nem az az ertelme, hogy tipusossa tegyunk egy dinamikusan tipusos nyelvet, ennek ondokumentacio meg self validation miatt van ertelme.
Pl ha van egy fuggveny ahol azt varod hogy tombbel hivjak meg, de biztosra akarsz menni, akkor
rossz esetben igy irod meg
function doStuff(inputArray) {
return inputArray.map(makeChange);
}Jo esetben pedig igy
/**
* @param {Array} inputArray
* @return {Array}
*/
function doStuff (inputArray) {
if (!inputArray || !utils.isArray(inputArray)) {
return [];
}
return inputArray.map(makeChange);
}Ondokumentalas, es annak a kodbeli leirasa, hogy te mint programozo milyen mukodesre irtad meg a fuggvenyt. Persze lehet ezt kevesbe expliciten is irni, pl:
function doStuff (inputArray) {
return (inputArray || []).map(makeChange);
}De ez utobbi megint csak a falsy value-k ellen ved, az ellen nem ha pl egy stringet adnak meg.
-
Jim-Y
veterán
válasz
inf3rno
#5471
üzenetére
Hat... Chrome console ->
function x_test(val) {
console.group();
console.log(!val);
console.log(val == false);
console.groupEnd();
}
[0, null, void 0, '', Number.NaN, [], {}, 2, "test"].forEach(x_test);
// output
VM586:3
VM586:4 true
VM586:5 true
VM586:3
VM586:4 true
VM586:5 false
VM586:3
VM586:4 true
VM586:5 false
VM586:3
VM586:4 true
VM586:5 true
VM586:3
VM586:4 true
VM586:5 false
VM586:3
VM586:4 false
VM586:5 true
VM586:3
VM586:4 false
VM586:5 false
VM586:3
VM586:4 false
VM586:5 false
VM586:3
VM586:4 false
VM586:5 falseNekem ez nem ugy tunik mint ami ugyanaz lenne
-
inf3rno
nagyúr
Szvsz. nem bad practice. Nem minden esetben kell annyira szigorúan venni a típusellenőrzést. Főleg nem ha általában kivételeket dobunk hibánál, nem null-al és hasonlókkal térünk vissza. Ha mégis kell komolyabb típusellenőrzés, akkor ott a typescript, és megintcsak használható a !x vagy !!x, stb...
-
#5470
Zedz
addikt
fordfairlane
#5465
Zedz
addikt
válasz
fordfairlane
#5465
üzenetére
Nem értem ezen mi a bad practice. Egyszerű falsy check. De ha én tudom rosszul akkor kérlek írd le miért bad practice.
-
#5468
Jim-Y
veterán
fordfairlane
#5467
Jim-Y
veterán
válasz
fordfairlane
#5467
üzenetére
A !x kifejezes nem azt jelenti, hogy x == false hanem
The production UnaryExpression : ! UnaryExpression is evaluated as follows:
Let expr be the result of evaluating UnaryExpression.
Let oldValue be ToBoolean(GetValue(expr)).
If oldValue is true, return false.
Return true.A ToBoolean a falsy ertekeket konvertalja boolean false-ra amit negalni fogunk true-ra. Tehat a !x az egy falsy check es ajanlott a hasznalata ha nincs szukseg explicit check-re.
-
#5466
Jim-Y
veterán
fordfairlane
#5465
Jim-Y
veterán
válasz
fordfairlane
#5465
üzenetére
Ezt kifejtened kerlek? Bar tudom, hogy nem nekem szolt de erdekelne
-
#5465
fordfairlane
veterán
Zedz
#5459
-
martonx
veterán
válasz
slice14
#5463
üzenetére
Azt kellene belátnod, hogy egy fórumból sosem fogsz megtanulni programozni. Egy-egy kérdésedre kapsz persze választ, és így tovább tudsz lendülni, az amúgy bagatell problémákon, és a végén el tudod mondani, hogy csináltál egy programot, de valóban érteni fogod, hogy miért is működik?
Segítség nélkül újra tudnád írni? Szóval a bagatell dolgok megkérdezése helyett, bizony elő kellene venned valami js-es online doksit, és legalább az alapokkal tisztába kerülnöd, ha már ez a választott nyelv, amin el akartál indulni.
-
j0k3r!
őstag
"Ha egy kicsit lejjebb görgetsz, akkor látni fogod, hogy az if(x === undefined) az igazából ugyan az, mintha azt vizsgálnád, hogy if(!x)."
Ez nem igaz. Pl.:
var a = undefined;
var b = null;
var c = "";
var d = false;
var e = 0;
if(!a) console.log("a");
if(!b) console.log("b");
if(!c) console.log("c");
if(!d) console.log("d");
if(!e) console.log("e");(remélem nem gépeltem el a kódot)
-
Zedz
addikt
válasz
slice14
#5458
üzenetére
Az undefined azt jelenti, hogy az adott változónak nincs értéke. Itt szépen leírják, hogy mire is kell gondolni.
Ha egy kicsit lejjebb görgetsz, akkor látni fogod, hogy az if(x === undefined) az igazából ugyan az, mintha azt vizsgálnád, hogy if(!x).
Ha érdekel a JS akkor szerintem megéri rászánni egy kis időt, és elolvasni ezt a könyvet.
-
Jim-Y
veterán
válasz
martonx
#5452
üzenetére
Felig meddig igazad van, a typeof az onmagaban broken es tipus vizsgalatra nem javallott. Egy dologra alkalmas, undefined vizsgalatra
Bar en arra is inkabb explicitebb megoldast valasztanek pl
valami === void 0 de ez egyeni preferencia.Kb jQuery + underscore + lodash-bol osszeollozva
function isString(obj) {
return $.type(obj) === 'string';
}
function isNumber(obj) {
return exist(obj) && $.isNumeric(obj);
}
function isBoolean(obj) {
return obj === true || obj === false || $.type(obj) === 'boolean';
}
function isArray(obj) {
return exist(obj) && $.isArray(obj);
}
function isFunction(obj) {
return $.type(obj) === 'function';
}
function isDate(obj) {
return $.type(obj) === 'date';
}
function isRegExp(obj) {
return $.type(obj) === 'regexp';
}
function isError(obj) {
return toString.call(obj) === '[object Error]';
}
function isUndefined(obj) {
return obj === void 0;
}
function isNull(obj) {
return obj === null;
}
function isEmpty(obj) {
if (!exist(obj)) {
return true;
}
if (isNumber(obj) || isBoolean(obj) ) {
return false;
}
if (isArray(obj) || isString(obj) || toString.call(obj) === '[object Arguments]') {
return obj.length === 0;
}
return $.isEmptyObject(obj);
}
function exist(obj) {
return !isNull(obj) && !isUndefined(obj);
} -
-
martonx
veterán
válasz
slice14
#5447
üzenetére
ajánlom figyelmedbe az undefined értéket. Javascript fura szerzet, mert ott a null azt jelenti, hogy van értéke valaminek, csak éppen az az érték null. Az undefined az ami azt jelenti, hogy az a valami nem is létezik.
typeOf(valami) === "undefined" mondjuk lehet a feltételed. -
slice14
veterán
Sziasztok
Hogy tudom azt if-elni hogy ha egy text adat hiányzik a json-ből lekérésnél. Tehát ha nincs benne adat, akkor rakjon be egy szóközt vagy egy - jelet.
Ez így nem müxik, gondolom azért mert a null az szám értéket nézz...
Jelenlegiidojaras = Weather.current_observation.weather; if (Jelenlegiidojaras == null) {
setGlobal('%Jelenlegiidojaras'," "); } if (Jelenlegiidojaras != null) {
Jelenlegiidojaras2 = convert( Jelenlegiidojaras, 'htmlToText');
setGlobal('%Jelenlegiidojaras',Jelenlegiidojaras2); }Gondoltam még hogy else-vel is megoldható lenne, de itt az lenne a feltéttel hogy ha nincs adat, akkor rakjon be egy - jelet, vagy akármilyen szöveget. Viszont hogy tudom azt meghatározni, hogy üres az adat mező?
Ja, szövegre nem tudok hivatkozni, mert az nem statikus. -
-
Zedz
addikt
CSS... az egy másik állatfaj.
Most a JS felől közelítettem meg a kérdést, hogy manapság azért ezek a különbségek hála a sok előre megírt dolognak aligha észrevehetőek. Persze ha valaki nekiáll plain js-sel craftolni valamit, akkor ezekre fel kell készülnie, főleg ha a régi böngészőket is támogatni kell.
-
martonx
veterán
Amit te szeretnél az egy single page application, amit Karma jól be is mutatott. Annyit tennék még hozzá, hogy ebben az esetben a helyetekben a drupalt abszolút mellőzhetném, csak rest apu kell alá. De érted, így meg bukod a komplett Cms funkcionalitást. Neked kell dönteni, marad a cms bubusság és szar végeredmény gyorsan összekattogtatva, vagy megírjátok normálisra spa-ként, mondjuk 10-szer akkora idő befektetéssel.
-
Karma
félisten
A JS-telen felhasználók lehet tényleg nagyon kevesen vannak, és valószínűleg tényleg meg lehet spórolni a támogatásukat... Egy-két elvetemültebb egyént ismerek én is csak, az meg simán mérési hiba, főleg mobilon.
Viszont a böngészők közötti eltérések még mindig valós probléma. Nem a JavaScript vonatkozásában szerencsére, arra nagyon jók a shimek, de CSS-ben vicces helyzetek tudnak előállni például a bugtenger Android 4.0-án, vagy iOS 6-on... Egyébként igen, a frameworkök megvédenek sok gyakori pofontól, de nem mindenhatóak - amint el akarsz térni, vagy hozzá akarsz tenni valami olyan elemet, ami nincs benne az általuk kitalált eszköztárban, máris ott vagy, hogy mindenen le kell ellenőrizned.
-
Zedz
addikt
Manapság már nem sok olyan eset lehet, amikor az adott usernek nincs JS a böngészőjében. Szóval ha mondjuk az egyszerű felhasználóknak készül az oldal, akkor miért ne lenne bekapcsolva a JS?
Kíváncsiságból kérdem, hogy a böngészők közötti eltérés még mindig valid probléma így 2015-ben? Manapság már mindenhez van lib, framework, ezek gondolom cross-browser megoldásokkal vannak ellátva.
-
Karma
félisten
A kontextus meg a helyzeted pontosabb ismerete nélkül (pl. a kódbázis minősége) nehéz testreszabott választ adni, de amit most leírtál, a mai gyakorlatban elég népszerű Single Page Application (~ webes vastag kliens) stratégia. (Egy kulcsszónak használhatod az SPA-t.)
Ennek van előnye és hátránya egyaránt, hogy néhányat soroljak:
+ Jobb érzékelt sebesség/felhasználói élményt nyújt az első betöltés után.
+ Kényszerűen tisztább az architektúra, jobban újrafelhasználható (pl. natív mobilalkalmazások, új UI...) a monolit projekt kettévágása miatt(*).
+ A részek önálló életciklussal bírnak, tehát több csapat könnyebben dolgozhat a részeken; külön tesztelhető és élesíthető minden elem.
+ A backendhez és a frontendhez is vannak specializált könyvtárak, ahelyett hogy egy eszközzel próbálnád egy n-tier alkalmazás minden aspektusát lefedni. (igen, még mindig nem szeretem a PHP-t)- JavaScript nélkül (pl. NoScript felhasználók) az egész történet halott, úgyhogy egy igazán univerzális megoldáshoz nem dobhatod ki a Drupal által generált önjáró, "ódivatú" oldalt.
- A böngészők közötti eltérések sose szűnnek meg. (Safari is the new IE )
- Nagyon könnyű tévútra menni, és ennek következtében (abszolút és UX-es értelemben is) lassú, működésében hibás, neadjisten biztonságilag kockázatos kódot írni!
- Tanulni kell. Egy tiszta JS alkalmazás ég és föld ahhoz a szinthez képest, amikor egy sablonból generált HTML oldal kis szakaszait jQueryvel ugráltatja az ember. Az azzal kapcsolatos tapasztalatok inkább veszélyesek, mint hasznosak.(*): Ehhez igazából nem kell SPA, csak egy jó környezet meg önfegyelem. Például a legtöbb értelmes MVC megvalósításban teljesen független az üzleti logika a HTML generálástól (megjelenítéstől).
Személy szerint Drupalt soha nem használtam, a Foundationt is csak kerülgettem (inkább Bootstrapeztem); de az elgondolás nemes, és ha a szerveroldalad képes az adatait strukturált formában kiadni, szerintem mindenképpen megér egy próbát. Sajnos nem tudom, hol lehetne jól elindulni nulláról, bár az Angular 1.4-hez az ng-book elég bíztató. Valaki segítsen ki!
-
_ak_
addikt
Sziasztok!
A következőben szeretnék tőletek egy kis iránymutatást kérni.
Egy olyan "weboldalra" lenne szükség, amit 99%-ban mobilról vagy tabletről használnának. Nálunk jelenleg, válogatás nélkül, mindent drupallal oldanak meg, amit Zurb Foundation-el alakítok mobil készre. Általában ennyi elég is, de jelen esetben úgy érzem, hogy nem a legjobb megoldás.
Véleményem szerint remek választás lenne a Foundation for Apps keretrendszer használata és a drupal csak a backend részét töltené be, ami JSON adatokat küld, tehát utóbbi tényleg csak tartalomkezelésre lenne használva, míg előbbinek csak meg kell jelenítenie azt.A gondom az, hogy eddig nem dolgoztam még ilyen formában sem javascriptel, sem JSON adattal. Nem tudom, hogy hogyan lehetne a kettőt összehozni.
Egyrészt nektek erről mi a véleményetek, másrészről pedig találkoztatok-e ilyen vagy ilyesmi párosítással? Én sajnos elbuktam a google teszten és nem is tudom, hogy merre induljak, hogy ez működjön, így ha jó az ötlet, akkor szükségem lenne egy pár kulcsszóra, vagy jó tutorialra, amin el tudnék indulni.
-
-
slice14
veterán
válasz
Mr Dini
#5432
üzenetére
Itt inkább a probléma a hiányzó adatoknál lehet csak legfeljebb, mert ha nincs adat az adott változóhoz, akkor a változó nevét jeleníti meg a tasker a notifiben, sceneben vagy akár a zooperben. De mivel nem volt ehhez hasonló megoldás a kódban, így marad az if.
Na de nem a hiányzó adat volt a téma.
-
Karma leírta a lényeget.
Ez egy Taskerre készült parser. A taskerben pedig van JSON parse. Egyébként jQuery-t is lehet használni, csak ki kell választani mint plusz library.
A cél a sebesség volt, illetve, h olyan laikusok, mint én is könnyen tudjanak a kódhoz plusz részt írni a későbbiekben, ha szükség lesz rá.
Szerintem ez sikerült hála slice14-nek, Karmának és a többieknek a Js topikból!
Ui.: egyébként amit a rawdata változóba raktál(fájl tartalma) azt a tasker beépített parancsaival egy sorral is meg lehet oldani. ("readFile('xy')")
-
Karma
félisten
-
#5427
Karma
félisten
PumpkinSeed
#5426
Karma
félisten
válasz
PumpkinSeed
#5426
üzenetére
Köszi, próbálkozom
Egyébként szoftverfejlesztő vagyok, jelenleg szabadúszom (egy nagy Angular projekten dolgozom főleg most), azelőtt Android/WP/iOS fejlesztőként dolgoztam, azelőtt salátában sokmindent (BI, Java SE alapon hatalmas rendszerek foltozása, SIM programozás), azelőtt meg Symbian fejlesztő voltam. Keresem a magasabb rendű rendezőelveket a tervezés/fejlesztés mögött (ld. Martin Fowler munkásságát, számomra példakép), a sok lexikális dolog meg egyszerűen rámragad. Kivéve a PHP-t, azzal taszítjuk egymást
-
slice14
veterán
válasz
slice14
#5423
üzenetére
Tudok a js-be a convert parancsnak változót adni, hogy a weather-t áztkonvertálja htmltoText-é? Több helyen kéne konvertálni és nem akarom átírni másik változóba a weather-t ha nem muszáj.
currentWeather = currentObservation.getWeather(),
Vagy nem kell változó, csak beírom a () közé a parancsot?
-
Jim-Y
veterán
válasz
slice14
#5419
üzenetére
Hat, hogy oszinte legyek sokkal jobb
Meg van 1-2 aprosag amit mashogy csinalnek. Peldaul arra nem lehet alapozni, hogy a hordozo kornyezet majd rendelkezik JSON parserrel ezert ha van lehetoseg jQuery-t hasznalni akkor javaslom.
Es akkor:
function getData(fileName) {
var rawData = readFile(),
parsedData;
try {
parsedData = $.parseJSON(rawData);
}
catch (ex) {
console.error(PARSE_DATA_ERR, ex);
}
return parsedData || {};
}Ha nincs lehetoseg jQuery-t hasznalni akkor pedig biztos ami tuti ellenorizzetek le, hogy van-e JSON object mint ahogy a jQ is csinalja:
// Attempt to parse using the native JSON parser first
if ( window.JSON && window.JSON.parse ) {
return window.JSON.parse( data );
} -
tick
aktív tag
Segítséget kérnék megérteni a lenti kódot. Működik, de nem értem hogyan
(nodejs stream-adventure / html stream feladat)var trumpet = require('trumpet');
var through = require('through2-map');
var tr = trumpet();
tr.pipe(process.stdout);
tr.selectAll('.loud', function(data) {
var stream = data.createStream();
stream.pipe(through(function(chunk) {
return chunk.toString().toUpperCase();
})).pipe(stream);
});
process.stdin.pipe(tr);"tr.selectAll": kap egy szűrőt és egy callback-et. A callback fv-ben definiálok egy új változót, pipeolom through-ba ahol átalakítom, majd önmagába pipeolom vissza. Eddig tiszta sor.
Viszont hogy kerül vissza? Closure-ben lett létrehozva és semmi függvény (ami return-ként működne) nem lett meghívva rá.
Maga a createSteram() köti a "stream" változót closure chainen keresztül "tr"-hoz valahogy? -
inf3rno
nagyúr
Nem mondanám, hogy nem követem a fejleményeket, legalábbis es-el kapcsolatban tisztában vagyok az újdonságokkal. ES7-nél az Object.observe a legfontosabb dolog, de ahogy nézem egyelőre csak a chrome alapú dolgok támogatják. Azon kívül még érdekes az async functions, amit böngészők még nem támogatnak, de babel és traceur igen. Próbálgasd azt, kíváncsi vagyok, hogy mennyire fekszik majd neked. Ajax-al kapcsolatban úgyis async dolgokról kérdeztél. Elvileg ez az es7-es feature a megoldás a velük kapcsolatos minden problémára, ha nagyon optimisták vagyunk...
-
Zedz
addikt
válasz
inf3rno
#5411
üzenetére
"amíg a böngészők nem támogatják es6-ot"
Szerintem ez téves hozzá állás. Olyan szempontból, hogy ebben a szakmában nem árt, ha naprakész az ember. A teljes ES6 támogatásra még várni kell, illetve az visszafelé nem tudom hogyan fog működni, ezzel pedig a régebbi böngészőkre is tudod használni az ES6 fícsöröket.
Én a fentebb említett hobbi projekt keretein belül pont a browserifyt, babelt és reactot próbálgatom.
(#5412) martonx: ES7 pár funkciója még kísérleti fázisban van a Babelben. ES6 (ES2015) most kezd divatba jönni, a hype vonat már elhagyta az állomást.
-
inf3rno
nagyúr
Ennyire nem folytam bele babel-be. Nekem van saját class lib-em úh. nem adna semmi extrát, amíg a böngészők nem támogatják es6-ot, addig meg nem foglalkozok vele. Nem szeretnék compilert, ha nem muszáj, megszoktam már így. Később lehet, hogy változik, ha rászokok a browserify-ra böngészőnél meg arra is, hogy sűrűbben használjam a gulp-ot.
-
inf3rno
nagyúr
Hát sok sikert, van amúgy kismillió ilyen nyelv, ami js-re fordul, itt [link] a felső sor nagyjából lefedi, hogy mivel érdemes foglalkozni. Persze még ezen kívül is van egy csomó, mint pl coffee, de attól meg már falra mászok. Én a normál js-t szeretem, az ilyen compiler-ekkel nem vagyok kibékülve. Azért lehet, hogy később én is csinálok egy saját nyelvet compiler-el aszinkron dolgok kezelésére, mert megvan róla a saját elképzelésem.
-
-
Sziasztok!
Tudom, h az if alap, de én is full alap (kuka) vagyok a témában...
Az lenne a kérdésem, h ifben hogy lehet megadni, h mondjuk akkor fusson le a benne lévő kódrész, ha xy=0, vagy mondjuk yx=0?
Az megvan, h egy változó, meg az "és" is, csak a vagy nincs meg.
Létezik ilyen?
Köszi!
-
inf3rno
nagyúr
A gond itt, hogy az ajax aszinkron, te meg szinkron gondolkodsz. Az ajax-nál elmegy a kérés szerver felé, és egy eseményt vált ki, ha megjött a válasz, hasonlóan, mint pl onclick-nél is csak akkor fut az eseménykezelő, ha kattintás történt. Szóval miközben megy az ajax, a szinkron kód ugyanúgy dolgozik tovább, nem vár arra, hogy megjöjjön a válasz, a választ lekezelni az eseménykezelő dolga. Két dolgot tehetsz. Vagy alkalmazkodsz és aszinkron kódot írsz callback-el, vagy beállítod, hogy szinkron legyen az ajax kérés. Általában inkább az előbbit szokták javasolni, és a szinkron ajax-ot bad practice-nek tekintik, de te döntöd el, hogy neked mi a jó.
-
Karma
félisten
"Rögtön a létrehozás után egy ajax kéréssel értéket is adok ennek a változónak."
Az aszinkronitás erősen kulcsfontosságú kérdés JavaScriptben, úgyhogy amellett, hogy az előbb linkelt példakódból összeollózód magadnak a probléma megoldását, javaslom minél előbb dobd el a hibás gondolkodást. Hamar hozzá lehet szokni a jövő idővel való számoláshoz, a promise-ok meg elég jól kezelhetőek.
Persze ES7-tel sokkal szebb lesz.
Írtam is nekik levelet ezzel kapcsolatban, hogy emiatt szoktam le a cikkjeik olvasásáról, hogy azóta is van-e ez a jelenség, fogalmam sincs, mert tényleg nem olvasom őket. 
De azert probalkozik az ember mert igeny (most mar) lenne ra. Legalabbis fejlesztoi oldarol.
Új hozzászólás Aktív témák
Hirdetés
- 16GB-os SODIMM (notebook) DDR4 RAM bazár - nézz be, lesz, ami kell neked!
- HP 15-af105nh laptop (15,6FHD/AmdQuad/4GB/128SSD/Magyar) - Akku X
- JOYOR S5 Pro 10" Elektromos Roller 26Ah Akkumulátorral Moddolt!
- XPS 13 9310 13.4" FHD+ IPS i7-1185G7 16GB 512GB NVMe ujjlolv IR kam gar
- Megkimélt Apple iPhone 8 Plus 64GB Fekete szinben, 100% akkuval, kártyafüggetlen, garanciával
- Bomba ár! Lenovo ThinkPad T460 - i5-6GEN I 8GB I 256SSD I 14" FHD I Cam I W10 I Garancia!
- BESZÁMÍTÁS! MSI X470 R7 5800X 32GB DDR4 512GB SSD ROG STRIX RTX 2080 Super 8GB Rampage SHIVA 650W
- HYNIX 2GB DDR3 RAM eladó
- Tablet felvásárlás!! Samsung Galaxy Tab A8, Samsung Galaxy Tab A9, Samsung Galaxy Tab S6 Lite
- Telefon felváráslás!! Xiaomi 13T, Xiaomi 13T Pro, Xiaomi 14T, Xiaomi 14T Pro
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest