[ JavaScript ] A deleteRow() törli-e a sorhoz rendelt eseménykezelőt?

Internet: PHP, CGI, stb.

Sziasztok!

JavaScriptben járatos fejlesztőktől kérdezem.

Ha egy táblázat egy sorához az addEventListener() függvénnyel hozzárendeltem egy eseményt (pl: mouseover), majd a táblázat ezen sorát törlöm a deleteRow() függvénnyel, akkor automatikusan törlése kerül-e a sor eseménykezelője is, vagy mindenképpen törölnöm kell előtte a sorhoz rendelt eseménykezelőt?

  • 2341 megtekintés

( Wabbitseason v | 2015. 10. 28., sze – 16:29 )

Törölnie kellene neki, de nem javaslom, hogy így csináld.

Érdemes kihasználni, hogy az események "buborékolnak", azaz ha egyetlen listenert teszel a <table> elemre, az pont elég, ugyanis az event object tartalmazza a target propertyt (https://developer.mozilla.org/en-US/docs/Web/API/Event/target), amiből kiderül, hogy melyik elemen (esetedben <td>, amiből egy event.target.parentNode-dal megkapod a <tr>-t) keletkezett az esemény.

Köszönöm a tanácsot és a linket.
Kipróbáltam, működik ez a megoldás is, igaz egy kicsit több feltételt kell vizsgálni, mivel a táblázat címsorára nem akarom alkalmazni az eseményt (event.target.parentNode.rowIndex > 0).

Továbbá, ami nehezíti még a dolgot, hogy igazából csak az első cellához akarom hozzárendelni az eseményt.
Ebben a tekintetben tévesen fogalmaztam meg a témaindító kérdésemet, mert az eseményt a következőképpen hozom létre (nem pont ezzel a kódsorral, de ez lényegtelen): 


document.getElementById("tableId").rows[i].cells[0].addEventListener("mouseover", function() {...});
document.getElementById("tableId").rows[i].cells[0].addEventListener("mouseout", function() {...});

Most pedig ezzel helyettesítettem: 


document.getElementById("tableId").addEventListener("mouseover", function(event) {
  if ( event.target.parentNode.rowIndex > 0 && event.target.cellIndex == 0 ) {
    // érdemi kód
  }
});

document.getElementById("tableId").addEventListener("mouseout", function(event) {
  if ( event.target.parentNode.rowIndex > 0 && event.target.cellIndex == 0 ) {
    // érdemi kód
  }
});

( Aadaam v | 2015. 10. 29., cs – 01:13 )

Hogy fogalmazzak... törli, kivéve IE 6-7-8.

A 9-es már más engine-t használ.

Amúgy kollégának igaza van, ill. annyit tennék hozzá, ma már nem szokás nyers JS-t írni, ilyenekre tipikusan egy angular vagy egy react van behúzva. Előbbi Google, utóbbi Facebook framework.

(és van még bootstrap, polymer, bower, grunt... nagy a világ :)

És akkor hogy is fog kinézni mondjuk angularban a table-re rakott event handler ami majd az event.target alapján kiválasztja melyik sorra lett meghívva? :) 


$scope.data = [1, 2, 3];
$scope.onHover = function(n) {
	$scope.last = n;
}

<table ng-repeat="n in data" ng-mouseover="onHover(???)">
	<tr><td>{{n}}</td></tr>
</table>
Last: {{last}}

kiszervezheted funkcióba, de minek?

Ha át akarod adni a targetet akkor $event, de ne piszkáld a DOM-ot feleslegesen, ez egy ojjektum, ha függvényt akarsz rá hívni, hívd rá mint ojjektumra.

Működő kód: http://pastebin.com/XtvDF7x9

<table>
 <tr ng-repeat="x in names" ng-mouseover="x.hovered=true" ng-mouseout="x.hovered=false" ng-class="x.hovered? 'black' : 'blue'">
   <td>{{ x.Name }}</td> <td>{{ x.Country }}</td>
   <td ng-click="delete(x)">&times;</td>
 </tr>
</table>

Mondjuk ezt speciel egy egyszerű CSS is megoldja, de most maradjunk ennél.

EDIT: jó, rájöttem, angular-ral nem kompatibilis a table-be rakás annyira, de azt mondják az okosok, nem is kell:

https://github.com/angular/angular.js/issues/1568

Ebből a szempontból a react a brutális, az ne féltsd, átrakja neked automatikusan.

Az IE 6-8 le van tojva.
Nem vagyok JS-|Web- fejlesztő, ez egy Google Maps-os hobbi projekthez kell.
JavaScriptet úgy ahogy minimálisan ismerem, Google Maps API-t, jQuery-t, jQuery UI-t tanulgatom.
Biztos nagyon rugalmasan meg lehetne oldani a felvetett problémámat jQuery-vel vagy AngularJS-el; ahogy te is írtad rengeteg JS keretrendszer van, nem ismerhetem mindegyiket, de igyekszem.

Az AngularJS-ről már hallottam :), de még nem használtam, most nézegettem, amint látom egy kicsit másfajta gondolkodásmódot igényel, mint a hagyományos JS-ben való fejlesztés. Ha lesz időm szánok rá egy-két napot, hogy ismerkedjek vele.

nézd, szerintem egy évtizede nem jött ki olyan játék, amit vanilla C++-ban írtak volna, semmi lib, semmi keretrendszer, csak úgy, gyorsan.

én is szoktam néha vanilla JS kódot írni, meg tudok régebbi keretrendszerkehez, pl. ext.js-hez, backbone-hoz is igazodni pl., de új projektnél felesleges, mindig azt kell nézni, mivel haladsz a leggyorsabban, és minél újabb a rendszer, sanszos hogy annál gyorsabb vele fejleszteni.

jQuery UI is már idejétmúltnak tekinthető, sőt, most mára a Bootstrap + Angular a "yesterday's technology", de egyelőre lusta vagyok.

Bootstrap + angular aztán hadd szóljon.

Most a komponenstechnológiák kezdenek feljönni mint pl. a polymer.

Oh, szoval en a jQuery fanatizmusommal egy helyre fogok kerulni a betarcsazos modemmel? :-)

Megmondom oszinten, nekem nem jon az be, amikor mar ennyi reteg ragcsalja a HTML-t. Ezt az egesz templatinget jobb szeretem szerveroldalt elrendezni, a JS a mar meglevo elemekbe szuljon max par uj elemet, de ne kezdjen el nekem custom szintaxisu cuccokat lecserelgetni...
--
Blog | @hron84
Üzemeltető macik

Dedikált URL-jeid lehetnek SPA esetén is.

Az SPA előnye programozási szempontból, hogy desktop-szerűbb a fejlesztés, tisztább az architektúra: van egy alkalmazás, meg egy rakás service, amiket hivogat, end of story.

User szempontból egyfelől a sebessége lehet előnyös taszkváltások és mikrotaszkváltások között (hisz nem tölt be előlről az egész, csak lejön az adat a szerverről és kész)

Másfelől konzisztensebb a felhasználói élmény az által, hogy egyszerűbb megőrizni a komponensek állapotait, hisz nem vesznek el soha. Pl. ha van egy fa valahol egy menüben amit nyitogatsz, majd utána piszkálgatsz egy ettől független formot, elküldöd a formot, ha oldalváltás történik, a programozó jóeséllyel nem fogja megőrizni neked a fa állapotát.

Persze hátránya hogy a back-gomb leprogramozása néha nehézkes úgy, hogy "hasonlítson" a viselkedése a hagyományoshoz, és SPA-t egyetlen egy nyelven lehet fejleszteni, ez pedig a JavaScript, amihez korrektül kell érteni, ha nem akarsz belegabalyodni.

errgh... akkor úgy mondom, a böngésző lelkivilágához kell érteni.

Amúgy nem mindegy, hogy fordul JS-re, nem láttam még irodai alkalmazásokhoz frameworköt emscripten felett, pedig elvileg lehet (tán a LibreOffice próbálkozik lefordítani magát LLVM-mel), persze tudom, ami késik, nem múlik.

Sokat próbálgattuk a single page dolgokat, de aztán a böngészők memory leak problémái miatt az oldal újratöltése mellett döntöttünk. A leak-ekhez mi is nagyban hozzájárultunk, de amikor ki akartuk debugolni, akkor annak az előzetes költsége magas lett volna, pénzügyi döntés született: üzleti alkalmazások SEO/human friendly URL-ekkel: /invoice/customer/123/copyfrom/7316

Nekem jellegeben hasonlo problemam van ezzel a temakorrel, ha intenziven elkezdesz fejleszteni, akkor egy ido utan elojobujnak a memoriaproblemak az egyoldalas cuccokkal, es nehez megtalalni az okat, enormous mennyisegu ido - csekely benefittel.

En egy koztes megoldast alkalmazok: vannak olyan oldalak, amiknek az egyes belso folyamatai AJAX-szal mennek, de ha az oldal nagy szazaleka frissulne, az oldaltoltes. Igy a kecske is jollakik, a kaposzta is megmarad. Mondok peldat: ha van egy gepem, akkor az uj IP cim hozzarendelese, bizonyos dolgok engedelyezese/tiltasa az a gep tulajdonsaglapjan keresztul mukodik, de ha innet a gepek listajara akarsz valtani, az egy rendes pageload. That's all.
--
Blog | @hron84
Üzemeltető macik

Rég volt amikor ezt kellett debuggolnom sajna, nem volt még se Chrome Profiler, se ezek a mai modern frameworkok, a Nokia (HERE) saját belső rendszerét használtuk (JSLA), de mintha a JSLint beszólt volna neked potenciális leakekre.

Mondjuk nálunk erős volt a coding style guide, volt benne 3 millió sor, voltunk csak JS fejlesztők a projekten kb 20-an, képzelheted, nem kerültél ki csak úgy élesbe. A QA-k nagyszerű munkát végeztek.Én 10 mega alatt tudtam maradni folytonos használatnál, de ehhez mindenféle linkelt cache-ek kellettek mindenféle szinten...

Az is igaz, hogy ez a Nokia (akkor végeláthatatlannak tűnő) pénzéből ment, de tuti nem lehet ezt megoldani coding standard szinten?

Van gányolás, persze, ugyanakkor a vezető frameworköket okos gyerekek csinálják - Twitter, Facebook, Google vezető JS fejlesztői, én azért tudom, milyen oda bekerülni JS fejlesztőnek (finoman szólva szűrnek).

Az Angular hiába Google, a függőség-injekciós megoldása nettó gányolás, szerintem a Google másik részlegénél - Closure, V8 - fogják is a fejüket rendesen.

De ezek azért alakulnak ki a nagy cégeknél, mert igényük van rá: gyorsan kell haladni, nem lehet hogy egy pixel arrébbrakása kétmillió új kódsort eredményezzen, illetve ha valamit kicserélnek, akkor azt sok-sok komponensben kell egyszerre: gondold meg, a Google egy mozdulattal cserélt logót mindenen.

UX részről elsősorban az a nyomás, hogy sebességet akarunk, másodsorban mentálisan konzisztens viselkedést: ehhez az eredeti desktop architektúra sokkal alkalmasabb volt, de ha egy cégvezetőnek azt mondanám, figyu, írunk neked mondjuk QT-ben bármiféle B2B vagy B2C platformot, képenröhögne.

Egy számlanyilvántartó még csak-csak lehet desktop, de amint külső felhasználói is lehetnek valaminek, web.

Szóval épül rendesen a ChromeOS világa, ahol minden program egy-egy wrappelt böngésző: az asztalomon most is fut egy Slack, egy Spotify, egy ...ergh... Popcorn Time Butter, ezek mind wrappelt webböngészők, az igazi böngészőkben a levelezéshez nyitva van egy GMail, abban van egy GChat, az FB-n ott a Messenger, és akkor még az olyan office-jellegű appokról, mint a GDocs, GCalendar vagy a Prezi nem is volt szó.

Gyakorlatilag a precíziós grafikai szoftvereim maradtak desktop egyelőre, meg a játékaim, a többi web, bár az utóbbi időkben a Pixate-et egyre többet használtuk (most - furcsa fordulat - kivonult desktopra), nagyon sok ismerősöm használ UXPin-t, most jött ki a bootstrap.io, forráskódra sokan szeretik az Atom-ot...

Mindezekhez a klasszikus javascript rendszerek kevesek voltak, a jQuery még csak egy XML-manipulátor lib, ellenben a Bootstrap UI leíró-nyelv, az Angular pedig egy MVVM ojjektum binder, csakúgy, mint a React.

Ennyi, van igény, lesz rá lib...

Nem arról volt szó hogy nem a web felé megy az ipar nagy része, hanem a fragmentáltság itt is ugyanúgy probléma lett.

Érdekes lenne egy olyan tanulmány, amely megvizsgálná, hogy mi okozza valójában a piac fragmentálódását - ezt részekre és valós eset tanulmányokra bontva, vizsgálva a motiváltságok okait és mértékét. Kíváncsi lennék ezekre az irány vektorokra.

Változás sebessége és piac nyiltsága.

a jQuery megjelenésének idején is volt vagy 25000 ugyanazt csináló framework (dojo, prototype, yui, emlékszik még rájuk valaki?), kellett 4-5 év amire letisztult a piac.

Manapság senki nem beszél knockback-ről holott az volt az első olyasmi, ami most az angular. ExtJS-ről se, holott az volt olyasmi, mint mondjuk egy backbone + bootstrap kombó. Ja, apropó, backbone-ról se beszél senki...

Semmi nem akadályoz meg senkit, hogy csináljon egy új frameworköt, ha kell egy, akkor vagy van, ami már tudja ami neked kell, vagy be tudod pluginezni rá, vagy nem tudod, és akkor írsz egy sajátot.

Brutális az a technológia, amit nyugodt szívvel meg lehet csinálni most, összehasonlítva mondjuk az 5 évvel ezelőttihez képest.

Egyetértek, nagyot változik a technológia 5 év alatt. És ha kicsit szabadjára engedjük a képzeletünket, és mondjuk belegondolunk, lehet akár hogy kinőnek fontos szerepet játszó szolgáltatások, melyek majd adaptívan tanulnak és változnak a globális infrastruktúra igényei alapján és a sok kicsi fogja ezeket jobban használni (ahogy eddig is, pl. Google kereső vagy maps), tehát ebből lesz több, amit egy kis játékos erőforrás hiány miatt nem tud összerakni. Ez viszont megfordíthatja bizonyos területeken a fragmentációt. Talán.

Sok az irány és lehetőség és sokan sok felé kutatnak.

Ha mar egy profi angularos. Azt hogyan csinalod meg, hogy ket url kozott ne toltse be ujra az egesz oldalt?

En a menusort adatbazisbol veszem, es igy mindig van a weboldalnak egy "villanasa".

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....