You Might Not Need jQuery
Nem minden esetben szükségszerű a jQuery-t használni
■ 
Friss blogmarkok
- Web Akadálymentesítési Útmutató (WCAG) 2.1 – nyilvános munkaterv – Megjelent a WCAG (Web Akadálymentesítési Útmutató) 2.1 nyilvános munkaterv (0)
- MongoDB Apocalypse Is Here as Ransom Attacks Hit 10,000 Servers – Több tízezer védtelen MongoDB szerverre csaptak le hackerek (2)
- 12 Signs You’re Working in a Feature Factory – A cél nélküli funkciógyártás néhány tünete (0)
- Translatable, custom dates in Twig templates of Drupal 8 – Saját dátumok megjelenítése, fordíthatóan a Drupal 8 smink rétegével dolgozva (0)
- NativeScript – Cross-Platform Native Development with Javascript – Fejlesszünk natív mobilalkalmazást JavaScripttel (0)
- GitHub Security Update: Reused password attack – Érdemes bekapcsolni a kétfaktoros azonosítást, ha a GitHub jelszavunkat más oldalakon is újra felhasználtuk (17)
- UX Design könyv – Hogyan tervezz felhasználóbarát és szerethető alkalmazásokat? (0)
- Introducing unlimited private repositories – Megváltozik a GitHub díjszabása: minden előfizetéshez korlátlan számú privát repository jár (0)
- Drupal 8 Twig: add custom CSS classes to menus (based on menu name) – Saját elképzeléseink szerinti CSS osztályok (automatizált) hozzáadása a Drupal 8 menüihez (0)
Cikkajánló
Bártházi András:
Perl alapjai VII.- Fájlműveletek
presidento:
Web Worker – Számolni? Böngészőben?!
Bártházi András:
Google alapjai I.
Friss csiripek
Csiripek betöltése…
Aktív fórum témák
Új fórum témák
Archívum
| H | K | Sze | Cs | P | Szo | V |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 1 | 2 | 3 | 4 | 5 |
Amíg a böngészők nem követnek
Ahhoz, hogy sok böngészőben támogatott és DRY kódot írjon az ember szükség van egy közös API-ra. Ez lehet jquery, vagy bármelyik másik keretrendszer interface-e, de lehet használni a jelenlegi szabványt is, és polyfillezni.
Csak hogy egy jelenlegi problémát hozzak fel, ezer féleképp lehet kliens oldalon adatot tárolni, és általában, ha ilyet akarunk, akkor tényleg csak annyi kell, hogy legyen egy interface, amin keresztül le tudjuk tárolni és vissza tudjuk kérni az adatot. Az már egyáltalán nem érdekel minket, hogy mindezt hogyan csinálja a böngésző (Cookie, WebSQL, LocalStorage, IndexedDB, etc...)
Olyan speciális esetek előfordulhatnak, hogy csak egy adott böngésző egy adott típusára fejlesztünk mondjuk egy cég belső hálójára. Esetleg gyorsan összeszórunk valamit, hogy teszteljünk egy rest service-t, stb... Ilyen esetekben valóban nem kell jquery, egyébként igen.
Btw kerestem egy fél órát, de
(Ha lesz egy kis időm lehet, hogy írok egyet.)
Tárolás
Milyen adatokat tárolnál ilyen módon a kliensen?
Keretrendszer?
Keretrendszer azért, mert nem akarok alacsony szintű dolgokkal foglalkozni, és azt szeretném, hogy ie6+ működjön a dolog, ie, chrome, ff, safari, opera, stb...-ben.
Ez nyilván projekt függő. Lehet alap beállításokat menteni, pl hány sor legyen egy oldalon, milyen színvilágú skin-t szeret az illető, mi volt legutóbb a kosarában, milyen cikket kezdett el írni, stb...
Az én megvalósításom 50 soros
Nekem eszembe nem jutna bármi érdemlegeset a kliensen tárolni, hisz nem megbízható, amiket írsz, inkább a szerverre tenném külön bejegyzésbe, a kliensre jellemző dolgok (pl. felbontás) kulcsa pedig a felhasználó user agentje lenne. Így megmaradna minden kliensben, hogy mit szeret (például a lila hátteret), de az is, hogy mobilon három sort szeret egy képernyőn látni, PC-n meg tízet.
Kliensen én max. olyan adatot tárolok, amiért nem kár, ha elveszik, például a vágólap tartalma, de ilyen típusú adatból meg elég kevés van.
Arról nem is beszélve, hogy a localStorage-et a Mozilláék nem ajánlják komolyabb használatra, mert minden oldalbetöltődéskor plusz lemezhozzáférést igényel. Érdemes arra rákeresni, hogy "localstorage performance".
Minél több munkamenethez
Meg lehetett volna úgy is csinálni, hogy ne igényeljen, szóval ez egy szimpla bug. Én személy szerint nem izgatom magam miatta...
Minél több munkamenethez
Miért?Mert minden egyes
Mert minden egyes oldal lekérés érinteni fogja a szervert munkamenet írás vagy olvasás formájában.
Ez gondolom költői kérdés volt. Elég sokszor esel ebbe a hibába. De nyugi, nem vagy egyedül, String-nek pl minden második mondata ilyen, amikor vitatkozik...
Mert minden egyes oldal
Innentől kezdve a kliensre kihelyezni adatokat pont az előreoptimalizálás kategóriája. Vagy tedd hozzá, hogy valamilyen REST-szerű szolgáltatáson dolgozol mostanában, (félig) vastag klienssel, és akkor megértem, miért gondolkozol így.
Az, hogy akár száz változót szerveroldali munkamenetben tárolunk, nem csökkenti a szerver teljesítményét észrevehető mértékben, de ha kliensoldalon, akkor meg azt kockáztatjuk, hogy adatokat vesztünk. Tehát akkor miért is jó ez utóbbi megoldás?
Én annyit mondtam/írtam, hogy
egyáltalán nem mindegy milyen
Az én megvalósításom 50 soros
Akkor ez remek alkalom arra hogy open sourceold és felrakd Githubra, és mindenki örülni fog hogy milyen kis mérettel meg lehet ezt oldani
Ettől még kis mennyiségű adatot ha nem sokszor olvassuk írjuk simán lehet használni például hogy ne vesszen el az eddigi szerkesztés egy oldalon
jstorage ilyen, userdata-t és
keretrenszerek arra
Az nevet, aki a végén nevet
Természetesen lehet mindenre ilyen-olyan keretrendszereket használni, de nézzük a hátrányaikat:
- általában jóval nagyobbak és többet tudnak, mint amire az embernek szüksége van
- soknak függőségei vannak
- ha valami nem úgy működik, ahogy szeretnéd, elsőre nem feltétlenül fogod átlátni
- a kód átnézése nélkül nem fogod tudni, hogyan oldották meg a problémát, azaz enélkül nem tanulhatsz belőle
- ha mindenre keretrendszert használsz, a kontroll csak részben lesz a te kezedben, ráadásul nagy valószínűséggel el fog szállni a processzor- és a memóriahasználat
Lista
Persze, de általában csak 1-1
Eleve úgy vettem észre, hogy nem túl nepszerű opensource js projekteknél a laza csatolás, úgyhogy még arra sem igazán jók, hogy kiindulási alapként használjam őket.
Van több probléma, amit meg kell oldani az ilyen jellegű keretrendszerrel. Nem mélyedtem túlságosan bele, de az egyik biztosan a véges tárhely lesz. Eltérő mennyiségű adatot lehet tárolni pl cookie-ban és localStorage-ben. Lehet, hogy ezzel kapcsolatban kellhet tömörítés, adat feldarabolása több cookie-ra, stb... A másik az aszinkron működés lesz, amit interval-al szoktak megoldani cookie-nál. A harmadik az intertab communication lesz (pl: localstorage-nál). Esetleg még kellhet valamilyen szintű titkosítás is stb, stb... A negyedik, hogy közös nevezőre kell hozni az sql-t, és a key-value storage-t. Erre mindre már nem egyszerű átfogó megoldást írni...
Keresgéltem js local orm témakörökben, de eddig semmi.
Közben találtam
yathit/ydn-db
Ez userdata, websql, localstorage, indexeddb, amiket használ. Cookie-t nem, de úgy néz ki az nem is szükséges széles körű böngésző támogatás kialakításához.
Van egy másik is, ami korábbi technológiákkal dolgozik, ebben van cookie fallback is.
jeremydurham/persist-js
Van még egy, ami szintén nem teljesen ugyanazokat a technológiákat használja.
amplifyjs.com/api/store/
Ha én csinálnám, akkor
Itt van rá cookie-s megoldás:
developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage
Egységesség
Nos úgy tűnik a jQuery csapata is ezen az állásponton van. Bár 2.x szériában már nincs ie6-9 support, cserébe van régi webkit (mint android 2.3.x ami sokszor szintén nem egy leányálom).
Az ie9-et támogatja a jquery
Tök érdekes, hogy a böngésző statisztikák teljesen ellentmondóak:
http://www.w3schools.com/browsers/browsers_explorer.asp
http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0
http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
Nagyon nem reprezentatív, hogy egy-egy oldalt milyen böngészővel néznek gyakran... Átlag azért az ie8- sajnos még mindig 5% körül mozog...
Sok a tanulatlan látogató...
Sizzle