jQuery refactorisation / maintien

Question

Je l'ai cherché un peu autour de SO et n'ont pas trouvé des questions / réponses qui me aident. Le problème est mes appels de fonction jQuery obtiennent beaucoup trop grand pour maintenir. Je me demande si je devrais refactoring beaucoup plus ou s'il y a une meilleure façon de faire tous ces appels. Vous verrez que je fais un appel, les fonctions anonymes qui sont des arguments pour la fonction finissent par être très grande et rendre la lisibilité du terrible code. Je pourrais en théorie briser tous ces vers le haut dans leurs propres fonctions mais je ne sais pas si c'est une bonne pratique ou non. Voici un exemple de certains des jQuery jusqu'à présent:

$('#dialog').html('A TON OF HTML TO BUILD A FORM').dialog('option', 'buttons', { 'Save': function(){$.post('/use/add/', $('#use_form').serialize(), function(data){ ......There were 4 more lines of this but I'm saving you so you don't rip your eyeballs out hopefully you get the idea.....dialog('option','title','New Use').dialog('open');

Comme vous pouvez le voir depuis tant des fonctions que j'appelle les fonctions de prendre comme arguments, quand je crée des fonctions anonymes je finis avec un énorme gâchis (il y avait environ trois déclarations de fonctions plus anonymes dans ce code)

Dois-je faire simplement un tas de fonctions et d'appeler ceux pour le rendre plus lisible. La seule raison pour laquelle je serais contre c'est parce que j'aurais un tas de fonctions déclarées qui ne sont utilisées qu'une seule fois.

Merci d'avance pour l'aide!

Answer 1

Définir les fonctions dans le champ d'application correcte et ce n'est pas une grosse affaire.

var generateHTML = function() {
  ...
};
var somethingElse = function() {
  ...
};

... some more ...

$('#dialog').html( generateHTML() )...etc

Il n'y a pas beaucoup d'autres choses que vous pouvez faire, sauf réorganiser votre code en général (par exemple, en utilisant un objet style orienté ) pour encapsuler le code il est donc pas en désordre.

Answer 2

  

La seule raison pour laquelle je serais contre c'est   parce que j'aurais un tas de fonctions   a déclaré que ne sont utilisés qu'une seule fois.

Utilisation de fonctions anonymes que vous faites actuellement est vraiment pas différent de déclarer correctement scope des fonctions nommées, sauf qu'ils sont en ligne et de le rendre un peu plus difficile à déboguer dans de nombreux débogueurs JavaScript comme le nom de la fonction est pas affiché.

S'il y a des modèles à vos fonctions anonymes à travers les pages, je tenterais de factoriser les fonctions nommées que fournissent une base commune à la fonctionnalité nécessaire.

Je serais enclin à ne pas avoir de grandes chaînes de HTML dans les appels de méthode jQuery ou incorporé dans les balises <script> JavaScript et les garder dans un endroit séparé qui peut être facilement interrogé pour récupérer le contenu pertinent - cela pourrait être des fichiers texte, etc. .

Answer 3

Une façon évidente de maintenir maintenabilité est d'utiliser une sorte de mise en forme.

Je comprends votre aversion pour nommer les fonctions utilisées seules, mais il est facile de contenir les noms. Le langage javascript pour imiter un champ d'action est d'envelopper le code en question dans une fonction anonyme qui est appelée immédiatement:

(function () {
  var f = function (x) ...
  var g = function (y, z) ...
  // operations involving f and g
}()); // called immediately

Je préfère une autre forme qui rend le fait que le code est exécuté immédiatement plus visible

new function () { // called immediately
  var f = function (x) ...
  var g = function (y, z) ...
  // operations involving f and g
};

il y a une autre façon de créer des noms avec ceci:

new function (i, j, k) {
  // functions f and g
  f(i, g(j, k));
}(3, 4, 5);

Answer 4

Mise en forme, le formatage, la mise en forme! Avec une utilisation correcte des espaces votre code CAN Rechercher lisible:

$('#dialog').
    html('A TON OF HTML TO BUILD A FORM').
    dialog('option',
        'buttons', {
            'Save': function(){
                var callback = function(data){
                    // There were 4 more lines of this
                    // but I'm saving you so you don't
                    // rip your eyeballs out hopefully
                    // you get the idea
                }
                $.post(
                    '/use/add/',
                    $('#use_form').serialize(),
                    callback
                )
             }
         }).
    dialog('option',
        'title',
        'New Use').
    dialog('open');

Ceci est juste comment je forme personnellement. Il existe d'autres moyens, mais je suggère fortement en laissant l'ouverture accolades / crochets et coutinuing virgules / points / + à la fin de la ligne, car javascript a tendance à ajouter automatiquement un « ; » à la fin d'une ligne si elle pense que la ligne est une déclaration bien formée complète.

La chose importante est de ne pas quelle règle mise en forme spécifique que vous adoptez. L'important est d'être cohérent à ce sujet. D'une certaine façon Python avait raison: il est parfois bon de forcer les gens à leur code en retrait (mais je déteste être forcé par Python)

.

Answer 5

Je vais essayer de décomposer le code en plug-ins autant que possible et la conception en fait le code autour de ce principe. Je ne sais pas à quel point cette idée correspond à vos besoins.

Answer 6

Il est facile d'entrer dans le problème de l'enchaînement sans fin de jQuery. Enchaînement de fonction est bonne si elle est utilisée modérément, ou il prend une éternité à lire et à comprendre le code qui a été écrit comme il y a 5 minutes. En ce sens, le formatage de votre code comme slebetman suggéré serait utile. De plus la portée de vos fonctions comme le suggère que quelqu'un ou thenduks sera également d'une grande aide.

Si vous deviez marcher un mile supplémentaire dans vos efforts de refactoring, je vous suggère de considérer une sorte de modèles architecturaux tels que MVC ou MVP pour organiser votre code. Une liste Apart bénéficie d'une belle article sur la mise en œuvre MVC avec Javascript . S'il y a une séparation de vue et les modèles, il donne facilement moyen d'utiliser des événements personnalisés et beaucoup d'autres ajouts qui sont facilement réutilisables. Elle oblige aussi à penser en termes du modèle de domaine plutôt que des objets DOM (tables, lignes, divs) ou d'événements (cliquez, keyup), etc. Penser en termes du modèle de domaine et les événements associés tels que onPostRollback, onPostCreate ou onCommentAdded qui pourraient être applicable sur le SO, par exemple. jQuery a récemment ajouté le support pour la liaison des événements personnalisés et ceux-ci sont quelques bons articles ( première , deuxième ) expliquant comment tos.

En général, il est difficile de réutiliser des vues, mais les modèles changent très peu à travers des projets et est un domaine où nous pouvons atteindre un maximum réutilisabilité.