Créez une single-page app avec Node.js et Meteor

Ah ok

Merci bien pour le tuyau

Bonjour à tous!

Suite à la lecture de ce tuto très interessant, j'ai décidé de faire une petite page web en utilisant Meteor, histoire de mettre en pratique. J'ai également regardé du côté de certains projets libres utilisant ce framework; je pense ici à Rocket.Chat ou Wekan. Hors dans ces projets, la façon d'utiliser Meteor semble un peu différente puisque il faut utiliser

1

meteor build ...

pour obtenir du code ressemblant à ce que tu présentes dans le tutorial.

J'aimerais bien comprendre en quoi ces deux approches diffèrent et si possible avec quelques détails sur le fonctionnement de ce meteor build.

meteor build est utilisé pour le déploiement d'une application meteor, pas pour le développement.

En effet, et ce que je cherche à comprendre, c'est si ça change la manière de developper avec Meteor.

Si on prend l'exemple de la gestion des utilisateurs pour le project Wekan, on peut voir que l'inclusion {{> loginButtons}} n'apparait à aucun moment dans les sources, mais se retrouve bel et bien présent après déploiement.

Non, ça ne change à la manière de développer.

Il est tout à fait normal et absolument préférable que lors du développement le code produit ne soit pas identique au code utilisé lors du déploiement. Je ne vais pas lister ici toutes les différences entre ce que produit meteor et meteor build, je vais plutôt te donner un exemple : quand tu es en train de développer, tu as envie de pouvoir aisément débugger ton application, le code généré doit donc être lisible. Quand tu déploies ton application, tu te fiches de débugger le truc puisqu'on ne débug pas en production, par contre tu as envie que ton application se charge et s'exécute rapidement chez les clients, donc meteor minifie le code et le regroupe en un seul fichier.

loginButtons est un template provenant d'un package useraccounts-* dont Wekan dépend.

D'accord, merci!

Je développe depuis plusieurs années avec Meteor, mais manifestement le cours n’est plus avancé et certains outils aujourd’hui massivement utilisés ne sont pas présentés ici. Est-ce qu’il y a un moyen de reprendre la rédaction de ce cours, ou d’y contribuer?

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

C’est un dépoussiérage de l’installation et des informations sur l’organisation d’un projet Meteor. Je continue de revoir le reste.

Merci d’avance pour vos commentaires.

Il va te falloir beaucoup d’abnégation, Genroa.

J’avais déjà fait un certain nombre de remarques à l’auteur précédent, et j’ai rapidement regardé ce que tu as modifié, je te cache pas qu’il y a vraiment du boulot pour remettre ça d’aplomb.

Tiens, je crois que t’y as pas trop touché encore depuis que t’as repris le tuto, mais voici mes remarques pour la toute première partie :

Si vous êtes ici, c’est que vous avez très certainement déjà utilisé Node.js, voire que vous avez déjà roulé votre bosse avec ce petit trésor issu du moteur V8 de Chromium…

Pas du tout issu de V8.

Node.js a fait pas mal d’émules depuis sa sortie, si bien qu’il divise : soit les développeurs la détestent, soit il la trouvent géniale. Toujours est-il qu’elle a rassemblé une solide communauté, à l’instar du langage JavaScript sur lequel elle se base.

Je sais pas à quoi l’auteur pensait en parlant d’émules. Je vois vraiment pas. Je pense qu’il faudrait enlever tout cette phrase. D’autant que l’enchainement logique "faire des émules DONC diviser l’opinion", c’est foireux. C’est aussi il me semble un des seuls passages du tuto où Node est féminin. En français on considère plutôt que Node est un framework ou un runtime, et on l’utilise au masculin.

Node.js offre des performances tout à fait satisfaisantes tout en fournissant un écosystème très riche à travers un nombre de modules impressionnant et un système de gestion de dépendances qui faisait cruellement défaut au monde du Javascript.

Pas top, la formule "un nombre de modules impressionnant", plutôt "un nombre impressionnant de modules". NPM est plus un gestionnaire de paquets qu’un gestionnaire de dépendances.

De plus en plus de grands acteurs du web se tournent vers Node.js : Facebook (React)

React ? Euh…

Premièrement, il faut différencier les frameworks "lightweight" (traduisez par "légers"), comme Express, des frameworks plus lourds, comme Meteor ou encore Sails.js. Néanmoins, sachez que Meteor se démarque des autres frameworks sur de nombreux points.

"Néanmoins" : enchainement foireux.

En effet, les frameworks légers se "greffent" sur Node.js: ils demeurent des modules. Les frameworks lourds sont des systèmes plus évolués, mais qui contiennent encore des références à Node.js.

Non.

un système de publications/souscriptions pour la synchronisation de la base de données

Non.

une solution intégrée de rendu coté client, réactive (nous en reparlerons, elle s’appelle BlazeJS)

Ce n’est plus le cas.

Cependant, Meteor est très, très modulaire!

"Cependant" : enchainement foireux. Faudrait tous les revoir à mon avis, les phrases de l’auteur original sont vraiment pas top. Néanmoins, elles sont très souvent pas correctes. Cependant, ça vaudrait le coup de les corriger.

Ce qui est très intéressant dans Meteor, c’est donc son souci de la réactivité, tout en restant extrêmement modulaire.

Aïe. Je comprends l’intention de l’auteur de faire des phrases tout en rédigeant un tutoriel.

Dans cette première partie, Meteor est grossièrement décrit à coup de phrases bateau et de trucs techniquement faux, et la principale particularité de Meteor, c’est à dire la seule chose qu’il vaudrait vraiment la peine de relever en présentant Meteor, est tout simplement manquante : le JS isomorphic. Un même bout de code JS tournera :

• Sur node (server side)
• Dans le browser (client side)
• Dans une application mobile (iOS, Android)

Ça m’a un peu découragé de continuer, là maintenant. Si tu continues à y travailler, je repasse volontiers quand t’auras bien relu et corrigé les autres sections du tutoriel pour te donner mon avis.

En fait, je parlais de solution intégrée de rendu coté client, car BlazeJS est toujours pour le moment dans la liste des dépendances par défaut qu’il faut retirer à la création d’un projet pour y placer autre chose (puisque l’exemple de base l’utilise). La formulation n’est pas très bonne, en effet.

Pour tout le reste avant, je n’y avais pas trop touché et j’avais pas trop regardé; je trouvais le coté obsolète de la technique présentée plus alarmant.

Je vais me pencher en détail sur tes retours pour corriger ce qui m’a échappé, mais rien qu’en regardant les citations que tu as posté sans leur message, j’y vois les erreurs dont tu parles en effet.

Concernant le coté "export pour tout support" de Meteor, c’est évoqué un peu plus loin il me semble, dans le "Meteor au détail". Dans celle-ci j’ai tenté de décrire plus en détail les intérêts de la technologie, sans pour autant éclater à la hache (ou au curseur en l’occurrence) la section précédente qui semblait faire un bref historique de Node et d’où se plaçait Meteor par rapport à ça… Je vais relire le début plus en détail, sans rien sauter.

Edit: en fait, je pense que ça se sent que j’essaie de greffer des corrections parce que je n’ose pas détruire le contenu d’origine du tutoriel… Parce que sinon, à ce rythme, autant que je le reprenne de zéro en allant jusqu’à redéfinir tout le déroulement du tutoriel. ^^’ J’hésite à aller jusque là.