Quelles sont les forces et les faiblesses réelles des nombreux frameworks basés sur backbone.js? [fermé]

J'espère que quelqu'un pourra partager son expérience avec certaines des dernières variantes émergentes de backbone.js. J'ai une bonne expérience avec backbone / underscore / require dans plusieurs projets et j'aimerai passer à l'étape suivante vers des solutions plus avancées pour une structure d'application complexe.

Je sais que les cadres suivants sont disponibles:

• Marionnette
• Geppetto (basé sur Marionette)
• Chaplin , Chaplin - chaplin-passe-partout
• Vertèbres
• LayoutManager
• Thorax
• Aura
• Luca
• Singool
• backstack
• Interface utilisateur de backbone

• ponton

• BTW - excellent point de départ pour un projet à grande échelle

Et probablement j'en ai raté quelques-uns.

Il y a une brève introduction sur les différences ici:

• lien de conversation speakerdeck

mais c'est très général. Je me demandais si quelqu'un pouvait partager son expérience avec des applications réelles utilisant ces frameworks.

Quel est l'avantage de choisir l'un par rapport à l'autre? Quand la marionnette sera-t-elle une meilleure solution que l'aumônier, ou pourquoi la vetebrae est-elle meilleure pour certaines applications, par exemple.

Bien sûr, la réponse évidente sera " utilisez ce qui est le mieux pour vos besoins ", mais je manque d'expérience avec ces cadres pour connaître leur force / leur objectif / leurs avantages ou leurs scénarios préférés.

Merci!

Edit 1: trouvé cet article: Backbone.Marionette vs Backbone-Boilerplate

Edit 2: Réponse de Mathias schafer (Chaplin) par mail:

Bref, la structure actuelle est proche de la version 1.0 puisqu'elle est déjà utilisée en production. Nous ne prévoyons pas d'ajouter de nouvelles fonctionnalités importantes ou de modifier les API avant la version 1.0.

Marionette est certainement la bibliothèque la plus complète et la plus stable qui soit. Il aborde plusieurs aspects du développement d'applications JS avec Backbone. Par exemple, il a une couche de vue forte que Backbone lui-même laisse complètement vide. Bien sûr, vous constaterez que certains aspects ne répondront pas à vos demandes et vous ressentirez peut-être le besoin de mettre en place une structure autour de Marionette.

En revanche, Chaplin se concentre sur un aspect plutôt petit mais très important des applications Backbone, à savoir la structure globale de l'application et le cycle de vie du module. À cet égard, Chaplin est très opioné et ressemble plus à un framework qu'à une bibliothèque (comme dans «votre code appelle une bibliothèque, un framework appelle votre code»). Chaplin fournit des classes centrales qui se trouvent au-dessus des modules d'application individuels et contrôlent l'état général de l'application. Cela donne à votre application une structure conventionnelle comme Ruby on Rails le fait par exemple.

Dans Chaplin, vous déclarez certaines routes qui mappent aux contrôleurs, et Chaplin démarre le contrôleur une fois que la route correspond. Il s'occupe également de l'élimination des anciens contrôleurs, ainsi que de l'affichage et du masquage des vues principales, qu'un contrôleur est censé créer. C'est l'idée de base, mais Chaplin s'occupe des détails laids pour que cela se passe bien.

Il y a deux principes qui accompagnent cette structure: - Modularisation, découplage et sandboxing - Communication inter-module à l'aide de Publish / Subscribe et Mediator (s)

Bien sûr, ces modèles ne sont pas nouveaux dans le monde du développement logiciel, et Chaplin n'est pas la seule bibliothèque à les appliquer aux applications Backbone.js.

Chaplin fournit également des améliorations pour la couche View, par exemple une CollectionView très sophistiquée, mais au total pas autant que Marionette avec ses régions et ses mises en page. Mais il est relativement facile d'écrire de telles méta-classes en utilisant les moyens fournis par Chaplin Views.

La plupart (tous?) Des frameworks que vous envisagez résolvent les mêmes problèmes, mais ils le font de manière légèrement différente avec des objectifs légèrement différents.

Je pense qu'il est juste de dire que tous ces projets résoudraient les problèmes dans ces catégories:

• Fournir un ensemble judicieux de valeurs par défaut
• Réduire le code passe-partout
• Fournir une structure d'application au-dessus des blocs de construction BackboneJS
• Extraire les modèles que les auteurs utilisent dans leurs applications

Marionette, que je construis depuis décembre 2011, a également en tête quelques objectifs et idéaux bien distincts:

• Architecture d'application composite
• Influence du modèle de messagerie d'entreprise
• Options de modularisation
• Utilisation incrémentale (pas d'exigence de tout ou rien)
• Pas de verrouillage du serveur
• Facilitez la modification de ces valeurs par défaut
• Code comme configuration / sur configuration

Je ne dis pas qu'aucun des autres cadres n'a les mêmes objectifs. Mais je pense que le caractère unique de Marionette vient de la combinaison de ces objectifs.

Architecture d'application composite

J'ai passé plus de 5 ans à travailler dans des systèmes logiciels distribués de clients lourds utilisant WinForms et C #. J'ai créé des applications pour les ordinateurs de bureau, les ordinateurs portables (client intelligent), les appareils mobiles et les applications Web, partageant tous un ensemble fonctionnel de base et travaillant plusieurs fois avec le même serveur principal. À cette époque, j'ai appris la valeur de la modularisation et j'ai très rapidement emprunté la voie de la conception d'applications composites.

L'idée de base est de «composer» l'expérience d'exécution de votre application et de la traiter à partir de nombreuses pièces individuelles plus petites qui ne se connaissent pas nécessairement. Ils s'enregistrent auprès du système d'application composite global, puis ils communiquent par divers moyens de messages et d'appels découplés.

J'ai écrit un peu à ce sujet sur mon blog, présentant Marionette en tant qu'architecture d'application composite pour Backbone:

• http://lostechies.com/derickbailey/2011/11/17/introduction-to-composite-javascript-apps/
• http://lostechies.com/derickbailey/2011/12/12/composite-js-apps-regions-and-region-managers/

Files d'attente / modèles de messages

Les mêmes systèmes distribués à grande échelle ont également tiré parti de la mise en file d'attente des messages, des modèles d'intégration d'entreprise (modèles de messagerie) et des bus de services pour gérer les messages. Ceci, plus que toute autre chose, a eu une influence considérable sur mon approche du développement logiciel découplé. J'ai commencé à voir des applications WinForms en mémoire à un seul processus de ce point de vue, et bientôt mon côté serveur et le développement d'applications Web en ont pris une influence.

Cela s'est directement traduit par la façon dont je regarde la conception des applications Backbone. Je propose un agrégateur d'événements dans Marionette, à la fois pour l'objet Application de haut niveau et pour chaque module que vous créez dans l'application.

Je pense aux messages que je peux envoyer entre mes modules: messages de commande, messages d'événement, etc. Je pense également à la communication côté serveur comme des messages avec ces mêmes modèles. Certains des modèles ont déjà fait leur chemin dans Marionette, mais certains ne l'ont pas encore fait.

• http://lostechies.com/derickbailey/2011/07/19/references-routing-and-the-event-aggregator-coordinating-views-in-backbone-js/
• http://lostechies.com/derickbailey/2012/04/03/revisiting-the-backbone-event-aggregator-lessons-learned/
• http://lostechies.com/derickbailey/2009/12/23/understanding-the-application-controller-through-object-messaging-patterns/ (code WinForms, mais toujours applicable)

La modularisation

La modularisation du code est extrêmement importante. La création de petits paquets bien encapsulés qui ont un objectif unique avec des points d'entrée et de sortie bien définis est un must pour tout système de toute taille et complexité importantes.

Marionette fournit la modularisation directement à travers ses moduledéfinitions. Mais je reconnais aussi que certaines personnes aiment RequireJS et veulent l'utiliser. Je propose donc à la fois une version standard et une version compatible RequireJS.

MyApp = new Backbone.Marionette.Application();

MyApp.module("MyModule", function(MyModule, MyApp, Backbone, Marionette, $, _){

  // your module code goes here

});

(Aucun article de blog disponible pour le moment)

Utilisation incrémentale

C'est l'une des philosophies de base que j'introduis dans chaque partie de Marionette que je peux: pas d'exigence "tout ou rien" pour l'utilisation de Marionette.

Backbone lui-même adopte une approche très incrémentale et modulaire avec tous ses objets de base. Vous êtes libre de choisir ceux que vous souhaitez utiliser, quand. Je crois fermement en ce principe et je m'efforce de m'assurer que Marionette fonctionne de la même manière.

À cette fin, la majorité des pièces que j'ai intégrées à Marionette sont conçues pour être autonomes, pour travailler avec les pièces maîtresses de Backbone et pour mieux travailler ensemble.

Par exemple, presque toutes les applications Backbone doivent afficher dynamiquement une vue Backbone à un endroit particulier de l'écran. Les applications doivent également gérer la fermeture des anciennes vues et le nettoyage de la mémoire lorsqu'une nouvelle est mise en place. C'est là qu'intervient Marionette Regionpour jouer. Une région gère le code standard de la prise de vue, de l'appel de rendu et du remplissage du résultat dans le DOM pour vous. Puis fermera cette vue et la nettoiera pour vous, à condition que votre vue comporte une méthode de "fermeture".

MyApp.addRegions({
  someRegion: "#some-div"
});

MyApp.someRegion.show(new MyView());

Mais vous n'êtes pas obligé d'utiliser les vues de Marionette pour utiliser une région. La seule exigence est que vous étendez à partir de Backbone.View à un moment donné dans la chaîne de prototypes de l'objet. Si vous choisissez de fournir une closeméthode, une onShowméthode ou d'autres, Marionette's Region l'appellera pour vous au bon moment.

• http://lostechies.com/derickbailey/2011/12/12/composite-js-apps-regions-and-region-managers/
• http://lostechies.com/derickbailey/2011/09/15/zombies-run-managing-page-transitions-in-backbone-apps/

Pas de verrouillage du serveur

Je construis des applications Backbone / Marionette sur une grande variété de technologies de serveur:

• ASP.NET MVC
• Rubis sur rails
• Rubis / Sinatra
• NodeJS / ExpressJS
• PHP / Slim
• Java
• Erlang
• ... et plus

JavaScript est JavaScript, lorsqu'il s'agit de s'exécuter dans un navigateur. Le JavaScript côté serveur est également génial, mais il n'a aucun effet ni aucune influence sur la façon dont j'écris le JavaScript basé sur mon navigateur.

En raison de la diversité des projets que j'ai construits et des technologies dorsales que mes clients utilisent, je ne peux pas et ne veux pas verrouiller Marionette dans une seule pile technologique côté serveur pour quelque raison que ce soit. Je ne fournirai pas de projet standard. Je ne fournirai pas de gemme rubis ou de package npm. Je veux que les gens comprennent que Marionette ne nécessite pas de serveur back-end spécifique. C'est du JavaScript basé sur un navigateur, et le back-end n'a pas d'importance.

Bien sûr, je soutiens pleinement d'autres personnes en fournissant des packages pour leur langage et leur framework. J'énumère ces paquets dans le Wiki et j'espère que les gens continueront à construire plus de paquets lorsqu'ils en voient un besoin. Mais c'est un soutien communautaire, pas un soutien direct de Marionette.

• https://github.com/derickbailey/backbone.marionette/wiki/Available-packages

Modifiez facilement les valeurs par défaut

Dans mes efforts pour réduire le code standard et fournir des valeurs par défaut raisonnables (ce qui est une idée que j'ai directement «empruntée» au LayoutManager de Tim Branyen), je reconnais la nécessité pour d'autres développeurs d'utiliser des implémentations légèrement différentes de celles que je fais.

Je propose un rendu basé sur des <script>balises en ligne pour les modèles, en utilisant le modèle Underscore.js par défaut. Mais vous pouvez le remplacer en modifiant les objets Rendereret / ou TempalteCachedans Marionette. Ces deux objets fournissent le cœur des capacités de rendu, et il existe des pages wiki qui montrent comment changer cela pour des moteurs de modèles spécifiques et différentes façons de charger des modèles.

Avec la v0.9 de Marionette, cela devient encore plus facile. Par exemple, si vous souhaitez remplacer l'utilisation de blocs de script de modèle en ligne par des modèles précompilés, vous n'avez qu'à remplacer une méthode sur le moteur de rendu:

Backbone.Marionette.Renderer.render = function(template, data){
  return template(data);
};

et maintenant l'application entière utilisera des modèles pré-compilés que vous attachez à l' templateattribut de votre vue .

Je propose même un add-on Marionette.Async avec la v0.9 qui vous permet de prendre en charge le rendu de vues de manière asynchrone. Je m'efforce continuellement de rendre le plus simple possible le remplacement des comportements par défaut dans Marionette.

Code comme configuration

Je suis fan de "convention sur configuration" dans certains contextes. C'est un moyen puissant de faire avancer les choses, et Marionette en fournit un peu - mais pas trop, honnêtement. De nombreux autres frameworks - en particulier LayoutManager - fournissent plus de convention sur la configuration que Marionette.

Ceci est fait avec un but et une intention.

J'ai construit suffisamment de plugins, de frameworks, de modules complémentaires et d'applications JavaScript pour connaître la douleur d'essayer de faire fonctionner les conventions de manière significative et rapide. Cela peut être fait avec rapidité, mais généralement au prix de pouvoir le changer.

Pour cela, j'adopte une approche "code as configuration" de Marionette. Je ne fournis pas beaucoup d'API de «configuration» où vous pouvez fournir un objet littéral avec des valeurs statiques qui changent un éventail de comportements. Au lieu de cela, je documente les méthodes de chaque objet - à la fois via le code source annoté et via la documentation de l'API réelle - dans le but de vous dire comment modifier Marionette pour qu'elle fonctionne comme vous le souhaitez.

En fournissant une API propre et claire pour les objets Marionette, je crée une situation où le remplacement du comportement d'un objet spécifique ou de la Marionette dans son ensemble est relativement simple et très flexible. Je sacrifie les appels de l'API de configuration «simple» à la flexibilité de fournir votre propre code pour que les choses fonctionnent comme vous le souhaitez.

Vous ne trouverez pas d'API "configure" ou "options" dans Marionette. Mais vous trouverez un grand nombre de méthodes qui servent chacune un but très spécifique, avec des signatures propres, qui facilitent le changement du fonctionnement de Marionette.

J'utilise actuellement backbone avec le module de gestion de disposition et le guidon comme moteur de création de modèles et j'ai trouvé très facile de configurer une petite application en utilisant un backend Grails déjà existant. Avant de commencer à utiliser le gestionnaire de mise en page, j'ai lu sur Marionette et Chaplin et les deux me paraissaient vraiment puissants mais complexes. Ensuite, je me suis souvenu pourquoi j'avais choisi à l'origine backbone.js: la simplicité. Tous ces frameworks ajoutent ce que le backbone a laissé de côté par la conception. Je ne dis pas qu'un framework est mauvais, mais si j'ai besoin de quelque chose de plus complexe, j'essaierai d'autres projets, comme ember.js ou sproutcore, car ils ont une base de code unique, écrite avec un objectif dans l'esprit de leurs développeurs. Ici, nous avons des cadres au-dessus d'un autre. Bien sûr, le backbone est un backbone non seulement pour la création d'applications, mais aussi pour l'écriture d'une bibliothèque plus puissante, mais la seule chose qui me semble vraiment médiocre est la couche de vue, car il manque un gestionnaire de mise en page et la possibilité d'imbriquer des vues. Avec le gestionnaire de mise en page, ce vide est assez bien comblé.

Donc, ma réponse à votre question est: commencez par utiliser le backbone tel quel, et demandez-vous ce qui manque et quelles étaient vos attentes concernant le framework. Si vous trouvez qu'il y a trop de choses laissées de côté par l'épine dorsale, allez les chercher dans les autres cadres et choisissez celui qui correspond le plus à vos besoins. Et si vous n'êtes toujours pas confiant dans le choix, peut-être que le backbone n'est pas pour vous et que vous devez chercher une autre solution (ember.js, sproutcore, ExtJs, JavaScript MVC sont tous bons). Si vous avez de l'expérience dans l'écriture d'applications clientes, vous n'avez pas vraiment besoin d'expérience sur tout le framework pour choisir le bon (pour vous, bien sûr)

J'ai étudié les différents frameworks construits avec Backbone.js et construit les Vertebrae pour un projet chez HauteLook. Les objectifs du projet comprenaient ... le chargement de script dynamique, le format du module AMD, la gestion des dépendances, la construction avec des bibliothèques principalement open source, l'organisation du code dans des packages, l'optimisation et la construction pour une ou plusieurs applications d'une seule page, l'hôte sur un serveur entièrement mis en cache, par exemple aucun serveur -side scripting en utilisant uniquement une API pour les données, et le plus amusant pour moi, utilisez le développement basé sur le comportement pour le projet. Il y a une description du projet sur: http://www.hautelooktech.com/2012/05/24/vertebrae-front-end-framework-built-with-backbone-js-and-requirejs-using-amd/

Notre problème:

Les bibliothèques sélectionnées (jQuery, Underscore.js, Backbone.js, RequireJS, Mustache) fournissent le chargement de modules, la gestion des dépendances, la structure de l'application (pour les modèles, les collections, les vues et les routes), les interactions asynchrones avec l'API, divers utilitaires et objets pour gérer les comportements asynchrones , par exemple (promesses) différés, rappels. La logique restante nécessaire pour compléter le cadre comprend:

• un objet (modèle) pour gérer l'état de l'application monopage;
• un gestionnaire de mise en page pour présenter, organiser / transition et effacer les vues, et
• contrôleurs qui répondent aux itinéraires, obtiennent / définissent l'état de l'application et confient le travail au gestionnaire de disposition.

Nos solutions (implémentées dans Vertebrae):

Gestionnaire d'état de l'application -

Le gestionnaire d'applications stocke les données en mémoire et conserve également les données dans le stockage du navigateur pour fournir une ressource pour les données / métadonnées communes. Fournit également des données (état) pour reconstruire les pages vues en fonction des interactions précédentes (par exemple onglet sélectionné, filtres appliqués). Le gestionnaire d'état de l'application fournit une stratégie permettant aux ressources de récupérer l'état. Destiné à agir comme une machine d'état.

Gestionnaire de mise en page -

Le gestionnaire de mise en page a une ou plusieurs vues ainsi que des destinations de document (DOM) pour chaque vue (rendue). Une page peut faire la transition entre de nombreuses vues, de sorte que le gestionnaire de mise en page garde une trace des états de vue, par exemple rendu, non rendu, affiché, non affiché. Vous pouvez utiliser le gestionnaire de mise en page pour charger paresseusement et rendre les vues (détachées) qu'un visiteur du site est très susceptible de demander, par exemple des changements d'onglets sur une page. La transition entre les états de vue est gérée par cet objet. Une mise en page entière peut être effacée afin que les objets de vue et leurs liaisons soient supprimés, préparant ces objets pour le garbage collection (évitant les fuites de mémoire). Le gestionnaire de disposition communique également l'état de la vue avec le (s) contrôleur (s).

Contrôleur -

Un objet contrôleur est appelé par une fonction de gestionnaire d'itinéraire et est chargé d'obtenir l'état pertinent (modèles d'application) pour générer une page (mise en page), (également responsable de la définition de l'état lorsque les itinéraires changent). Le contrôleur transmet les données dépendantes (modèles / collections) et les objets de vue construits pour une page demandée au gestionnaire de disposition. En tant qu'effet secondaire, l'utilisation de contrôleurs empêche l'objet de routes de devenir gonflé et emmêlé. Une route doit être mappée vers un contrôleur qui démarre alors la page vue, en gardant les fonctions de gestion de route allégées.

L'application Todos est hébergée à la fois en mode développement et optimisée sur Heroku ...

• http://vertebrae-framework.herokuapp.com/
• http://vertebrae-optimized.herokuapp.com/

Beaucoup de concepts dans les autres frameworks sont empruntés, par exemple la nécessité de déstocker les vues pour prévisualiser les fuites de mémoire comme indiqué par Derick Bailey - http://lostechies.com/derickbailey/ ; le gestionnaire de mise en page par Tim Branyen http://tbranyen.github.com/backbone.layoutmanager/

En résumé, Backbone.js est censé être un outil dans votre application, la bibliothèque Backbone.js ne fournit pas toute l'architecture dont vous aurez besoin pour créer une application, mais fournit d'excellentes interactions avec une API et une structure de code solide pour ... Les vues (agissent également comme des contrôleurs) et vos modèles et collections de couches de données, et enfin les itinéraires. Nous avons construit Vertebrae pour atteindre les objectifs de notre projet et avons décidé d'extraire le code en tant que cadre pour que d'autres puissent l'utiliser, apprendre ou autre chose.

La réponse à votre question à mon avis est d'apprendre de tous les frameworks et d'utiliser ce dont vous avez besoin pour atteindre vos objectifs, si vous trouvez que les objectifs de votre projet correspondent étroitement à l'un des frameworks construits avec Backbone alors super, sinon construisez votre propre framework il y a de bons exemples partagés par la communauté. Ou si vous vous trouvez un peu perdu dans la direction de votre application, choisissez quelque chose de plus opiniâtre et structuré, peut-être Ember.js. La grande chose est qu'il existe un bon assortiment de choix pour vous aider à coder en utilisant un modèle de type MVC (MVX) avec JavaScript.

J'ai développé le framework Luca en travaillant chez BenchPrep où nous l'avons utilisé pour développer plusieurs grandes applications d'une seule page en plus de la bibliothèque backbone.js.

J'avais travaillé avec ExtJS pendant plusieurs années auparavant et j'ai volé mes concepts préférés de ce cadre, tels que l'architecture pilotée par les composants où vous développez vos vues en tant que composants autonomes, puis les associez à d'autres composants à l'aide de vues de conteneur. Et comme il est fortement basé sur la configuration, développer une application dans Luca ressemble beaucoup à la description d'un objet avec JSON.

L'un des avantages de cette approche est la possibilité de réutiliser des composants dans plusieurs applications ou à différents endroits de votre application, avec seulement des modifications mineures en utilisant l'extension de Backbone. Il est également très facile d'expérimenter de nombreuses mises en page / présentations de composants en apportant uniquement des modifications mineures à la configuration JSON.

En plus d'un large éventail de fonctions d'aide / utilitaire, Luca Ships avec de nombreux dérivés de Backbone de plus haut niveau que vous pouvez assembler de toutes les manières imaginables pour créer une interface utilisateur complexe.

Vues, ​​composants, conteneurs

• Modèles augmentés, vue, collection, classes de routeur
• Options de configuration qui facilitent la communication entre les modèles, les collections, les vues, l'application et ses gestionnaires respectifs.
• Conteneurs (présentation fractionnée / colonne, disposition grille, vue onglet, vue carte / assistant)
• FormView avec tous les composants de champ standard et des aides pour la synchronisation avec un Backbone.
• GridView, pour générer des éléments de grille déroulants à partir d'un Luca.
• CollectionView, pour générer des vues basées sur une collection
• Barres d'outils / boutons

Styles et balisage Twitter Bootstrap gratuitement

• Luca joue très bien avec le framework de bootstrap Twitter. En définissant simplement Luca.enableBootstrap = true, et en incluant le CSS, vos composants (tels que les onglets, les barres d'outils, les boutons, les formulaires, les champs, les grilles, etc.) utiliseront automatiquement le balisage compatible avec Twitter Bootstrap et les conventions de classe CSS.
• Utilise le système Grid pour la mise en page et répond à la plupart des classes css de base bootstrap de manière intelligente
• Les composants Luca.Viewport et GridLayout sont configurés pour fonctionner avec les systèmes de grille réactifs, fluides ou statiques de bootstrap.
• Vise à fournir une correspondance un à un pour les composants de bootstrap Twitter, pour les représenter comme des vues de backbone configurables

Le composant d'application

• La machine à états basée sur Backbone.Model fournit des méthodes getter / setter et des événements de changement d'attribut comme style de flux de contrôle d'application
• Composant de contrôleur intégré qui masque / affiche les pages de l'application en réponse aux événements Backbone.Router ou State Machine
• Integrated Collection Manager qui garde une trace des collections que vous avez créées, vous permet de les étendre, de les regrouper, de leur attribuer des paramètres par défaut
• Un gestionnaire de socket qui est une couche d'abstraction au-dessus des services websocket qui rend le push aussi simple que Backbone.
• Un routeur d'événements de clavier qui déclenche des événements clés nommés sur les composants qui se soucient de répondre à de tels événements

Améliorations de la collection et du modèle

• Les collections sont basées sur backbone-query , qui fournit une interface de requête très similaire à mongoDb
• activer un stockage local Backbone.sync en définissant simplement collection.localStorage = true
• remplissage automatique des collections dont les données sont amorcées au chargement de la page
• méthodes mises en cache / propriétés calculées. mettre en cache le résultat des méthodes de collecte et faire expirer le cache en réponse aux événements de modification / ajout / suppression sur la collection ou ses modèles
• propriétés calculées sur les modèles. créer des attributs basés sur une fonction complexe et mettre à jour automatiquement la valeur calculée en réponse aux modifications

Événements et crochets

Les composants Luca sont plus libéraux avec les événements qu'ils émettent par rapport aux composants de base du stock. Ils émettront des événements comme avant: initialiser, après: initialiser, avant: rendu, après: rendu, activation, premier: activation, désactivation, premier: désactivation, et cela vous permet d'ajuster plus finement le comportement de vos composants. De plus, en définissant un événement dans la propriété @hooks sur votre vue, il appellera automatiquement une fonction de nom similaire pour vous si elle existe. Cela empêche beaucoup de code de style de rappel, ce qui améliore la lisibilité.

Vous pouvez également configurer la classe Luca.Events pour publier les événements sur un canal de publication / abonnement global, ce qui facilite la création d'une grande application et facilite la communication entre les modules.

Le Ruby Gem

Luca a été développé spécifiquement en travaillant avec les API Rails et Sinatra et pour cette raison, il est actuellement optimisé pour une pile spécifique, mais il ne vous verrouille en aucun cas dans un serveur spécifique.

Luca est distribué dans le cadre d'un Ruby Gem configuré pour fonctionner sur le pipeline d'actifs, ou sous forme de fichier JS téléchargeable.

Vous n'êtes pas obligé d'utiliser Rails ou Sinatra. Mais si vous le faites, j'ai inclus beaucoup de choses utiles:

• Les fichiers avec l'extension .luca sont traités comme HAML avec interpolation de variable de style JST. (équivalent à .jst.ejs.haml) par le pipeline d'actifs
• Un harnais de test pour navigateur, ou des tests unitaires basés sur Jasmine sans tête, ainsi que de nombreux assistants de test Backbone et Underscore.
• Un point de terminaison d'API pour l'ensemble d'outils de développement fourni avec Luca (plus d'informations à ce sujet plus tard)
• Un point de terminaison d'API qui vous permet d'utiliser Redis comme moteur de stockage sans schéma pour Luca.Collection avec une configuration minimale

Les outils de développement

• Les applications Luca peuvent activer une console coffeescript dans le navigateur avec des aides et des commandes spécifiques à Luca qui facilitent la surveillance, l'inspection et le débogage des applications et des composants Luca

• Avec l'aide de Rails Gem et de l'éditeur de composants basé sur CodeMirror de Luca, vous pouvez modifier le code source de Luca Framework ainsi que les composants spécifiques à l'application directement dans le navigateur, à l'aide de Coffeescript. Vous verrez des commentaires immédiats en réponse à vos modifications, les instances des objets affectés étant actualisées avec le prototype mis à jour, et vous pourrez enregistrer vos modifications sur le disque.

• Le Component Tester est un bac à sable en direct pour jouer avec les composants qui composent votre application de manière isolée. Il vous fournit des outils pour modifier le prototype du composant, configurer ses dépendances et configurer le composant. Le composant sera immédiatement rendu à chaque fois que vous effectuez une modification. Vous pouvez afficher et modifier le balisage généré par le composant, ainsi que le CSS directement dans le navigateur et voir immédiatement vos modifications. Cela en fait un outil d'expérimentation très précieux.

• Le testeur de composants sera bientôt intégré à Jasmine afin que vous puissiez voir les résultats de vos tests unitaires de composants en temps réel lorsque vous modifiez leur code

Luca est un travail en cours, mais maintient une API stable (pas encore 1.0) et a été utilisé dans plusieurs grandes applications de production. C'est certainement un cadre très avisé, mais je travaille à le rendre plus modulaire. Je travaille activement sur la documentation et les exemples de composants.

Je suis co-auteur de Chaplin et j'ai écrit une comparaison approfondie entre Chaplin.js et Marionette.js:

http://9elements.com/io/index.php/comparison-of-marionette-and-chaplin/

Ce n'est pas une «fusillade», mais tente d'expliquer les deux approches de manière équilibrée.