- Macrodroid
- Motorola Edge 30 Neo - wake up, Jr...
- Motorola Moto Tag - nyomom, követ
- One mobilszolgáltatások
- Samsung Galaxy A54 - türelemjáték
- Xiaomi 14T - nem baj, hogy nem Pro
- India felől közelít egy 7550 mAh-s Redmi
- Samsung Galaxy S23 Ultra - non plus ultra
- Vivo X200 Pro - a kétszázát!
- Xiaomi 14T Pro - teljes a család?
-
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
-
DNReNTi
őstag
Csak tippelem, nem probaltam, de talan azert mert a
getUserNameFromServer()nem egy boolean-nal hanem promise-szal ter vissza. Egyebkent tok fura nekem hogy a service-ben subscribe-olsz az observable-re, en ezt eddig mindig ugy csinaltam, hogy az observable-t adtam vissza. Nem tudom melyik a best ptactice, majd utanaolvasok. -
Venyera7
senior tag
-
#6423
PumpkinSeed
addikt
Zedz
#6421
PumpkinSeed
addikt
Mi OAuth-t használunk beléptetésre. De a JWT szerintem nem egy túl jó megoldás beléptetésre, csak arra, hogy biztonságosan megtartsuk az adatokat a kommunikáció során. Az Oauth azért is jó, mert a token-ek miatt több szolgáltatás esetén is tudod kezelni a belépést. Esetleg JWT-t használhatsz arra, hogy megoszd a token-eket.
-
#6417
fordfairlane
veterán
Zedz
#6415
fordfairlane
veterán
Tényleg nem tudom hová tenni a dolgot. Nem tusok sokat a Typescriptről, de tudtommal az object abban is object.
Ha jelen esetben auth.userProfile egy object, és van neki egy username nevű property-je, elvileg teljesen mindegy kell hogy legyen az, hogy dot notation vagy bracket - subscript notation-nel próbálod elérni. Még abban az esetben is, ha nem sima propertyről van szó, hanem getter-setter függvényről.
-
DNReNTi
őstag
Furcsa, mert szerintem is mukodnie kellene, bar sose hasznaltam igy, es ezzel eljutunk oda: hogy egyebkent ennek igy mi ertelme? Marmint, a komponensedben rendelkezesre all az egesz Auth osztaly, benne minden user adattal, mi szukseg akkor kiszervezni plusz egy attributumba a felhasznalonevet?
Egyebkent ez lehet (tenyleg csak tipp), valami TS specifikus dolog. Az Auth.userProfile tipusa sima Object, nincs interface vagy valami specifikus osztaly (pl UserProfile osztaly) ami leirna, hogy milyen attributumai vannak, tehat feltetelezheti, hogy nincs username property, es ezt te amugy nem is ellenorzod. Bar ha igy lenne akkor mar szerintem a TSC dobna warning-ot. Egyebkent pont ilyenkor jon jol hogy a TS tipusos, tessek hasznalni, egy userProfile ne legyen mar egy standard osztaly! 
Remelem segit megoldani. 
-
sztanozs
veterán
A JS-t viszont most tolják minden platformra, boldog-boldogtalan abban fejleszt, a PHP pedig mindig is a szerveren maradt.
Ez amúgy szerintem a JS egyik nagy problémája.
Mivel a JS egy (jelentős) része kliens oldalon fut és lehetőség sincs a forrás védelmére vagy validálására, így maga a JS, mint platform rendkívül sebezhető. -
martonx
veterán
"Szvsz semmi értelme folyamatosan felszállni bármilyen hype vonatra" - köszi a helyesbítést.
Igen ez általánosan is igaz, és nehogy félreértsétek, ez nem azt jelenti, hogy ragadjunk a múltban, és soha ne próbáljunk ki semmi újat.
Egyszerűen csak egy idő után, mikor az ember már eleget látott, többet ráadásul újra és újra, akkor kialakul egyfajta "lényeglátás", amivel meg kell tudni különböztetni, hogy akkor ez most egy normális trend, és valóban előre visz, vagy csak egy újabb hype, amit valami eleve rossz irányra adott, szintén nem feltétlenül jó választ szült.
Azt látom, hogy a fentiekben a js világ (átvéve a szerepet a php-tól) jelenleg világelső. -
martonx
veterán
ASP.Net Core-ban is biztosan van: [link]
Szvsz az SSR-nek nagyobb a füstje, mint a lángja, vagy inkább fából vaskarika, ha már server side prerendering kell, akkor megette a fene az egészet, és erősen megkérdőjeleződik, hogy van-e értelme az adott projekten SPA-zni.
Azaz ha szerver oldalon akarsz renderelni, akkor - most tessék megkapaszkodni - azt megírhatod bármilyen klasszikus szerver oldali nyelven, bármilyen rendering engine-el, ahogy az az elmúlt évtizedekben szokás volt. De ez csak a magánvéleményem.
A történelem ismétli önmagát (de js-ben ennyire gyorsan???). Először minden szerver oldalon renderelődött, a js-csak némi cukormáz volt. Aztán jöttek a js heavy SPA-k, jaj szerver oldalon fúj, ne rendereljünk semmit, mert az olyan oldschool, meg fúj, meg ugyanmár. Aztán kiderült, hogy annyira azért még se volt hülyeség a szerver oldali rendering, de akkor már nehogy visszatérjünk a szerver oldali renderinghez, hanem oldjuk meg, hogy az SPA-nk renderelődjön szerver oldalon
Szvsz semmi értelme folyamatosan felszállni a js világban száguldozó hype vonatokra. -
-
-
-
martonx
veterán
Ha itt összehasonlítod a bal és a jobb oldalt. Értem én, hogy mostanra már class-okat is lehet js-ben létrehozni - 2016-ban hűha, de én már évek óta várom, hogy a jquery kikophasson végre a fenébe, és legalább ezeket a nulladik szintű funkcionalitásokat tudja maga a nyelv mindenféle boilerplate kód nélkül.
-
Jim-Y
veterán
Üdv,
Szerintem browserify nem kell mert a systemjs azt production módban megoldja. Nem vagyok nagy szakija ennek a systemjs-nek, de itt nem arról van szó, hogy development "módban" olyan mint a RequireJS (AMD) tehát nem kell bundling, production-ben pedig olyan mint egy browserify/webpack. Persze ha node-os packagek kellenek ahhoz kell bundling.
Na, lényeg a lényeg ott van a hiba hogy a num nevű változót próbálod behívni a modulból holott lel-ként exportáltad. Különbség van az "export default" és az export között. Példa program
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>The HTML5 Herald</title>
<meta name="description" content="The HTML5 Herald">
<meta name="author" content="SitePoint">
<!--[if lt IE 9]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
</head>
<body>
<script src="jspm_packages/system.js"></script>
<script src="config.js"></script>
<script>
System.import('app/app.js')
</script>
</body>
</html>app.js
import nameItAsYouLike from './module';
import { otherStuff } from './module2';
console.log(nameItAsYouLike);
console.log(otherStuff);module.js
const stuff = 42;
export default stuff;module2.js
export const otherStuff = 43;
üdv
-
martonx
veterán
Egyébként én is ezt látom, hogy nagyon nyomják mindenhol a TS-t, de igaziból pont ha már az ember egy normálisabb MVVM megközelítést használ, elég felesleges a plusz TS-es körök belevitele a történetbe.
Ugyanakkor el tudok egy olyan kód komplexitást képzelni, ahol megfordul a dolog, és a több száz osztály, több tízezer sorjánál hirtelen megéri az a pici plusz fáradtság, hogy már a kód írása közben kiderüljön, ha valami típus eltérés bibi lesz valahol. -
martonx
veterán
-
DNReNTi
őstag
Ha jobban megnézed, SO-n is úgy van megoldva ahogy én is írtam, igaz szóközre lenyomásra. Van egy tag-editor osztályú div, abban egy span, és egy input. Itt sem az inputon belül maradnak a tag-ek, csak szépen trükkösen meg van csinálva, hogy úgy tűnjön mintha. Valójában a span-ba kerülnek át space lenyomáskor. JQuery-vel ezt baromi egyszerű megoldani, de még talán plain js-sel sem egy ördöglakat.
(#5859) Sk8erPeter
Jogos. -
-
martonx
veterán
ASP.NET-en a konyhakész SignalR-t használom websocketezéshez windows szerveren IIS-el hosztingolva. Ez azért fontos, mert amit magamnak kitaláltam, az nem biztos hogy máshol is így van. No, SignalR-nél 64Kybte-ban maximalizálták a csomagok méretét, de tapasztalataim alapján 32K fölött és elég nagy számú csomag mozgásnál elkezd instabil lenni a dolog. Ahogy utána olvastam, valami pufferek viszonylag könnyen be tudnak telni a webszerveren websocket esetben.
Innen jött a 32KByte-os önkorlátom, így atom stabil komolyabb terhelés mellett is. Meg valóban igaz is, hogy a websocket nagyon gyors kétirányú kommunikációra lett kitalálva pici csomagokkal, nem pedig nagy csomagok lassú egyirányú kommunikációjára mint a http. Szóval már csak architekturálisan is szerintem alapvető hibát jelez, ha az ember elkezd több száz K-t áttolni websocketen.
-
#5786
Sk8erPeter
nagyúr
Zedz
#5785
Sk8erPeter
nagyúr
Jaja, kicsit megváltozott a jsFiddle, amúgy szerintem előnyére, legalábbis nekem jobban bejön, jobb helyen vannak a JS library-k annál a lenyílónál.
Picit tényleg fura ez a Language megnevezés, de végül is ha úgy vesszük, ezek tényleg mintha más nyelvek lennének, más szintaktikát használsz, a JavaScript sajátjánál sokkal értelmesebbet.![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#5784
Sk8erPeter
nagyúr
Zedz
#5783
Sk8erPeter
nagyúr
Be van húzva:
De amúgy bocsi, asszem hülyeséget mondtam, és igazad van, JavaScriptre visszaváltva elég a "use strict"; az elejére, és Blink-motorral menni fog ("Uncaught SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode"). Firefoxban még nem ("SyntaxError: let is a reserved identifier"). Mindenesetre ezeket a problémákat áthidalja a Babel.
-
inf3rno
nagyúr
Szvsz a TDD nem advanced dolog, hanem alapvető, ha fejleszteni akarsz. Ha nem ismered, nagyjából arról szól, hogy először a tesztet írod, utána meg az implementációt, mindezt kis kód részletekben. Így a végére a kód nagyjához lesz automatizált teszted. Menet közben is hasznos, mert a hibák azonnal kiderülnek, és nem kell utánanyomoznod órákat debug-al, hogy hol hasal el a kód. Én már inkább a BDD fele hajlok, annál először szövegesen írod le, hogy mit akarsz, aztán azt fordítod át tesztekre. Így a teszteket bármikor kicserélheted, úgy, hogy a szöveg változatlan marad. Ez sokkal rugalmasabb, mint a TDD, pl ugyanazok alapján a leírások alapján egy csomót azonos képességű eltérő klienst tudsz fejleszteni, esetleg eltérő API-kat kipróbálni, és így tovább.
-
inf3rno
nagyúr
Megértelek, a dev környezet kiépítésére sajnálom leginkább az időt. Inkább leülök olvasni, vagy kódolok, minthogy erre menjenek el napjaim. Nekem nem tűnik annyira szélesen támogatottnak ez a sourcemap dolog, de egyelőre még csak firefox-ban néztem meg, elképzelhető, hogy más böngészőkben jobb a helyzet. Az elvet sem pontosan tudom, ami mögötte van, pl hogy lehetséges e több fájlt és azok kódjait betenni egy sourcemap-be, az is kérdés. Jelenleg csak a babelhez meg a minifyolt változathoz kellene, máshoz nemigen, szóval meg tudnám oldani nélküle is. Amit idáig összetákoltam dev környezetnek karmával meg nodejs-el az egész jó, át fogok térni rá a projektjeimnél, fejlettebb, mint amit előtte toltam.
-
inf3rno
nagyúr
Próbálkoztam sourcemaps-el, de nem nagyon lehet ráhúzni. Nekem legalábbis nem sikerült egyelőre. Te hogyan debuggolsz babellel? Én egyelőre sima browserify + ugify-al próbáltam sourcemaps-et a gulp-sourcemaps-el, de csak a bundle tartalmát látom firebug-ban, a forrás fájlokat nem, illetve hibánál a sor is a tömörített fájlra vonatkozik, szóval mindig 1. Így egyáltalán nem használható debug-ra. Még próbálkozom. Ha mégis összejönne, akkor megpróbálom babel-re is.
Láttam, hogy van karma-cucumber, szóval elvileg cucumber-el is lehetne tesztelni, nem muszáj a jasmine. Majd megpróbálom azt is, mert nekem a BDD szimpatikusabb, mint a szimpla TDD, amit jasmine jelenleg támogat. Furának tartom, hogy azt írják jasmine dokumentációban, hogy BDD keretrendszer, amikor köze nincsen hozzá.
-
inf3rno
nagyúr
Ja, mindenki azt használ.
Na összeszórtam babel-el is, nehéz szülés volt, mármint a nodejs jasmine teszt vele. [link] A végén úgy döntöttem, hogy becsomagolom browserify-al az egészet egy pack-ba, aztán úgy tesztelem. Próbáltam jest-el is, annak elvileg van preprocessor-a, ami babel-el átalakítja, de bugos. Facebook fejlesztők kontár munkája...
Úh. azzal nem jött össze a dolog. Most megy, de kellene még bele egy source map, amit nem tudom, hogy fel tudok e építeni browserify+babelify+uglify kimenetéből. Talán ha minden összejön, akkor igen. A következő probléma meg az lesz, hogy hogyan alakítom át a jasmine hibaüzeneteit a bundle-ről valami épkézláb dologgá a sourcemap segítségével. Meglájuk. Még úgysem használtam sosem ilyesmit. -
inf3rno
nagyúr
C#-ot valszeg nem fogom, mert búcsút mondok a windows-nak. A java szimpi, de csak fél évet foglalkoztam vele, akkor se túl komolyan. Jobb szeretem a könnyű súlyú dolgokat. Majd talán kisebb asztali alkalmazásokat rakok össze java-ban. De elvileg már node-al is lehet ilyesmit. Az android még ami izgat.
-
inf3rno
nagyúr
Persze egy ideje ismerkedek vele, tisztább, szárazabb érzés a PHP után. PHP kb olyan, mintha a fél karom hiányozna, mert a webszerver kezeli a thread-eket, meg csak szinkron kódot lehet írni vele. (Tudom, hogy van appszerver, meg nagyon próbálják pusholni páran az aszinkron PHP-t, de rajtuk kívül senki nem veszi komolyan.)
Azért a nodejs is gyerek még, nagyon kell neki, hogy stabil támogatás legyen az ES7 async function-ön. Így future-ökkel el lehet bohóckodni, de nem az igazi. Most próbálok egy object stream-hez hasonló belső üzenetküldőt csinálni aszinkron kódoláshoz. Meglátjuk hova jutok vele. Igazából már 1 éve elkezdtem hobbiból, aztán azóta már egyszer újraírtam, és most fogom másodszor is. Tisztul a dolog. Nem tudom mások hogy írnak keretrendszereket, de nekem mindig kell 2-3-4 újraírós ciklus, amitől egyre szebb meg egyszerűbb lesz a kód. Úgy néztem azért másoknál is jellemző, hogy teljesen újraírják őket, pl ext4 vagy nanomsg (ami zeromq2), symfony2, és így tovább. Nagyon ritka, hogy elsőre megtalálja a legjobb megoldást az ember.
-
inf3rno
nagyúr
Magával a nyelvvel csak annyi, hogy xarból nem lehet várat építeni. A PHP4 kb olyan volt, mint a js-ben a típusellenőrzés. Azóta rátákoltak a tetejére egy oop réteget, kb. ennyi történt. Ugyanúgy szinkron, nem lehet aszinkron kódot írni benne, sem többszálút. Általában aztán az van, hogy az ügyfél kiválasztja magának a legolcsóbb tárhelyet, megveszi, kattintgat párat joomlában, vagy hasonló CMS-ben, aztán rájön, hogy ehhez nem ért, és akkor fejlesszek neki PHP-ben LAMP-ra valamit, feléből mennyit engedek alapon. A másik lehetőség ugyanez, csak az első versenyző spagetti kódban már félig összegányolta mielőtt belezavarodott a saját kódjába, és feladta, és hát nekem már csak "alig valamit" kell lekódolni. Meguntam ezt az életérzést. Úgy döntöttem, hogy ez így nem vezet sehova. Inkább elméletben képzem magam addig könyvekből, amennyi nekem kell, DDD, BDD, REST, SOLID, meg hasonló betűszavak terén, aztán ezentúl csak saját projekteket csinálok, pénzt meg másból keresek. Ennyi a bajom az egésszel.
Itt a karmás [link]. Egyelőre nem találtam még olyat, amivel jasmine teszteket össze tudok kombinálni babel-el, más dolgom volt. A Jest elvileg jó rá, gyakorlatilag jobb szeretném megoldani először anélkül.
-
inf3rno
nagyúr
Egy jó ideje már jasmine-el tesztelek TDD-vel, újabban meg cucumber-el BDD-vel. Szerintem jasmine teljesen alkalmas munkára. Mocha-t is megpróbáltam annak idején, de nem sikerült elindítani sem...
Most nem melózok egy ideje, biomérnök állást keresek, meguntam a programozást, mármint azt a részét, hogy tucat webshopokat kell php-ben programozni. Ki nem állhatom azt a nyelvet, elég volt belőle pár év.Jövőre ha lesz egy kis szabadidőm labor mellett, akkor összeszórok egy cucumber+jasmine kombinációt, mert a mostani cucumber elég fapados, és csak annyira lenne szükség, hogy jasmine fölé építsünk egy speckó test loadert, ami a gherkin syntax-os scenario-kat lefordítja jasmine-re. Ezt azért pár hét alatt össze lehet hozni sztem. Elvileg talán még gherkin parser is van készen, csak össze kell tákolni a jasmine-el.
Közben sikerült összekombinálni jasmine+browserify+karma+gulp-ot. Még dolgozok rajta pár órát, aztán felteszek egy project templatet github-ra. Jó lenne még ilyen finomságokat, hogy sourcemap meg coverage meg ilyesmik is beletenni. Talán majd később. Ha fent van, akkor hozzácsapok egy babelify-t is külön branch-en aztán belinkelem.
-
inf3rno
nagyúr
Egyelőre eddig jutottam vele:
var browserify = require("browserify"),
fs = require("fs");
module.exports = function () {
return browserify()
.require("./dist/nodelist.latest.node.min", {expose: "nodelist"})
.bundle()
.pipe(fs.createWriteStream("dist/nodelist.latest.bundle.js"));
};Annyi jött le, hogy a bundle() egy readable stream-et ad, amit aztán át lehet pipe-olni fájl írós stream-be. Ebben az esetben csak egy modult csomagoltam bele, és publikussá tettem, mert böngészős jasmine tesztekből akarom elérni. Ha magamnak fejlesztettem volna, akkor karma-browserify-t rakok alá, és nem mentem ki külön fájlba, de az már más kérdés.
A te régi kódod elvileg nagyjából jó, csak a glob-ot kéne hozzácsapni. A vinyl source egy douplex stream, ami hozzácsapja a fájlnevet, szóval csak simán át kell küldeni rajta, aztán a dest-hez adni. Azt nem néztem még, hogy pontosan a fájlnév hozzáadása hogyan történik, gondolom van valami konvenciójuk rá, lényegtelen.
gulp.task('js', function () {
return browserify({
entries: glob('./resources/assets/js/*.js'),
debug: true,
transform: [babelify]
})
.bundle()
.pipe(source('bundle.js'))
.pipe(gulp.dest('./public/assets/js'));
});A recipes-ben is amúgy valami ilyesmit használnak. [link]
Egyelőre még nem volt időm megnézni, mindjárt kipróbálom. Annyira nem vagyok elszállva babel-től, mint sokan. Valszeg nem fogom használni, inkább megvárom, amíg stabil lesz az async function. Azt írják, hogy draft jelenleg: [link], ami nekem nem elég.
Amúgy semmi gond nincs gulp-browserify-al, amíg kompatibilis gulp-al. Kösd meg, hogy 3.x-es gulp legyen a lib-ed függősége, mert azt írják, csak azzal kompatibilis. Valszeg a 4.0-s gulp-al el fog törni.
-
inf3rno
nagyúr
Azt hiszem egyelőre most én is hagyom. Nem én csinálom a projektet, csak a csomagolás részébe segítek bele, aztán gondoltam legalább az legyen TDD alapon. Legalább egy pár szimpla jasmine tesztet írok majd arra, hogy megy e a böngészőben a lib vagy nem. A jquery-t akarja kiváltani vele a srác. [link]
Ha valakit érdekel, akkor karma-ban singeRun-al így oldható meg rendesen:
var karma = require("karma");
module.exports = function (done) {
var server = new karma.Server({
configFile: "../../../karma.conf.js",
singleRun: true
}, function (exitCode) {
done();
});
server.start();
};Az előző kód valamiért singleRun: true esetében ha hibás volt a teszt, akkor elszállt valamilyen gulp hibával. Nem értek a lelki világához, debugra meg most nem igazán van időm. Ennél is fontos, hogy a karma config fájlban __dirname-t használjunk, különben rossz helyet állít be basePath-nak. Ne kérdezzétek miért, valszeg ez is egy bug lehet. Már reportoltam.
-
inf3rno
nagyúr
Azt nézem hatalmas különbség nincsen, csak annyi, hogy streamelhetővé teszi browserify-t. Elméletileg enélkül is működnie kellett volna sima callback-el. Így azért szerintem sokkal szebb, hogy tudja a gulp src-t használni, és nem kell glob-ot meg ilyesmiket beletákolni a kódba. Majd ha kipróbálom babel-t, akkor visszatérek ehhez. A webpack-re azt mondják, hogy babel-el gyorsabban csomagol, meg hogy kisebb a minified fájlméret is. Azért nem olyan egyszerű belőni, mint a browserify-t.
Karmával van tapasztalatod? Azzal küzdök, hogy gulp task-el szervert indítsak, ami nem záródik be a gulp task végén sem. Gondolom child process-be kellene tenni valahogy, és belőni daemon-nak a child process-t. Egyelőre idáig jutottam:
var karma = require("karma"),
gutil = require("gutil");
module.exports = function (done) {
var server = new karma.Server({
configFile: "../../../karma.conf.js"
});
server.on("browser_error", function (browser, err) {
gutil.log("Karma Run Failed: " + err.message);
throw err;
});
server.on("run_complete", function (browsers, results) {
gutil.log("Karma Run Complete: " + results.failed ? "Some of the Tests Failed" : "No Failures");
done();
});
server.start();
};module.exports = function (config) {
config.set({
basePath: __dirname,
frameworks: ['jasmine'],
files: [
{pattern: 'src/nodelist.js', included: true},
{pattern: 'tests/*.js', included: true}
],
exclude: [],
reporters: ['progress'],
port: 9876,
colors: true,
logLevel: config.LOG_INFO,
autoWatch: true,
browsers: ['Firefox'],
captureTimeout: 6000,
singleRun: false
});
};Az a kínja most, hogy a teszt futása közben megakad az egész a singleRun: false miatt. Gondolom ezt a részt valahogy ki kellene szervezni child process-be, aztán megpingelni a szervert, hogy fel van e lőve. Ha igen, akkor meg hagyni, hadd dolgozzon. A gond csak az, hogy elvileg ezt a karma magától megteszi. Szóval nem tudom, hogy melyik részt lenne érdemes child process-be tenni, és hogyan kommunikálni vele. Láttam, hogy van olyan, hogy karma client, lehet, hogy a szervert miután a child process-be tettem csinálni kell egy client-et, ami majd kommunikál vele. Gondolom a fájl frissítéseket az autoWatch automatikusan megcsinálja, szóval azzal a részével nem lenne gond. Hát egyelőre zavaros, dokumentáció meg általában nem nagyon van ilyen mélyebb dolgokról. Majd feltúrom a kódot, aztán lesz valami.
-
inf3rno
nagyúr
Közben kiderült, hogy a sorrend stimmel. A gond nem ezzel van, hanem nagy valószínűséggel az entries nem fogad glob patternt, csak útvonalakat egy tömbben. Szóval ha egy glob kimenetet rátennél, akkor valszeg működne. Legalábbis a példakódok alapján, amiket eddig láttam. [link]
-
inf3rno
nagyúr
Hát ilyenkor első körben érdemes lenne konzolba kiíratni, hogy mégis mi a browserify({ entries: './resources/assets/js/*.js', debug: true }).transform értéke, ha nem függvény. Gondolom undefined. Ránézésre én azt mondanám, hogy először kellene a babel kódot átalakítani normál js-re, és csak utána átküldeni browserify-on, mert úgy sejtem, hogy a browserify nem tudja feldolgozni a babel kódját. A kód alapján pont fordítva ülsz a lovon. Persze lehet, hogy én tévedek. Browserify-t ma akarom fellőni először gulp-al, karmával meg nightwatch-al egy böngészős projekt tesztelésére. Az utóbbi kettő már ment, de elfelejtettem mióta utoljára használtam őket.
-
-
inf3rno
nagyúr
Babel-el kapcsolatban tudsz némi információval szolgálni? Leginkább az érdekelne, hogy async function és Object.observe mennyire működik vele msie alatt (gondolom babelify + browserify amit használni kellene hozzá). Ha ott megy, akkor mindenhol. Ha meg ennyire széles a support, akkor nem szórakozok ES5-el, hanem inkább áttérek rá én is.
-
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...
-
#5465
fordfairlane
veterán
Zedz
#5459
-
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)
-
-
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.
-
Karma
félisten
-
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...
-
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.
-
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.
-
-
inf3rno
nagyúr
Ez csak hobbi projekt, nem üzleti. Magamnak írok egy edzéstervezőt meg naplózót, mert már unom az Endomondo meg Strava hülyeségeit.
Hát lehetne éppen C#-al is, csak ahhoz nem értek, meg nincs kedvem megvenni a Visual Studio-t. Más alternatíva meg js-ben sajnos most nincsen. Van olyan, hogy NodeRT, ami szintén valami WinRT-s C-s dolgot fordít be dll-be, ha jól tudom, de ahhoz meg node-gyp-et vele együtt meg Visual Studio-t meg Pythont, meg minden hülyeséget fel kellene telepíteni, akkor meg már kézenfekvőbbnek tűnt, hogy WinJs-el lekódolok gyorsan egy Bluetooth-ot használni képes klienst, aztán átküldöm a nodejs szervernek vele az adatokat valamilyen protokollon.
-
Karma
félisten
Néha. Igazából nem sokat szoktam foglalkozni vele, az angular-fullstack Yeoman generátorral szoktam indulni és csak minimálisan piszkálom az általa belőtt Expresst.
Amúgy tényleg olyan, mint a Python (vagy a YAML), mert az indentálás számít. Nekem ezzel amúgy nincs bajom, sőt, de mások szoktak viszolyogni
A témában nem vagyok jártas+ az EDGE böngészőben nem volt ilyen opció csak a chromeban, de megtaláltam a többi meg megy majd a HTML topikjába. Erre jutottam közben:
Egyebkent ez lehet (tenyleg csak tipp), valami TS specifikus dolog. Az Auth.userProfile tipusa sima Object, nincs interface vagy valami specifikus osztaly (pl UserProfile osztaly) ami leirna, hogy milyen attributumai vannak, tehat feltetelezheti, hogy nincs username property, es ezt te amugy nem is ellenorzod. Bar ha igy lenne akkor mar szerintem a TSC dobna warning-ot. Egyebkent pont ilyenkor jon jol hogy a TS tipusos, tessek hasznalni, egy userProfile ne legyen mar egy standard osztaly! 
Remelem segit megoldani. 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- alza vélemények - tapasztalatok
- Macrodroid
- Sütés, főzés és konyhai praktikák
- A fociról könnyedén, egy baráti társaságban
- Genshin Impact (PC, PS4, Android, iOS)
- Revolut
- Melyik tápegységet vegyem?
- Motorola Edge 30 Neo - wake up, Jr...
- Starlink
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- További aktív témák...
- Telefon felvásárlás!! Samsung Galaxy A13/Samsung Galaxy A33/Samsung Galaxy A53
- Samsung Galaxy A52s 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
- AKCIÓ! Apple Macbook Pro 16" 2019 i9 9980HK 64GB DDR4 1TB SSD Radeon Pro 5500M garanciával
- 0% THM 3 havi részlet! Beszámítás, 27% áfa, Sapphire Nitro+ RX 9070XT 16GB készletről
- Csere-Beszámítás! Asus Tuf RTX 5070Ti 16GB GDDR7 Videokártya! Bemutató darab!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest