2010-10-22 7 views
4

Mon style actuel de la programmation est javascript OO en utilisant la fonction Class.extend par John Resig: http://ejohn.org/blog/simple-javascript-inheritance/orienté objet Javascript vs stockage pur jQuery et .data

Cela a été très bien, mais je me retrouve à écrire de nombreux setters et getters qui ne s'utilise que sur init. En outre, il semble conduire à des fuites de mémoire dans IE lors du stockage des instances de ces objets dans un tableau pour une utilisation ultérieure. Je commence à favoriser un code plus petit, plus propre et plus lisible par rapport à l'approche OO apparemment exagérée. Mon idée est maintenant de simplement tout baser sur dom en utilisant jquery et en stockant les propriétés de données en utilisant la méthode .data. Par exemple, au lieu de créer une instance d'un nouvel objet Tweet, vous devez simplement ajouter un div au dom avec tweet de classe et simplement ajouter les propriétés comme auteur, horodatage, réponse à, envoyé depuis, etc. dans le cache .data pour cet élément dom.

Que pensez-vous de cette approche moins structurée lors de la création d'instances de choses telles que des éléments dans un flux comme Twitter? Est-ce que l'héritage OO et prototypal est la meilleure approche ou est-ce que la manipulation dom est la meilleure?

+1

Suivez YAGNI .... –

Répondre

1

Je fais quelque chose de similaire. J'ai pris l'approche OO javascript. Mais au lieu d'utiliser des tableaux, j'utilise un objet valeur clé. La clé est un identifiant d'élément dom unique, la valeur est l'objet lui-même. ça ressemble à quelque chose comme ça.

par exemple:

var collection = {}; 
var $domEl = jQuery;    // jquery dom element 
var myClass= new MyClass($domEl); // class instance 

// add to collection 
collection[$domEl.attr('id')] = myClass; 

// remove 
delete collection[$domEl.attr('id')]; 

vraiment cela dépend de la complexité de vos objets. Une approche strictement .data devrait s'appuyer sur des plugins pour toutes les méthodes associées, puis stocker des données dans les données des éléments. J'ai de nombreuses méthodes qui ne sont pas liées à l'interaction strictement élément, donc je garde les méthodes et les données dans la classe.

1

Mon cerveau me dit que le Javascript très structuré qui ne repose pas sur la manipulation du DOM et qui l'appelle et le sort avec jQuery serait idéal.

Cependant, je viens d'écrire une application web HTML5 qui fonctionne hors ligne en utilisant le SQLlite intégré et l'a fait en utilisant principalement .data et en stockant des informations dans les divs et les sortir de là. C'était simple, propre et facile mais, pour une raison quelconque, je ne me sentais pas bien.

Mais cela a bien fonctionné.

+0

>> "mais pour une raison quelconque, je ne me sentais pas bien." Mais si c'est propre, simple, rapide et efficace, pourquoi ne vous sentiriez-vous pas bien? Parce que ce n'est pas la meilleure pratique? – Abadaba

+0

ouais c'est comme si je mixais trop mon écran/front end avec mon code et ma logique. Stocker des données directement dans le DOM semble juste bizarre. Versus le garder dans les objets JS. –