Howdy,

Je suis en train de bosser sur un site, sur lequel j'ai besoin de rédiger des articles en markdown.

La structure sera donc, pour chaque article :

• nom-de-l-article (dossier)
• • index.md (l'article lui-même)
  • image.jpg (image quelconque utilisée dans l'article)

J'ai donc besoin de lister tout ce petit monde (pour pouvoir lier et parser le contenu)… Et je ne sais pas comment faire. Tout le bouzin étant géré via du node/wepback, j'ai pensé utiliser le module fs mais le serveur final ne tournera pas sur NodeJs (hébergé sur Github Pages). Qu'est-ce qu'il existe pour faire ça ?

Autre possibilité étudiée : le tout étant destiné à être hébergé sur GitHub Pages, j'ai songé à la possibilité d'exploiter l'API de github pour lister les dossiers directement sur le repo ; mais c'est plus complexe que de simplement lister des fichiers locaux, et ça fait appel à une API "externe". Qu'en pensez-vous ?

Merci d'avance.

À ma connaissance, c'est pas trop possible dans un environnement statique, ce qu'est GitHub Pages au final.

Même si c'est au final un peu violent, tu peux utiliser l'API de GitHub, ou peut-être jeter un oeil du côté de Jekyll, pris en charge par GitHub Pages et qui pourra peut-être te convenir, en fonction du projet.

J'ai pensé à Jekyll oui, mais je cherche à tout faire moi-même en VueJS ; pour le lolz et pour le sport (et l'apprentissage, et la satisfaction personnelle, etc.). Mais c'est effectivement très proche de ce que je veux obtenir oui.

Je sais que putaindecode.io fait la même chose en react, mais je n'arrive pas à trouver comment dans leur source... https://github.com/putaindecode/putaindecode.io Il y a peut-être quelque chose que je rate là-dedans.

Merci pour ton avis en tout cas.

Rien qu'en survolant leur README, ça a l'air clair : ils utilisent l'API de GitHub.

Et surtout ils utilisent ça : https://phenomic.io

Et du coup j'ai tendance à penser qu'en fait, ils font la même chose qu'avec Hexo et d'autres : tu builds en local puis tu deploy sur GitHub Pages. Ce qui me semble, au fond, le plus logique.

Quand tu décortiques un peu leur code et celui de phenomenic, très vite (j'ai pas trop le temps de creuser), c'est vraiment le comportement que je vois : comme hexo, phenomenic se base sur un serveur node local pour tester ton site pendant le dev, puis t'as une commande build pour générer l'export statique de ton site, que tu pourras ensuite uploader sur GitHub Pages (eux intègrent même des scripts pour faciliter le tout).

Du coup et à la réflexion, je ferai pareil à ta place. Un p'tit script node et/ou bash que tu run en local, qui te génère ta liste de fichiers à traiter et la sauve quelque part en json, que tu manipules ensuite dans vuejs côté client. Sachant que, tant qu'à faire, je ferai déjà le parsing markdown en local plutôt que dynamiquement, histoire d'alléger le traitement.

Voilà, j'ai pas des masses plus de temps, je suis techniquement sur le dernier jour de mon dernier projet pro avant mes premières vacances en 4ans, donc j'ai la tête dans du debug de tout autre chose :D

D'accord, c'est ce que j'ai fini par soupçonner aussi ; du coup je vais m'atteler à ça, avec une commande npm deploy ou quelque chose d'approchant.

Merci ! Bon courage, et bonnes vacances ;)

En fait, c'est totalement phenomic qu'il me faudrait, mais avec VueJS en lieue et place de React… Du coup j'essaie de comprendre le mode de fonctionnement, mais c'est au-delà de mes compétences. Pourtant, ce serait un très bon exercice… Grmf !

Mauvaise idée. Enfin, dans la forme, pas dans le fond. Te plonger dans le code d'un outil déjà mature et en prod, tu vas t'y perdre, c'est sûr et certain.

Pars de zero. Définis ton architecture de base par toi-même, et va repiquer chez les autres si besoin uniquement. Commence par développer un moteur qui va répondre à tes besoins immédiats, et plus tard, si nécéssaire, tu le "génériciseras" si tu veux le publier.

Tel que j'ai compris ton truc, t'as pas besoin de grand chose : un simple script cli en node qui parse un tree (tu as déjà tout ce qu'il faut en natif avec le module fs, même si je te conseille fs-promise, un peu enrichi et surtout, comme son nom l'indique, "promise-friendly"), génère ta structure html correspondante, et d'autre part, tes scripts clients en vue que tu gères déjà.

Le truc avec phenomenic, c'est que c'est un outil ouvert, avec plein de trucs, de la preview dynamique, etc... logique que tu t'y perdes en te plongeant dedans.

D'accord, ça fait sens.

Mais j'ai besoin de comprendre justement quelle architecture définir… Par exemple, générer des fichiers html via du markdown, okay, j'ai trouvé comment faire. Mais ça ne suffit pas, il faut que ce soit généré dans une page "type" du site donc à travers un ensemble de pages VueJS... Ou bien est-ce qu'il faut simplement importer directement le html généré au sein d'une page vueJS ? Et du coup, comment générer en plus une route VueJS de façon "dynamique" pour chaque page ?

Ça me dépasse un peu, c'est pour ça que je cherchais des façons de faire dans d'autres outils. En essayant d'assembler un puzzle, je ne sais pas vraiment où je dois aller, du coup je ne comprend pas vraiment comment ce que je dois chercher.

Merci de tes conseils en tout cas

Je vais sans doute raconter des conneries

Basiquement, si tu veux jouer avec vuejs, c'est que ton objectif (je pense) est d'avoir un ou plusieurs templates et binder des articles dedans. Le cas échénant, vuejs ou pas, ça sera simplement de la génération de code html…

Du coup, si je devais faire ça, je ferais un builder de fichier json (markdown -> json) en référençant dans un seul fichier tes articles (faut checker le coup en bande passante cela dit). Il ne restera que l'UI à réaliser (vuejs + le routeur qui va bien).

...je rebondis (hop) sur l'idée de deepblue : si tu veux hoster sur GitHub Pages (ou était-ce un autre projet?), tu pourrais fragmenter tes articles en un json "index" qui indiquerait les adresses d'un ou plusieurs json de "stockage", pour optimiser le rapport requêtes/poids des données encodées en json...

Mmmh, mais c'est pas bête du tout cette histoires de json… Du coup, au build, je ne génère pas du html, mais des fichiers json, c'est bien ça ?

Oui, le but est bien d'héberger tout ça sur github pages. Tu parles de fragmenter les articles, mais dans quelle mesure ?

Merci beaucoup les amis, ça va relancer la sauce ça !

Comme le disait deepblue, il faudra voir la taille de tes json, et donc, au besoin, fragmenter tes articles en plusieurs json. Le plus logique dans cette optique, ce serait de fragmenter tes json pour correspondre à ta pagination. Imaginons 5 articles par page ; lors du build, tu regrouperas 5 articles par json (et toujours un fichier d'index pour connaître le nombre de pages et les relations entre elles).

Vous êtes les meilleurs. J'essaie ça dès que possible et je vous fais part de mes échecs.

Je reviens à l'assaut !

J'ai progressé, j'ai pu faire un petit script qui parse les fichiers markdown et les enregistres en multiples fichiers json.
Sauf qu'au final, je galérai pour exploiter cette configuration, donc j'ai modifié un chouïa pour ne garder qu'un seul json pour l'instant… Et sans pagination pour l'instant aussi.

Là où je coince maintenant, c'est pour afficher un article seul ; et c'est con, parce que c'est vraiment le dernier truc qui me manque pour que ça devienne exploitable (pas optimisé, mais exploitable).

En gros, je charge le json avec un petit coup de vue-resources (qui fait une sorte d'appel Ajax) :
Vue.resource(this.url).get(params);

Et ça me renvoie le json complet, que je traite dans une boucle : https://github.com/EmmanuelBeziat/emmanuelbeziat/blob/master/src/pages/blog/index.vue

Du coup, chaque élément est bien listé, avec le lien qui génère la bonne url. Mais ensuite, une fois là-dedans (le bon Template est chargé), je ne sais pas comment récupérer l'objet.… https://github.com/EmmanuelBeziat/emmanuelbeziat/blob/master/src/pages/blog/post.vue
L'objet reste vide sur la page.

Je ne vois pas vraiment comment récupérer un objet précis du JSON, en fait. Et faire ça, ça ne revient pas un peu au même que d'avoir un fichier par article plutôt qu'un json qui en contiennent plusieurs ? Est-ce qu'il ne vaudrait pas mieux pouvoir passer l'objet directement sans recharger le json ? J'essaie de savoir comment faire.

Une idée ? Un conseil ? Une fraise tagada ? Merci !

Je n'ai pas de solution propre. Naïvement, tu pourrais avoir une variable globale dans laquelle tu places l'objet contenant l'article à afficher quand tu un as un click sur un v-link mais ça ne marcherait que si tu passes systématiquement pas le listing avant d'afficher un post particulier.
Cependant, tu pourrais avoir à la fois un json pour l'ensemble de tes articles et un json par article. Ça te permet de gérer à la fois le listing (via une première requête) et d'afficher un article particulier dans une seconde requête.

Allez hop, je remonte tout ça pour donner des nouvelles : ça avance pas mal. Même très bien. En fait, j'ai presque fini, il ne reste grosso modo qu'à faire certains contenus.

Il me reste deux problèmes liés aux plugins de vue-js eux-même (vue-head et vue-router) : lorsqu'on accède à une page depuis l'intérieur du site, tout se met en place correctement.Ainsi, sur chaque page je peux définir différentes meta (pour le partage twitter / facebook /g+, un title différent, une desc différente, etc), mais si j'accède à une page directement depuis l'url (en cliquant sur un lien externe, ce n'est pas modifié correctement. Le dev de vue-head a dit qu'il allait se pencher sur ce problème.
De la même façon, une requête a été faite pour vue-router, afin qu'il soit possible de gérer des redirect (pour page 404, en gros) même depuis des subroutes.

En gros, pour l'instant je dois attendre que les autres aient corrigé "mes" problèmes, puis je mettrais le site en ligne sur GitHub pages (je vais laisser tomber mon dédié pour ce site) avec un peu de https et un déploiement continu avec Travis-CI.

Restera après le dev de fonctionnalités moins "urgentes" : short url pour le partage sur les réseaux sociaux, système de paging pour les articles (next / prev), affichage/tri des archives par catégories/tags, et champ de recherche.

Je me suis fait une roadmap https://github.com/EmmanuelBeziat/emmanuelbeziat/issues/1

Bref, merci pour votre aide, qui m'a permis d'en arriver là.

Ça a pris du temps, mais voilà, j'ai fini. Je n'ai plus qu'à faire des améliorations à l'envi, et à continuer à bloguer. Merci à tous!

Je ne sais pas si ce sont mes confs firefox qui posent soucis, mais je n'arrive pas à afficher ton site sur ma version d'iceweasel (44.0b2) https://upload.deblan.org/u/2016-10/57f42ba6.jpg

Good job en tout cas, ça rend bien sur le butineur web de google