Gatsby: Utilisation des composants React dans la source Markdown

C'est une bonne idée. Je serais prêt à travailler si ce n'est pas encore disponible.

Je suis le développeur de reactdown. Ce serait génial de voir Reactdown travailler avec Gatsby. Ping moi si vous avez des questions ou avez besoin d'aide concernant son intégration.

👍 c'est une demande courante, ce serait donc formidable d'avoir quelque chose qui fonctionne et qui est largement disponible!

J'ai mis en place un référentiel d'exemples rapide et sale sur la façon de faire fonctionner Reactdown avec gatsby. Il est bon de noter que sous le capot, gatsby est juste un emballage très convivial sur le dessus du Webpack, donc toute la puissance est toujours là pour faire à peu près n'importe quoi.

https://github.com/benstepp/gatsby-reactdown

Merci, je vais l'essayer et je vous ferai savoir comment cela s'est passé.

Oh cool! Nice Ben. C'est beaucoup plus simple à configurer que je ne l'avais imaginé
haha. Beau travail Andrey.

Le mar 7 juin 2016 à 22:31, Jo Meenen [email protected] a écrit:

Merci, je vais l'essayer et je vous ferai savoir comment cela s'est passé.

-
Vous recevez ceci parce que vous avez commenté.

Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/gatsbyjs/gatsby/issues/312#issuecomment -224492088,
ou couper le fil
https://github.com/notifications/unsubscribe/AAEVh-2doZe_FXFMBxYTJ5FAVqo4XqxNks5qJlO6gaJpZM4Iubim
.

@benstepp sympa! Cela semble assez simple lors de l'utilisation de fichiers Markdown via un wrapper, mais cela fonctionnerait-il également lors de l'importation du fichier Markdown à utiliser dans un composant React?

Edit: il semble que cela devrait fonctionner immédiatement, mais d'une manière ou d'une autre, le composant React dans lequel le fichier md est transformé ne produit rien ...

Je réfléchis à une approche différente que la nouvelle couche GraphQL (# 420) ouvre. J'ai ouvert un problème à ce sujet dans le repo mdash https://github.com/wooorm/mdast/issues/13

Ce serait génial! Je me sentais si proche de Reactdown cependant… Les fichiers markdown sont correctement transformés en composants React par webpack (du moins ça y ressemble), mais cela me donne juste des composants vides lorsque je les utilise dans mon code.

@SachaG a un repo quelque part que je peux jeter un œil?

Wow, vraiment bizarre. J'essayais de créer une reproduction du problème, et maintenant ça marche! Je ne sais même pas ce qui a changé ... Je ne peux pas me plaindre je suppose :)

Les dieux de React sont descendus dans un char d'or, et voilà! le code a fonctionné

@SachaG Je me souviens qu'il y avait des problèmes avec la façon dont reactdown fait référence à son exécution. Quoi qu'il en soit, si vous rencontrez des problèmes, je serais plat pour aider.

salut! Y a-t-il eu des mises à jour récentes à ce sujet? Quelle est la méthode recommandée pour utiliser les composants de réaction dans le démarquage? Y a-t-il un exemple que je peux suivre? Merci!

Pas encore :-( J'ai un bon plan pour savoir comment le faire - en gros, compilez le fichier markdown dans un fichier de composant React où vous gérez correctement l'importation de tous les composants React référencés mais n'avez pas encore besoin de le construire. N'hésitez pas à commencez à travailler dessus si vous en avez besoin!

@KyleAMathews voulez-vous dire que je devrais exécuter un script de conversion sur mon fichier markdown, puis ajouter manuellement les autres composants de réaction dont j'ai besoin au fichier de sortie produit par l'étape de conversion? Une fois que cela est fait, faites la construction finale?

Ce serait idéalement un plugin pour Gatsby v1 qui ferait ces étapes
automatiquement.

Le mar 2 mai 2017, 12 h 50, Piyush Singh [email protected] a écrit:

@KyleAMathews https://github.com/KyleAMathews voulez-vous dire que je devrais courir
un script de conversion sur mon fichier markdown, puis ajoutez l'autre réaction
composants dont j'ai besoin pour le fichier de sortie produit par l'étape de conversion? Une fois que
ceci est fait alors faire la construction finale?

-
Vous recevez cela parce que vous avez été mentionné.

Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/gatsbyjs/gatsby/issues/312#issuecomment-298741837 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAEVh4riB8uXgeRUybcR6OxsC1EAKnkKks5r14kPgaJpZM4Iubim
.

Un exemple simple de ce que je veux dire.

Imaginez que vous ayez un fichier de démarque sur /my-blog/index.md qui ressemblait à ceci:

---
title: "hi folks"
---

# This is my broomstick

Yo yo foo

<SweetComponent props="super cool" />

Le corps pourrait alors être converti en un composant de réaction qui serait exécuté via webpack / babel / etc. comme d'habitude.

import React from 'react'
import SweetComponent from 'auto-resolve-this-somehow'

class MarkdownBody extends React.Component {
  render () {
    return (
      <div>
        <h1>This is my broomstick</h1>
        <p>Yo yo foo</p>
        <Sweet Component props="super cool" />
      </div>
    )
  }
}

La partie astuce est de savoir comment intégrer cela avec le système graphql de Gatsby. Idéalement, vous pourriez simplement rechercher la version «composant» d'un fichier de démarque similaire à la façon dont vous pouvez rechercher le HTML aujourd'hui.

Quoi qu'il en soit, c'est un bref aperçu de ce à quoi j'ai pensé.

@KyleAMathews merci, je pense que j'ai l'idée maintenant.

Mon objectif est de pouvoir écrire un contenu comme celui-ci qui tire parti des visualisations MathJax, D3.js et pourrait également incorporer des composants d'animation Three.js dans la source de démarquage.

Si vous voyez la source html ici, la page utilise jQuery pour certains des curseurs de contrôle, bien que j'imagine qu'il pourrait y avoir de meilleures façons de faire des choses jQuery avec les composants React?

D'après ce que j'ai compris jusqu'à présent, j'imagine que produire un tel contenu avec le framework Gatsby est réalisable de manière beaucoup plus ordonnée et structurée, n'est-ce pas?

Je suis nouveau dans le développement Web, mais je fais de mon mieux pour apprendre comment fonctionne le système Gatsby afin de pouvoir contribuer à atteindre ce genre d'objectifs ...

@KyleAMathews , j'ai réfléchi à votre proposition de solution.

Pensez-vous que quelque chose comme markdown-it-jsx pourrait être utilisé ou amélioré pour effectuer la conversion vers la structure de composant MD JS souhaitée?

Pour résoudre auto-resolve-this-somehow part, un deuxième analyseur pourrait peut-être analyser le fichier de composant MD JS pour rechercher JSX qui correspondent à ceux d'une liste de registre de composants (qui pourrait être un simple fichier texte ou une recherche de fichier dans le répertoire où tous les composants seront stockés), puis ajouter la ligne d'importation appropriée en haut du fichier?

Je vais commencer à travailler là-dessus, donc tout commentaire serait génial!

Juste une note, il y a un autre projet qui fait cela, peut-être qu'il sera utile comme référence: react-styleguidist . Exemple de fichier markdown

L'activation des composants dans le démarquage me rappelle ce chef-d'œuvre de Bret Victor.

UPD: et un autre exemple: mdxc

Et un autre http://thejameskyle.com/react-markings.html

Une solution utilise react-jsx-parser .
Chez howtographql.com, nous l'utilisons en production: https://github.com/howtographql/howtographql/blob/master/src/components/Tutorials/Markdown.tsx#L182

Un inconvénient: c'est bien sûr plus lent que d'utiliser simplement dangerouslySetInnerHTML , car il

1. Analyse le HTML
2. Construit un arbre dom virtuel
3. Rend l'arborescence virtuelle avec React

Une façon d'accélérer cela serait de ne pas envoyer le html brut avec la requête graphql, mais d'envoyer en fait un format que les documents Inferno.js utilisent, comme décrit ici .

Comme je ne trouve actuellement pas le temps de faire cette dernière étape d'optimisation, quiconque s'y intéresse pourrait adopter cette approche.

Cela voudrait dire

1. Construisez des types GraphQL appropriés, cela ne devrait pas être un problème car les types GraphQL peuvent être récursifs et représenter un arbre
2. Une fois que l'analyse syntaxique remark est terminée, générez un format jsx sérialisé.
3. Dans React, désérialisez ce format.

Une autre option que j'ai envisagée est https://github.com/mapbox/jsxtreme-markdown

Nous pourrions utiliser un modèle similaire. Convertissez simplement le démarque en composants JSX. Utilisez des délimiteurs personnalisés pour ajouter JavaScript et JSX. Nous pourrions très bien utiliser notre configuration Remark existante. Et il n'y aurait pas beaucoup de pénalité en termes de performances car il ne s'agirait que de pages React normales.

Il y a aussi https://github.com/cerebral/marksy , que j'ai utilisé récemment à bon escient.

Y a-t-il une approche recommandée pour cela dans le contexte de Gatsby ou est-ce encore à décider?

Salut, une recommandation pour inclure des composants douaniers dans nos fichiers de démarques Gatsby?

Une option supplémentaire dans la collection https://idyll-lang.github.io/

On dirait que marksy fonctionne bien pour ce cas d'utilisation

comme il renvoie un arbre d'éléments de réaction, je me demande comment je pourrais l'intégrer dans un plugin gatsby?

@KyleAMathews @revolunet Que pensez-vous de l'enregistrement des composants que nous devons utiliser comme éléments personnalisés, après quoi nous pouvons simplement les inclure dans le billet de blog et laisser le reste du travail au navigateur?

Cela éliminerait tout besoin d'analyser le démarque comme un arbre de réaction et de garder notre application performante, cependant, je ne sais pas s'il y aura un coût de performance, pour faire ReactDOM.render chaque fois que nous devons ajouter un nouveau des composants personnalisés, mais cela nous donnerait quand même un moyen assez cool d'ajouter des fonctionnalités dynamiques aux articles de blog.

@abdulhannanali Enregistrer les composants disponibles dans le démarque est une bonne idée, mais les éléments personnalisés ne semblent pas très conviviaux côté serveur :)

J'ai donc essayé de penser à une façon propre de mélanger React & Markdown pour toujours. Ou du moins depuis que j'ai commencé à travailler sur Gatsby.

Et enfin je pense que j'ai une idée qui pourrait marcher.

Nous utiliserions la même règle pour différencier les éléments HTML normaux et les composants React que JSX, c'est-à-dire que React est en majuscule.

Ainsi, vous pouvez inclure des composants React directement dans votre Markdown, par exemple

# Hi folks

I'm writing some markdown about speaker <Person id="Paul Ryan">Paul Ryan</Person> who's the speaker of the house and other stuff.

<InteractiveComponent invertedColors={true} allTheProps={true} />

Ensuite, cela serait analysé dans un AST quelque chose comme:

[
  [{ raw: true, value: "<h1>Hi Folks</h1>" }],
  [
    { raw: true, value: "<p>I'm writing some markdown about speaker " },
    {
      raw: false,
      value: {
        name: "Person",
        props: { id: "Paul Ryan", children: "Paul Ryan" }
      }
    },
    { raw: true, value: " who's the speaker of the house and other stuff.</p>" }
  ],
  [
    {
      raw: false,
      value: {
        name: "InteractiveComponent",
        props: { invertedColors: true, allTheProps: true }
      }
    }
  ]
];

Et puis dans votre composant, au lieu de rendre directement (style de danger) le HTML, vous le passeriez à la place à une fonction d'assistance avec un mappage à chaque composant React quelque chose comme:

import React from "react";
import renderHtmlReact from "gatsby-render-html-react";
import Person from "../components/Person";
import InteractiveComponent from "../components/InteractiveComponent";

export default ({ data }) => (
  <div>
    {renderHtmlReact({
      ast: data.markdownRemark.ast,
      componentMap: { Person, InteractiveComponent }
    })}
  </div>
);

// Your query goes down here

Nous aurions besoin de faire du prototypage pour nous assurer que cela fonctionne avec Remark, mais je suis presque sûr que le React "Html" serait transmis intact. Donc, nous aurions juste besoin d'un analyseur pour diviser le HTML et transformer les parties React JSX en données ainsi que la bibliothèque frontend pour rendre le résultat "AST".

Pensées?

Et puis dans votre composant, au lieu de rendre directement (style de danger) le HTML, vous le passeriez à la place à une fonction d'assistance avec un mappage à chaque composant React quelque chose comme:
[…]
Pensées?

C'est quelque chose que nous avons fait aussi (très simplifié, pas vraiment sûr et conçu uniquement pour des balises spécifiques). Notre cas d'utilisation était de styliser / mettre en page un document JSON:

<IconGrid src="sensors.json" />

Cela a été vraiment utile pour éviter le contenu dupliqué et nous envisageons d'utiliser un mécanisme similaire pour les composants de documentation API réutilisables.

Ce qui manque à cette solution, que nous n'avons pas non plus résolu, c'est l'utilisation du démarquage dans les propriétés des composants. Pour que quelque chose comme ça soit possible:

<Api method="post" description="
An API which uses **markdown**.

And having multi line parameters would be helpful as well.
" />

Après avoir essayé des tonnes de trucs dans cet espace pendant un moment, je suis convaincu que oui, cela doit vraiment être résolu au niveau de la démarque. Cela signifie que la saveur de démarque doit vraiment comprendre jsx / react. Le problème est vraiment l'interpolation javascript que jsx prend en charge et le markdown s'étouffe. Jsxtreme-markdown se rapproche et contourne ce problème en les traitant d'abord, puis en utilisant markdown pour analyser le reste. Une autre approche consiste à s'appuyer sur la capacité naturelle des analyseurs MD à gérer le html et donc le jsx simple (Marked, par exemple, gérera les éléments en majuscules), mais vous vous heurtez rapidement à des limitations ennuyeuses, car seules des chaînes sont bloquées et aucune démarque imbriquée (par exemple, Markdown à l'intérieur) , accessoires enfants). L'autre problème est que l'hydratation du client devient ennuyeuse car vous avez besoin d'un runtime (et généralement assez grand) pour convertir une chaîne en éléments de réaction, ce qui n'est pas idéal pour que Gatsby se concentre sur le temps rapide d'interaction et de performance.

Je pense que la voie la plus prometteuse pour aller de l'avant est une approche astucieuse, mais pour cela, vous avez vraiment besoin d'une variante de démarque rapide qui soit suffisamment différente de celles existantes pour constituer un projet considérable.

Juste jeter mes 2 cents!

Avant de savoir que gatsby existait (il y a 2 ans), j'ai essayé de créer un générateur de site statique réagissant qui se comportait de la même manière que jekyll ( rovr ). Je voulais mélanger markdown, react et html dans mes fichiers md.

J'ai choisi d'utiliser une expression régulière pour trouver <CapitalizedComponents/> dans le contenu de démarque et cela a plutôt bien fonctionné, sauf qu'il y avait quelques cas extrêmes. À l'époque, j'utilisais marqué qui avait des effets secondaires étranges autour de leur analyse de HTML.

De plus, mon expression régulière simpliste ne permettait pas les balises de fin de composant et donc aucun enfant ... donc cela n'a pas fonctionné:

<Component>
   <Child/>
</Component>

Quoi qu'il en soit, je suis vraiment ravi que gatsby soutienne cela! Je suis en train de convertir mon site jekyll en gatsby et je suis presque terminé. Ma prochaine tâche consiste à trouver comment changer mon jekyll inclut dans les articles de blog md en composants dans ma version gatsby.

@jquense convient que ne pas prendre en charge JS dans le démarquage serait une limitation. Mais à l’avantage, cela s'intégrerait parfaitement dans notre structure existante. La bibliothèque d'exécution serait assez simple, juste une boucle récursive sur les éléments de création AST. Nous pourrions également le configurer pour analyser automatiquement tout texte enfant des composants en tant que démarque afin que les composants pour cela ne soient que dangerouslySetInnerHTML sur props.children .

Ce n'est pas une solution à 100% mais cela fonctionnerait pour de nombreuses configurations. Je ne suis pas non plus un grand fan de l'idée d'écrire JS à l'intérieur du markdown. Vous perdez ainsi tout le support d'outillage.

@jakedeichert ouais, une simple regex ne va pas plus loin. Cool, vous avez quelque chose de similaire à ce travail! Cela valide le concept. Nous voudrions utiliser un analyseur JS qui comprend JSX pour extraire des informations structurées. De cette façon, nous pourrions prendre en charge les composants imbriqués.

@KyleAMathews Quelle est la progression de ce que vous avez proposé?

Quelques réflexions à ce sujet:

1. J'ai un exemple de travail qui utilise la remarque pour transformer le démarquage contenant des composants de réaction arbitraires tmp-remarque-jsx . J'ai utilisé remark-html et hast-util-to-html comme projets de base.
   Voici un exemple d'utilisation + sortie: exemple
   Je peux vous fournir plus d'informations sur la façon dont cela fonctionne si vous êtes intéressé.
2. MapBox créé un paquet remarque réagissent qui se transforme en MarkDown réagissent éléments en utilisant remarque. L'adaptation du package pour accepter les éléments de réaction personnalisés peut prendre un certain temps.

Personne n'a commencé à y travailler afaik.

Le problème avec ces deux approches est qu'elles ne fonctionnent pas avec le système de données basé sur GraphQL de Gatsby car les requêtes GraphQL ne peuvent renvoyer que des données qui n'exécutent pas de code. remarque-react par exemple effectue la conversion markdown => html dans le client pour contourner ce qui est plus cher qu'idéal.

Donc, pour travailler avec GraphQL, vous avez besoin d'un runtime client pour créer les composants React. Ma proposition est venue de travailler sur une conception qui permettrait le plus petit temps d'exécution possible.

Je pense que je comprends maintenant. Donc, ce qu'il faut à votre avis, ce sont deux morceaux de code:

1. markdown -> prêt à utiliser HAST qui prend en charge les composants de réaction. (Ce code doit s'exécuter au moment de la construction?)
2. react enabled HAST -> react element (Cela devrait s'exécuter du côté client avec un runtime minimal / trivial)

Est-ce que je comprends bien? Est-ce que je manque quelque chose?

Ouaip!

J'ai parcouru un autre projet dans cet espace - a quelques idées intéressantes https://github.com/luiscarli/md-to-react

Salut,

J'essaye un autre coup. J'ai un exemple de travail de la première partie qui crée le HAST ici remarque-custom-element-to-hast . Il doit toujours prendre en charge l'utilisation du markdown en tant qu'éléments enfants et peut-être un chargeur de pack Web qui l'utilise.

@KyleAMathews Pensez-vous que l'approche correspond à votre point de vue?

Comme pour la deuxième partie, nous pouvons utiliser syntax-tree / hast-to-hyperscript . Voici un exemple d'utilisation wooorm / remarque-vdom .

@ fazouane-marouane cool! Ouais, d'un coup d'œil, cela semble vraiment proche. Bon travail!

Nous ne voulons pas utiliser hast-to-hyperscript dans le frontend car il a un tas de dépendances et nous voulons que le runtime soit aussi léger que possible - par exemple, il suffit de passer en revue l'AST en créant des éléments React. Alors déplacez-vous autant dans la deuxième bibliothèque dans votre module.

@KyleAMathews C'est super alors! J'essaierai de faire les étapes restantes dans les prochains jours. Espérons que cela nous rapprochera d'une solution pratique.

Salut @ fazouane-marouane & @KyleAMathews , j'ai lu votre discussion et implémenté des versions "simples" des différentes parties que vous avez décrites ici sur cette application sur laquelle je travaille.

Les parties intéressantes sont celles qui utilisent le code @ fazouane-marouane sous la forme d'un plugin gatsby ici et la partie où nous rendons HAST ici . Il peut également être intéressant de voir comment le HAST est récupéré grâce à GraphQL.

Veuillez noter qu'au moment où j'écris ce commentaire, il est loin d'être parfait, optimisé et propre.

EDIT: mon composant renderHAST est fortement inspiré par la façon dont phenomic traite le rendu du markdown côté client: https://github.com/phenomic/phenomic/blob/master/packages/plugin-renderer-react/src /components/BodyRenderer.js

@pbellon Merci de votre participation! Cela fera gagner beaucoup de temps à tout le monde. Le code semble faire ce qui est nécessaire pour le reste des étapes. J'essaierai plus tard ce soir.

Une chose que j'ai besoin de déboguer est la manière de gérer les enfants des composants.
Pour le moment, si je mets write in markdown This is a test <MyComponent>let's see how children are handled</MyComponent> la propriété MyComponent de children sera définie sur [0, null] .

Mais je ne sais pas si cela vient de l'analyseur ou de la façon dont j'hydrate HAST.

@pbellon il vient de l'analyseur. C'est un analyseur minimaliste pour prototyper cette réaction dans son ensemble. Il aura certainement besoin de quelques correctifs pour être utilisable dans tous les cas. N'hésitez pas à soumettre un problème si vous rencontrez plus d'exemples. Cela aidera quand même à faire une bonne base de test.

@ fazouane-marouane je vois. J'essaierai de mon côté de jouer avec votre code pour voir si je peux implémenter cette fonctionnalité (et faire un PR si j'arrive à le faire) mais cela ne semble pas une modification anodine 😮
J'ai créé un problème sur votre dépôt ici

Sonnerie avec mon 0,02 $. Dans le cadre du développement de GitDocs, nous avions besoin d'un moyen de permettre aux utilisateurs d'intégrer JSX dans des fichiers de démarque. Voici ce que j'ai jusqu'à présent.

Analyse Markdown

Le traitement de démarque utilise unifié , remarque et rehype . Un tokenizer personnalisé dérivé du tokenizer HTML du bloc de remarques avec un regex supplémentaire pour détecter JSX. Ce tokenizer permet à rehype de détecter les blocs JSX comme raw pour un traitement ultérieur.

J'ai écrit un plugin de rehype personnalisé qui fonctionne de manière similaire à rehype-raw mais qui prend en charge JSX et une évaluation d'expression de base. Le plugin trouve les nœuds raw et détermine s'ils sont JSX en essayant d'analyser le bloc en utilisant acorn-jsx . Si l'analyse réussit, le JSX AST produit par acorn est converti en HAST.

JSX pris en charge

Jusqu'à présent, je peux convertir les bits suivants de JSX (exemples de cas tirés de la suite de tests)

<Test>
  <Test2></Test2>
</Test>

<Test>some text</Test>

<Test attr={{ prop: 400 }} />

Expressions

L' évaluation d'expressions au moment de la compilation

<Test attr={1 + 2}/>

Le nœud HAST créé aura la propriété 'attr' définie sur 3 .

Expressions de tableau

L'utilisation de Array.prototype.map() est autorisée dans les propriétés:

<Test attr={ [1,2,3].map(x => 2 * x) } />

Vous pouvez même mapper sur un tableau et créer des enfants JSX

<Test>{ [1,2,3].map(x => (<Test2>{x}</Test2>)) }</Test>

sera traduit en HAST comme l'équivalent de

<Test>
  <Test2>1</Test2>
  <Test2>2</Test2>
  <Test2>3</Test2>
</Test>

Limites

La prise en charge des expressions est assez limitée et n'a pas fait l'objet d'un examen de sécurité. Le code n'utilise pas eval et l'accès à des choses comme window ne devrait pas être possible mais je ne peux pas donner de garanties.

J'ai fait une expérience dans ce domaine où vous pouvez utiliser pleinement les plugins de remarque gatsby comme d'habitude. Vous passez le html graphql à un chargeur webpack qui produit du code react.js. Malheureusement, il a plusieurs problèmes et interrompt les versions de production uniques.

          createPage({
            path: edge.node.fields.slug,
            component: getCdResolve(blogPost, edge.node.fileAbsolutePath, {
              html: edge.node.html,
              site: result.data.site,
            }),
            context: {
              slug: edge.node.fields.slug,
            },
          })

Où cdResolve renvoie une chaîne comme !!cd-resolve-loader!foo.md . Gatsby n'aime pas ça. Cela fonctionne au moins dans le serveur de développement.

Le reste du code est ici .

La sortie de construction est un composant simple avec un ensemble de nœuds statiques pour les enfants.

var h = require('react').createElement;
var n1 = h('div', { key: 1, dangerouslySetInnerHTML: { __html: '<h1>Hello</h1>' } });
var n2 = h(CustomComponent, { key: 2, foo: 1 });

module.exports = () => h('div', null, [n1, n2]);

Hein intéressant!

Cela interromprait malheureusement aussi le rechargement à chaud de la démarque en développement pour autant que je sache.

Oui, c'était un autre problème. Je pense que si les problèmes étaient résolus, ce serait l'un des meilleurs résultats finaux, en ce qui concerne la taille du paquet et le temps d'interaction. Bien sûr, c'est loin d'être une solution de travail. Des conseils sur la façon d'obtenir la compilation en fichiers JS après le travail de remarque?

@brigand Je pense que la solution la plus simple est ce que j'ai décrit dans un commentaire précédent https://github.com/gatsbyjs/gatsby/issues/312#issuecomment -336681894

@KyleAMathews Pour la solution que vous avez proposée, nous savons maintenant comment transformer le markdown contenant jsx en html AST à l' aide de remarques. Nous avons résolu le dernier bogue de blocage. Il ne nous reste plus qu'à créer le code capable de transformer cet AST en composant react et de le pousser dans npm. J'aurai du temps libre pour le faire d'ici la fin de la semaine prochaine.

N'hésitez pas à vous présenter à ma porte avec une batte de baseball si je ne pousse pas quelque chose d'ici là 😅.

@ r24y a fait fonctionner ça !!! Consultez son PR https://github.com/gatsbyjs/gatsby/pull/3732 et sa page d'exemple sur le site d'exemple using-remarque!

https://using-remark.gatsbyjs.org/custom-components/

Donc, rapporter mes progrès ici. J'ai eu le temps de terminer la deuxième étape.

Dans l'ensemble, nous avons deux forfaits:
L'analyse dans HAST: @ dumpster / remarque-custom-element-to-hast
Le rendu trivial dans le composant react: @ dumpster / hast-react-renderer

@pbellon a proposé un plugin Gatsby ici.

Ce pipeline devrait être plus permissif que le rehype. Si ma mémoire est bonne, rehype utilise l'analyseur 5 qui n'accepte pas <Note value="my content" /> et je ne me souviens pas s'il accepte les corps pour les éléments personnalisés.

@KyleAMathews Je ne sais pas quelle est la prochaine étape à partir d'ici.

@ fazouane-marouane génial !!!

Je pense que les prochaines étapes consisteraient à ajouter un exemple de site au référentiel afin que nous puissions également montrer votre travail - nous devons ensuite ouvrir une page de documentation sur gatsbyjs.org pour parler des différentes options et compromis dont ils disposent.

Sucré ! Merci pour les clarifications.

J'essaierai d'avoir quelque chose pour la semaine prochaine ou la semaine d'après (commencer un nouvel emploi ce lundi 😅).

Après avoir lu https://using-remark.gatsbyjs.org/custom-components/ et l'avoir essayé, j'ai créé un petit paquet nommé gatsby-remarque-component pour éviter les avertissements validateDOMNesting que vous obtenez si votre composant est dans votre démarque contient des éléments de niveau bloc (div ...). Les composants personnalisés sont par défaut enveloppés dans un paragraphe, alors qu'avec ce package, ils sont enveloppés dans un div.
C'est assez facile à utiliser

//In your gatsby-config.js
plugins: [
  {
    resolve: "gatsby-transformer-remark",
    options: {
      plugins: [
        {
          resolve: "gatsby-remark-component",
          options: { components: ["my-component", "other-component"] }
        }
      ]
    }
  }
]

J'espère que cela est utile à quelqu'un.

@Hebilicious merci pour le plugin; oui, j'ai réalisé que tous les composants personnalisés étaient rendus dans l'élément <p> et j'utilisais,

<div>
  <custome-component></custom-component>
</div>

comme solution de contournement.

Cependant, il est difficile d'inclure tous les composants personnalisés dans le fichier de configuration à nouveau, comme ce que je l'ai déjà fait dans le fichier modèle de démarquage.

@ li-xinyang Je suis d'accord avec vous. J'ai ajouté une fonction de détection automatique pour que vous n'ayez pas à les ajouter manuellement.
Assurez-vous de mettre à niveau le package vers la dernière version 1.1.0 si vous souhaitez l'essayer.
Cela fonctionne hors de la boîte avec:

//In your gatsby-config.js ...
plugins: [
  {
    resolve: "gatsby-transformer-remark",
    options: {
      plugins: ["gatsby-remark-component"]
    }
  }
]

C'est un peu une tangente, mais les gens ici pourraient être intéressés par une coordination avec @rauchg : voir la proposition

@ r24y sonne bien!

Je pense qu'il y a plusieurs façons de résoudre ce problème qui ont des compromis différents.

Je ne sais pas si vous êtes au courant du projet appelé Catalog qui prend également en charge l' intégration de composants React dans Markdown . Il existe également un plugin Gatsby appelé gatsby-remarque-design-system qui tente d'adapter le concept de Catalogue.

Cette solution semble parfaite @arcticicestudio

Le catalogue est joli; Et le plugin gatsby-remarque-design-system est cool, mais il ne prend pas en charge les composants React. Je pense que cela fait quelque chose de bien, il utilise la syntaxe de bloc de code existante pour ajouter des fonctionnalités plus complexes à Markdown.

Comme discuté à quelques reprises dans ce fil, je pense que l'utilisation de l'analyseur existant n'est pas tout à fait la fonctionnalité souhaitée. Peut-être qu'au lieu d'éléments React flottants libres, il serait possible de désigner plus clairement les composants React complexes de manière explicite, par exemple un fichier de démarque peut ressembler à:

 # Certains titres
 ... etc ...

<Example>
   <Etc />
</Example>

Lorsque nous voulons qu'un élément react incorporé soit rendu, nous spécifions le langage comme react , et un analyseur JSX se met en marche et génère un AST valide qui peut être utilisé avec rehype. Si nous voulons un exemple de prisme JavaScript normal, utilisez simplement le langage normal javascript .

Salut les gars, bonne discussion ici.
J'utilise le gatsby-remark-component et j'ai quelques questions:

1. Existe-t-il un moyen de «détecter automatiquement» les composants? Cela supprimerait la nécessité d'informer explicitement mes composants dans l'objet composants:

const renderAst = new RehypeReact({
  createElement: React.createElement,
  components: {

  },
}).Compiler

1. Existe-t-il un moyen d'intégrer certaines images avec le gatsby-remark-images ? L'un de mes objectifs est que l'utilisateur puisse ajouter une image et l'envoyer à mon composant via des accessoires, par exemple. Quelque chose comme:
   <my-component header-image="[](./image.png)"><my-component>

Merci!

@ThiagoMiranda Oui, (2) serait génial! Mon cas d'utilisation est une galerie d'images:

<gallery>
  <item source="image1.jpg" caption="One"></item>
  <item source="image2.jpg" caption="Two"></item>
</gallery>

Cet analyseur de démarques JSX de Zeit semble prometteur: https://github.com/mdx-js/mdx

MDX est un sur-ensemble de la spécification CommonMark qui ajoute le JSX intégré et la syntaxe d'importation / exportation.

Il est basé sur des remarques et des rehype, ce pourrait donc être une bonne solution de remplacement pour une utilisation dans les projets Gatsby

J'ai écrit un plugin pour mdx: https://github.com/nhducit/gatsby-plugin-mdx

cool, je voulais essayer ça avec Gatsby :)

En utilisant le plugin mdx de @nhducit, il est assez simple de câbler des pages MDX !!

1. Ajoutez la configuration pour mdx et source dans le répertoire pages/ .

gatsby-config.js

module.exports = {
  plugins: [
    'gatsby-plugin-mdx',
    {
      resolve: 'gatsby-source-filesystem',
      options: {
        name: 'pages',
        path: `${__dirname}/src/pages/`,
      },
    },
  ],
}

1. Interrogez tous les fichiers de démarque et créez des pages pour chacun d'eux.

gatsby-node.js

exports.createPages = ({ graphql, boundActionCreators }) => {
  const { createPage } = boundActionCreators

  return new Promise((resolve, reject) => {
    graphql(`
      { 
        allFile(filter:{extension:{eq:"md"}}) {
          edges {
            node {
              absolutePath
              relativeDirectory
              name
            }
          }
        }
      }
    `).then(result => {
      if (result.errors) {
        return reject(result.errors)
      }

      // Create markdown pages.
      result.data.allFile.edges.forEach(({ node: {
        absolutePath,
        relativeDirectory,
        name
       } }) => {
        createPage({
          path: `/${relativeDirectory}/${name}`,
          component: absolutePath
        })
      })
    })
    .then(resolve)
  })
}

1. Utilisez MDX 🎉

src/pages/my-markdown-page.md

import MyComponent from '../components/MyComponent'

# Title

_some content_

<MyComponent />

@avigoldman Nice! Ce serait formidable de voir votre exemple ajouté au fichier README du plugin @nhducit .

@avigoldman PR est le bienvenu! 👍

@avigoldman ressemble à cette approche en conflit avec le frontmatter?

@nhducit Je vais faire un PR!

@lintonye pouvez-vous expliquer un peu plus ce que vous voulez dire. Faites-vous référence aux exportations du MDX?

@lintonye avez-vous essayé d'utiliser les exportations mdx? Cela semble être un équivalent pour mdx: https://github.com/mdx-js/mdx#exports

Corrigez-moi si je me trompe, mais il semble que nous devions attendre Gatsby 2.0 avec une version ultérieure du webpack pour transmettre les plugins de remarque à MDX.

cc @KyleAMathews

@avigoldman @nhducit Lors de l'exportation de données hors des fichiers mdx à l'aide de la syntaxe d'exportation, comment pouvons-nous y accéder dans notre interface utilisateur lorsque les composants sont rendus?

même question ici, avec MDX actuellement, ne pouvait pas:

• appliquer des styles personnalisés aux pages de démarque
• injecter le contenu du frontmatter comme pathContext à partir d'exportations mdx nommées
  Cela pourrait être fait en fait, mais cela nécessite la création d'un fichier .js pour importer le fichier .md, pour chaque fichier .md, donc il duplique le travail ...

@slorber J'ai une solution assez hacky dans ce dépôt: https://github.com/avigoldman/avigoldman.com

Certainement pas idéal. Je vais y revenir une fois que Gatsby V2 sera sorti.

Salut et merci @avigoldman

J'ai également essayé de le faire ici https://github.com/nhducit/gatsby-plugin-mdx/issues/13#issuecomment -392334706

Il semble que vous ayez trouvé la pièce manquante dont je n'avais pas besoin pour extraire correctement les exportations: babel-plugin-config-export

Vous créez une mise en page par page de billet de blog, vous ne savez pas exactement si cela est censé être fait de cette façon ou quel genre d'impact cela peut avoir sur les performances de Gatsby, car les personnes utilisant Remark ont ​​généralement une seule mise en page à la place ...

Qu'en est-il de la publication de votre plugin sur NPM? cela semble plus utilisable que celui de @nhducit concernant le frontmatter

Aussi, d'où vient le fragment ... mdx graphql?

À propos de MDX, ils viennent d'ajouter un "MDXProvder" (basé sur React Context) qui peut être utile pour intégrer des balises personnalisées avec Gatsby, cc @avigoldman

@slorber J'ai créé un plugin gatsby-transformer-mdx pour pouvoir interroger les fichiers MDX.

Je traite chaque mise en page comme une page et chaque fichier MDX comme le contenu. Ainsi, la mise en page obtient le contexte de la page, puis le MDX est déposé (comme vous le feriez avec le code HTML généré par la remarque).
Cela ne fonctionnera pas dans Gatsby V2 car les composants de mise en page spéciaux disparaissent.

Le MDXProvider semble prometteur!

En ajoutant mes 2 ¢ ici, j'ai réussi à pirater la plupart de mon propre site Web (le dépôt utilise toujours Jekyll, sera bientôt mis à jour ou ajouter un nouveau dépôt) à Gatsby en utilisant mdx grâce à gatsby-transformer-mdx de @ avigoldman!

C'est génial! Devrait avoir du temps ce week-end / la semaine à venir pour en faire un package qui fonctionne bien avec Gatsby V2.

@avigoldman une chose que je n'ai pas pu comprendre à partir de votre gatsby-transformer-mdx est l'étape de rendu. gatsby-transformer-remarque utilise le champ html (qui est une chaîne), qu'est-ce que votre transformateur utilise? Comment fonctionne le chargeur Webpack s'il n'est requis nulle part?

Oh, je viens de lire les commentaires ci-dessus, l'astuce est que Gatsby v1 enveloppe automatiquement tout dans un composant de mise en page, vous utilisez donc absolutePath pour cibler le fichier MDX. 😃 Merci pour cette astuce!

@avigoldman des nouvelles sur le plugin Gatsby 2? Ce serait également génial si vous pouviez donner des instructions approximatives sur la façon dont vous le construiriez sans le composant de mise en page qui n'existe plus dans Gatsby 2.
Merci!

J'espérais pouvoir d'une manière ou d'une autre utiliser la fonction export default de MDX, mais passer des accessoires supplémentaires autres que children ne semble pas être possible au guichet automatique. mdx-js / mdx # 187

Si mon PR est fusionné (mdx-js / mdx # 189), je pense que nous pourrons utiliser MDX avec les gatsby-plugin-mdx et gatsby-transformer-mdx existants. Le seul changement requis sera de notre côté, et c'est l'exportation de notre modèle de publication à partir de nos fichiers .mdx :

src/posts/hello-world.mdx :

import Post from '../components/post'

# Hello World

Lorem ipsum.

export default Post

gatsby-node.js :

const path = require('path')

exports.createPages = ({ actions }) => {
  actions.createPage({
    path: '/posts/hello-world',
    component: path.join(__dirname, 'src', 'posts', 'hello-world.mdx'),
    context: { /* passed as pageContext */ }
  })
}

src/components/post.js :

import React from 'react'
import Layout from './layout'

export default ({ children, pageContext }) => (
  <Layout>
    {children}
  </Layout>
)

Je pense que c'est vraiment critique. À l'heure actuelle, tous les plugins gatsby-remark-* sont en train de ~ réimplémenter un tas de logique de rendu qui pourrait et devrait probablement être dans React. Cela pourrait beaucoup simplifier les choses.

@DylanVann ça dépend un peu. gatsby-remark-* plugins https://www.gatsbyjs.org/packages/gatsby-remark-images/?=remark-image

Idéalement, bien sûr, nous mélangeons les deux mondes.

@KyleAMathews Oui, cela signifierait un peu plus de JS côté client, bien qu'il soit toujours livré en HTML statique. Je pense que beaucoup de gens envoient probablement gatsby-image pour certaines parties de leur site de toute façon, donc dans ce cas, la duplication est moins un problème.

Je comprends qu'il existe des utilitaires dans les plugins gatsby-remark-* . La logique de rendu en particulier, qui est actuellement effectuée avec des chaînes, semble cependant pouvoir être effectuée dans React.

J'ai ce genre de travail avec la méthode htmlAst / rehype-react .

Cela semble être le cas, mais en pratique, c'est beaucoup plus compliqué. Si vous pensez que vous êtes sur quelque chose, vous pouvez soulever un nouveau problème avec une proposition ciblée.

Cela semble être un problème difficile à résoudre. Malheureusement, je ne pense pas avoir le temps de mettre en œuvre quoi que ce soit ou de faire une proposition. L'idée de faire des plugins remark en utilisant partiellement les composants personnalisés React fonctionne certainement, j'ai du code qui l'utilise.

Ceci est généré par @dylanvann/gatsby-remark-cloudinary partir d'images de démarque se terminant par mp4 . L'idée est d'optimiser les vidéos (dimensionnement au moment de la construction, ajout d'affiches). Je voulais cependant la logique de rendu dans React. Le traitement de la vidéo est effectué dans une autre fonction, mais cela fait partie de ce par quoi le HTML du nœud est remplacé.

export const videoHTML = ({
    srcVideo,
    srcVideoPoster,
    base64,
    paddingBottom,
    presentationWidth,
}) =>
    `<cloud-video srcvideo="${srcVideo}" srcvideoposter="${srcVideoPoster}" base64="${base64}" paddingbottom="${paddingBottom}" presentationwidth="${presentationWidth}"></cloud-video>`

Puis en utilisant un composant personnalisé avec rehype-react .

import React from 'react'
import rehypeReact from 'rehype-react'
import CloudVideo from './CloudVideo'

const renderAst = new rehypeReact({
  createElement: React.createElement,
  components: {
    'cloud-video': CloudVideo,
  },
}).Compiler

const Markdown = ({ ast }) => renderAst(ast)

Markdown.propTypes = {
  ast: PropTypes.object,
}

export default Markdown

L'ast peut être extrait de GraphQL.

Donc, ce composant fonctionne pour SSR et côté client. Quoi qu'il en soit, je sais comment c'est avec OSS. Je dis juste que je pense que ce serait une fonctionnalité intéressante et pourrait réduire la complexité du code, donc ce serait formidable si quelqu'un a le temps de trouver de meilleures solutions.

Je ne suis pas en désaccord avec tout ce que vous dites, je pense que commencer une bonne discussion serait beaucoup mieux dans son propre numéro, plutôt qu'à la fin d'un fil de discussion très chargé de plus de 60 commentaires. 😉

@Avigoldman et moi gatsby-mdx pour héberger des intégrations et des

Actuellement, les pages .mdx de gatsby fonctionnent par défaut après l'activation du plugin et les fonctionnalités supplémentaires suivantes ont été ajoutées en plus de mdx:

• Utiliser et interroger le frontmatter de style classique et JSON
• Définir des dispositions par défaut pour les fichiers mdx qui n'en définissent pas

Nous prévoyons également des intégrations plus sophistiquées pour

• traitement d'image avancé
• plugins personnalisés md et hast.
• compatibilité avec tous les mêmes champs que gatsby-transformer-remarque

Nous sommes encore assez tôt dans le cycle de vie, alors faites-nous savoir si vous rencontrez des problèmes et nous le ferons :)

@ChristopherBiscardi est-il destiné à être utilisé en combinaison avec gatsby-plugin-mdx ou à sa place?

@silvenon Il semble que gatsby-plugin-mdx sera obsolète et s'arrêtera donc à 1.0, tandis que gatsby-mdx ira de l'avant avec 2.0 et au-delà.

@ m-allanson pense qu'il est prudent de fermer ce problème maintenant que nous avons gatsby-mdx ?

Je pense que oui, merci à tous 🎉

Alors, est-ce que gatsby-mdx maintenant être préféré à rehype-react en conjonction avec gatsby-transformer-remark comme décrit ici ?

Si la réponse n'est pas clairement affirmative, quelqu'un pourrait-il expliquer les avantages et les inconvénients des deux approches?

Je pense que cette partie de ce billet de blog répond à votre question. rehype-react fournit des éléments HTML personnalisés qui correspondent aux composants React, mais MDX est en

Je ne suis pas dans l'équipe Gatsby, mais je dirais que oui, gatsby-mdx est le moyen préféré de React dans Markdown.

@janosh pour autant que je sache, gatsby-mdx ne peut pas encore remplacer complètement gatsby-transformer-remarque
semble toujours manquer gatsby-remarque-images & gatsby-remarque-copy-linked-files par exemple et d'autres plugins gatsby-remarque
Je pense qu'ils y travaillent mais pas sûr de l'état actuel

Mais si vous n'avez pas besoin de ces plugins ou que vous pouvez attendre, je dirais que oui, au moins je le préférerai, me semble plus propre

@CanRau Je en service avant la fusion.

L'état du PR est que les plugins gatsby-remarque- * sont appliqués correctement, mais il existe des différences dans la façon dont la sortie du plugin gatsby-remarque-prismjs (qui produit actuellement une sortie HTML) est gérée par transformer-remarque vs mdx pipeline. Je considère que le support des plugins comme gatsby-remarque-prismjs est important, mais aussi une approche sous-optimale. Une meilleure approche dans le monde MDX consiste à utiliser quelque chose comme prism-react-renderer comme élément code dans un MDXProvider , ce qui vous donnerait une flexibilité et un contrôle complets sur le rendu par rapport à l'utilisation remarques pour obtenir un effet similaire (et vous permettent également de partager ce composant avec du contenu non-mdx comme des pages .js).

Je suis beaucoup plus préoccupé par le fonctionnement des fichiers liés par copie et du traitement d'image que par les prismjs travaillant pour la première version du support du plugin gatsby-remarque- *.

Cela semble génial
Peut-être que je peux partager quelques commentaires, je pense que je vais essayer de petites méta-pages pour essayer des choses

intéressant de savoir que vous diffusez votre travail ... Je suis assez nouveau dans la vie et je ne comprends pas encore comment savoir quand vous allez vivre ... fonctionne probablement uniquement avec un compte, je suppose

Heureux de vous avoir de l'aide à tout moment dans le futur si vous trouvez le temps, n'hésitez pas à m'envoyer un ping si vous avez des questions :) Les commentaires en eux-mêmes aident beaucoup dans les deux cas, donc si vous essayez, assurez-vous de signaler les problèmes!

intéressant de savoir que vous diffusez votre travail ... Je suis assez nouveau dans la vie et je ne comprends pas encore comment savoir quand vous allez vivre ... fonctionne probablement uniquement avec un compte, je suppose

J'ai mis en place un "calendrier" des heures de streaming au bas de ma chaîne Twitch . Je sais que si quelqu'un a un compte Twitch et qu'il me suit, il recevra des notifications lorsque je serai en ligne, mais sinon, le calendrier est où chercher. À peu près sûr que vous pouvez voir si vous avez un compte ou non. Je suis un peu nouveau dans le streaming moi-même (je ne le fais que depuis quelques semaines maintenant), donc toujours ouvert à de meilleures façons de faire ce genre de choses. Quelques personnes sont venues à plusieurs reprises et traînent / regardent / discutent dans le chat, ce qui est assez amusant :)

kay compris, bon à savoir

et je publierai sûrement des problèmes quand j'en rencontre;)

Btw, puisque Prism a été mentionné, je voudrais simplement ajouter que les plugins de remarque / rehype devraient idéalement être utilisés directement, MDX prend en charge cela via les options mdPlugins et hastPlugins (cela peut être transmis via gatsby -mdx). Des plugins comme @ mapbox / rehype-prism peuvent être ajoutés à hastPlugins , mais il y avait des problèmes d'espaces blancs que j'ai corrigés dans mdx-js / mdx # 226, donc une fois que cela sera fusionné et publié, la coloration syntaxique sera bonne aller!

ouais, totalement. gatsby-mdx prend déjà en charge le passage des plugins de remarque / rehype via mdx core. Voici @ mapbox / rehype-prism par exemple (j'ai retiré cet exemple de certaines de vos discussions PR / Issue à l'origine @silvenon , merci). AFAIK rehype prism ne prend pas en charge les plugins prism, c'est donc toujours un compromis en fonction des cas d'utilisation (je pense que l'utilisation de plugins de rehype pour prism signifie que vous aurez plus de mal à intégrer quelque chose comme react-live , par exemple)

gatsby-remarque-prismjs et d'autres plugins gatsby-remarque- * ont été publiés dans la version 0.1.1 aujourd'hui, il y a donc maintenant au moins 3 options pour la coloration syntaxique entre rehype / remarque / react-components 😝