-
PROHARDVER!
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
-
nevemfel
senior tag
válasz
K1nG HuNp
#8127
üzenetére
megtanulsz kódolni akkor a legtöbb nyelv csak szintax diff lesz
Mégis miről beszélsz? A delikvens nem tudja, hogy mi az a függvény, és mit jelent az, hogy "függvényt meghívni". Visszautasítja a kétszázadik javaslatot is arra vonatkozólag, hogy hol talál leírást, videót, akármit a programozás alapjairól.
-
-
Silεncε
őstag
válasz
K1nG HuNp
#8071
üzenetére
Én se arra gondoltam, amire az előző kolléga értette, hanem hogy egyáltalán nem ír CSS-t aka nem webes fejlesztő, erre vonatkozott a disclaimer is
Nekem most az emotiont kell megtanulni React projekthez, előtte Sass-t használtam, a Sass-al nem volt annyira nagy bajom, viszont ezt a CSS-in-JS-t én kicsit kreált problémának érzem, de fixme...
Az viszont kb totál mindegy, hogy mi hány sor griddel, ha a támogatott böngészők fele fejreáll a gridtől...
-
-
cattus
addikt
válasz
K1nG HuNp
#7881
üzenetére
> Az inline stylekkel ugyszint semmi baj nincs, objektiven gyorsabb egy weboldal betoltese ahol nem egy bazinagy css fajlban szerepel minden, de továbbmegyek, a legtobb css-in-js solutin is "inline" style attributumokkent irodik es run/build-time valik style tagekke.
Az inline style-lal az a baj, hogy se formázás, se autocomplete, se write-time error checket nem kapsz, amikor írod, plusz újrahasználni se tudod a stílusokat. A CSS-in-JS libeknek meg csak az outputja inline style, nem véletlenül nem írsz ott se közvetlenül a style tag-be.
-
Zedz
addikt
válasz
K1nG HuNp
#7794
üzenetére
lesz meno JS routered amiel weblap ujratoltes nelkul tudsz maszkalni az nem azt jelenit hogy SPA lenne az oldalad
Dehogynem, attol lesz SPA, hogy egy "shellben" folyamatosan csereled a tartalmat, dinamikusan, ujratoltes nelkul. Az, hogy ez a cucc most CSR vagy SSR, az mindegy. -
martonx
veterán
válasz
K1nG HuNp
#7789
üzenetére
"es volt valami elegancia abban hogy felpakolsz egy php filet ftpre es fut es atom gyors 123kB js nelkul is" - a PHP előnyei kb. itt meg is állnak
Amúgy meg a server side rendering mindig is nagyságrendekkel gyorsabb volt, nem véletlenül erőltetik majdnem mindenhol az SSR-t. -
#7706
instantwater
addikt
K1nG HuNp
#7705
-
sztanozs
veterán
válasz
K1nG HuNp
#7660
üzenetére
Ami még eszembe jutott az a shared secret.
Szintén PBKDF2-SHA2 funkcióba beledobod a felhasználónak generált azonosítót (256 bit random , vagy szintén PBKDF2-SHA2-256) és ezt sózva a shared secrettel újragenerálva.
A QR kódba kiírod az elsőt - UserID (256 bit) és a másodikat PBKDF(UserID, Shared secret - mint Salt) (szintén 256 bit)
Ez egy 2*32 bájtnyi adatot fog generálni, ami Version 7 High level error correctionbe épp belefér.Ez a modell offline is ellenőrizhető, ha a shared secret és az ellenőrzést végző kód fel van telepítve az olvasóra (pl RPi). Persze az offline-nal az a gond, hogy ugyanazzal a kóddal többen is be tudnak menni, hacsak nem csinálsz lokális hálózatot és érvényteleníted a már beolvasott kódokat (de ennyi erővel már lehet neted is)...
-
sztanozs
veterán
válasz
K1nG HuNp
#7658
üzenetére
Ha a végén nálad fut be minden, akkor az oauth-hoz generálsz egy megfelelően hosszú random számot (vagy hash az emailből akár, megfelelő PBKDF2-SHA2 key generation funkcióval). A QR-nek csak a letárolt számot kell tartalamaznia, és nem tud vele visszaélni se a szervező, se nem lehet rosszindulatú usernek legenerálni, meglevő emailcím alapján.
Persze ehhez kell, hogy a beléptetéskor online tudják ellenőrizni a kódot.Ha offline kell, akkor azt tudod csinálni, hogy digitális aláírással aláírod az azonosítót, amit a szervező ad, és ezt a "csomagot" rakod át QR-be - viszont ez általában meghaladja egy praktikus QR méretét (Version 10).
-
#7659
instantwater
addikt
K1nG HuNp
#7658
-
K1nG HuNp
őstag
válasz
K1nG HuNp
#7655
üzenetére
Megoldás egy URL-be ágyazott JWT token lett, ugyis erre valok
marmint itteni utolso bekezdes alapjan, mostmar csak vhogy a lejaratukat kell megoldani, hogy frontenden automatikusan generalodjanak-frissuljenek, azaz ha nyitva a telefonod kb 2 percig akkor mar 2 kulon jwt-t lattal. -
#7630
instantwater
addikt
K1nG HuNp
#7629
-
#7625
instantwater
addikt
K1nG HuNp
#7624
válasz
K1nG HuNp
#7624
üzenetére
Lerna.js-el manageled a monorepot?
Miért használsz monorepot?Én olyan előnyeit látom, mint a könnyebb kódmegosztás, egy helyen lehet az összes Docker buildelő CI/CD pipelinet kezelni, nem kell minden repóban hozzáadni valamit, ha új lépést akarunk beszúrni.
Milyen beléptető?
Saját adatbázisos vagy valami OAuth szolgáltatást (pl Google) használsz? -
#7608
instantwater
addikt
K1nG HuNp
#7606
-
K1nG HuNp
őstag
válasz
K1nG HuNp
#7605
üzenetére
Ne hagyjatok le a node.js setHeader fv string alapu cookie setterebol a httpOnly utan a ;-t es akkor boldogok lesztek
problem solvedLehet megirom elso medium cikket, mert netet bongeszve sokan szptak ezzel, viszont ha ez a par dolog amire idokozben rajottem/leesett egy nagyon durvan clean code authot lehet csinalni, frontend kodban pontosan 0 sorral
(se cookie savelgetes fn, se token kudozgetes, minden bongeszon kivul tortenik) -
-
#7562
instantwater
addikt
K1nG HuNp
#7561
-
#7560
instantwater
addikt
K1nG HuNp
#7559
-
Dißnäëß
nagyúr
válasz
K1nG HuNp
#7549
üzenetére
Ok köszi, ez is egy vélemény, pláne megerősít, hogy vágjak bele.
Egy alap HTML/CSS/JS-t felszedek w3schools-on (szerintem jó), aztán udemy és utána meglátjuk. Valszeg a tudás nagyja az egyébként valljuk be, itt-ott hiányos alapokra úgyis menet közben jön meg.
Csak ez a k*sok ilyen-olyan-amolyan zárójel, hülyét kapok..
Na, akkor némileg fiatalabb vagy nálam, én 40 és az utolsó kód, amit írtam, nem tegnap volt és szerintem még csak nem is Windows-on
Köszi.
-
#7543
instantwater
addikt
K1nG HuNp
#7542
-
#7516
hiperFizikus
senior tag
K1nG HuNp
#7514
hiperFizikus
senior tag
válasz
K1nG HuNp
#7514
üzenetére
"honnan szedi hogy oldalakban merjuk a kodot"
Hát valamiben mérni kell . Mégis miben méritek ?"meg igy mi akar lenni ez a random if elsek egymas alatt,"
Folyamat megosztás ."ilyen egy senior fejleszto? kappa"
Majd leszel te is idősebb, és a fiatalabb foglalkosztatód majd téged piszkálni fogg . Kíváncsi vagyok, hogy hogyan fog ez esni neked ?
-
#7482
instantwater
addikt
K1nG HuNp
#7479
-
martonx
veterán
válasz
K1nG HuNp
#7452
üzenetére
Képek töltésének figyelése helyett azt szokták csinálni, hogy minden képhez beállítasz egy placeholder-t, és amíg nem érkezik meg a kép, addig az jelenik meg. Persze ez is csak kerülő megoldás. Lazy load-olt képeknél ez elég általános.
Másik bonyolultabb ötletem, hogy minden egyes képre csinálsz egy komponenst, azon belül figyelve az adott kép onload eventjét. Amikor a kép betöltött, akkor a kép komponens státuszát loadingról loadedre váltod. Kívül pedig azt figyeled, hogy minden kép komponensed loaded lett-e (bár persze, mi van, ha egy kép valóban hiányzik), és a szülő státusza csak akkor lesz loaded, ha a képek is loaded-ok.
De szerintem ez egy rakás bohóckodás csak azért, hogy mindenáron vuejs-en belül tarts mindent, miközben az egyszerű megoldásom vuejs nélkül css-ből megoldja az adott problémát és még a UX is rendben lesz, mert hamarabb megjelennek a találatok, a képek meg majd ahogy jönnek lecserélgetik a placeholdereket (ha meg 404-el jön egy-egy kép, akkor marad a placeholder). -
#7454
instantwater
addikt
K1nG HuNp
#7453
-
-
-
Zedz
addikt
válasz
K1nG HuNp
#7283
üzenetére
Nektek ki a front-end developer?
Ahogy az elottem szolo kollegak is irtak, mindenkinek mas. Egyszeru kerdesnek tunik az elejen, aztan kicsit jobban belegondolva azert komplexebb a dolog.
Nekem peldaul vitathatlanul beletartozik a sitebuild, a nevesebb FE oldali keretrendszerek es libek ismerete, az FE oldali bundlerek ismerete, egy SPA build es deploy folyamata. UI es UX erzek bonusz, de meg merem kockaztatni, hogy alapveto dolgokat illik ismerni ezeken a teruleteken is.
Es ezektol fuggetlenul nem art tudni, hogy nagyjabol mi folyhat a backenden is. Nem azt mondom, hogy mindenkepp fullstackbe kell tolni, de mostanaban mivel FE heavy appokat irunk, nagyjabol itt osszpontosulnak a dolgok, igy egy kicsit mindenre ra kell latni.
-
martonx
veterán
válasz
K1nG HuNp
#7283
üzenetére
Ez nagyon változó. Van ahol külön választják a front-endest a sitebuildertől. De van ahol meg a full-stack webfejlesztőkre esküsznek.
Szerintem (aztán aki akar, majd megcáfol), azért valahol az a jó, ha a frontendes nem vérzik el a css-ezésen. Azt kell látni, hogy az utóbbi években rengeteget változott a frontendes. Régebben a frontendezés valóban minimális javascriptezésből, és inkább css-ezésből állt.
Manapság viszont a js heavy, single-page appok idejében a komoly programozási tudás, komplex rendszerek átlátása (lásd alap angular projekt mikor, hol, mibe, miért éppen abba kell belenyúlnia) alapkövetelmény egy frontendesnél.
Ráadásul a CSS is egyre többet tud, scss, less miatt az is komolyodik, szóval egyre inkább kezd a sitebuilderség (amihez némi dizájner véna se árt, de a UX-es szakmát végképp ne keverjük ide ) is egy külön szakiránnyá válni.Szerintem.
-
martonx
veterán
válasz
K1nG HuNp
#7274
üzenetére
No igen, itt jön be, amit írtam, hogy a react meg túl fapados, és még egy normális bindolás, foreach sincs benne.
és ezek hiánya miatt mindent kényszeresen komponensekbe "kell" szervezni, hogy "elrejtsd" a fapadosságát, és mégis valamennyire olvasható maradjon a kód.Ezzel szemben vuejs-el / angular-al (már ha angular esetében megtetted előtte a fentebb részletezett jó hosszú előkészületeket) kb. ennyivel meg is lehet oldani:
<ul id="example-1">
<li v-for="item in ListItems">
<a :href=item.to>
<img :title=item.title :alt=item.alt :src=item.src />
{{ item.text }}
</a>
</li>
</ul>Aztán persze vue / angular vonalon is lehet komponenseket készíteni, de a fejlett html-es binding lehetőségek miatt korántsem kell annyira kényszeresen csinálni, mint a reactnál.
"egy jó fapados minden elemet kézzel beírt html kódot meg nem mernék felrakni a githubomra mert kiröhögnek" - ezt csak hiszed. Az "attól tűnik profibbnak, hogy jól túlkomplikáljuk" hozzáállás is nevetséges tud lenni
-
martonx
veterán
válasz
K1nG HuNp
#7249
üzenetére
+1 annyit téve hozzá, hogy vuejs esetében nem kell a jsx-et se megtanulnod, ellenben a saját nagyon jól dokumentált, faék bindolásait érdemes megtanulni, viszont ennek alcsonyabb a belépési küszöbe, mint a jsx-é (bár erre rá lehet fogni, hogy ez szubjektív szempont), cserébe alád tesz egy csomó mindent reacthoz képest pl. foreach, model bind inputokhoz stb...
-
martonx
veterán
válasz
K1nG HuNp
#7243
üzenetére
nem véletlenül ajánlom mindig a vue-t, én is dolgozok react-tal is (régen pedig volt szerencsétlenségem angularral is szopni), és már várom, hogy mikor fog ugyanúgy lecsengeni a react hype, mint anno az angular hype. Bár tagadhatalan, hogy az angularhoz képest a react is egy megváltás. -
K1nG HuNp
őstag
válasz
K1nG HuNp
#7239
üzenetére
első mondatban cookie helyett tokent akartam írni.
mindegy, közben esti kikapcsnak megcsináltam Vue-ban is egy jwt autentikációt. meglepően sima volt, reacthoz képest legalábbis... vannak ilyen apróságok, hogy routes.beforeEach() amivel aki csinált már más frameworkben authot szerintem el tudja képzelni mennyivel egyszerűbb a téma
Még amikor kiderült, hogy cégnél Vue van a stackban eléggé el voltam kenve, mert nem akartam egy enniyre opinionated frameworkot begyakorlolni, meg a react mégiscsak jobban ment, de mostmár kezdem érteni miért szeretik ennyire az emberek. Kezdőknek nagyon sokat segít, hogy minden "gyárilag" benne van, de látva a személyes példám és azt hogy egyre nagyobb oldalak váltanak vue-ra (gitlab, 9gag), lehet annyira nem is vészes dolog az, ha egy framework nincs teljesen lecsupaszítva a minimumra.
-
Jim-Y
veterán
válasz
K1nG HuNp
#7215
üzenetére
En JWT-s authentikaciot meg nem csinaltam, igy a blacklisteleshez nem tudok hozzaszolni (bar engem is erdekelne), de cookie alapu autentikacional
* kell egy session middleware (express, koa, xyz .. mindnek van ilyen middleware-e). A session-t tarolhatod adatbazisban, memoriaban, vagy memcache-ben is (pl redis)
* sikeres loginnal ctx.session-re beallitod a user-t, meg azokat az informaciokat amiket fontosnak tartasz session-ben tartani
* frontendre lekuldhetsz publikus user infokat
* logoutnal session-t nullazod a backendenAPI meg ugy mukodik, hogy a nem publikus endpointokra teszel session checket.
-
-
Jim-Y
veterán
válasz
K1nG HuNp
#7210
üzenetére
Van 2 lehetoseged.
A szokasos: a frontenden kitorolsz egy element, elinditasz egy HTTP DELETE requestet a backendre, ha megjott a valasz frissited a view-t
Optimistic: FE-n kitorlod a listabol az elemet, befrissited a view-t, de cacheled a kitorolt elemet, kozben elinditod a DEL requestet es attol fuggoen, hogy a BE-n sikerult-e vagy sem utolag frissited a view-t. Ha a backenden minden sikerult es kitorolted az elemet akkor FE-n mar nem kell csinalni semmit max clearelni a cache-t. Ha viszont a backenden nem sikerult kitorolni, akkor vissza kell allitani a cahce-bol a state-et.
-
bandi0000
nagyúr
válasz
K1nG HuNp
#7174
üzenetére
igen közben tegnap pont egy olyan videón szaladtam végig
A bootstrapnél ugye elvileg oszlop szélességet adok meg, viszont az is felbontás függvényében változik nem pedid kijelző méretben
pont ezen agyaltam, hogy szép ez a felbontás függő dolog, de most már a telefonnak nagyobb a felbontása mint a monitornak szal azon az életben nem lesz mobilnézet ha csak azt veszem figyelembe
Koszi a tippet!
![;]](http://cdn.rios.hu/dl/s/v1.gif)
(se cookie savelgetes fn, se token kudozgetes, minden bongeszon kivul tortenik)
Új hozzászólás Aktív témák
Hirdetés
- 129 - Lenovo Legion Pro 7 (16ARX8H) - AMD Ryzen 9 7945HX, RTX 4080
- Bomba ár! Lenovo ThinkPad T15 G1 - i5-10GEN I 16GB I 256GB SSD I 15,6" FHD Touch I Cam I W11 I Gari!
- ÁRGARANCIA!Épített KomPhone i5 12400F 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
- Bomba ár! Dell Latitude 5400 - i5-8GEN I 16GB I 512SSD I 14" HD I HDMI I Cam I W11 I Gari!
- Bomba ár! Dell Latitude 3590 - i5-8GEN I 8GB I 256SSD I HDMI I 15,6" FHD I Cam I W11 I Garancia!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged