web-dev-qa-db-fra.com

Combiner réactif et jade

Je travaille sur une application javascript isomorphe avec express + react. Nous avons commencé à utiliser du jade pour les modèles côté serveur pour le contenu statique, mais la combinaison des deux devient rapidement difficile à gérer. Nous nous sommes retrouvés avec quelque chose comme ça:

Dans les routes express:

router.get("/", function(req, res) {
  var webpackStats = require('../../config/webpack-stats.json');
  var reactHtml = React.renderToString(HiwApp({}));
  var slideshowHtml = React.renderToString(slideshowApp({}));
  var config = {
    webpackStats: webpackStats,
    reactOutput: reactHtml,
    slideshowHtml: slideshowHtml
  };
  res.render("how_it_works/howitworks", config);
});

En Jade:

body
  .company-logo.center
  #react-main-mount
    != reactOutput
  include ./content_block_1.jade

  include ./content_block_2.jade

  #slideshow-main-mount
    != slideshowHtml

C'est très fragile - si nous voulons jsx puis un modèle jade puis plus jsx, nous devons nous assurer que nous obtenons la bonne commande.

Mon idée est de le faire tous avec jsx. Je sais qu'il y a React.renderToStaticMarkup pour ce genre de chose, mais cela ne résout pas le problème du mélange de pages dynamiques avec des pages statiques.

Les grandes questions: si nous décidons de faire tout cela avec jsx (disons layout.jsx qui contient tous les composants), puis appelons React.renderToString(App({});, cela sera-t-il un gros problème de performances? Si oui, existe-t-il une meilleure façon de le faire pour combiner facilement des blocs statiques et dynamiques?

javascriptnode.jsexpresspugreactjs
23
johnnyutah

Bien que cela puisse être un tout petit peu hors sujet: Nous sommes restés avec des modèles de jade.

Fondamentalement, nous voulions la flexibilité d'utiliser une architecture sans réaction + flux pour les zones du site quand et si ce besoin se faisait sentir. Notre site est essentiellement composé d'un certain nombre de petites applications SP: Site, UserAccount, Team et Admin.

Pourquoi avons-nous fait cela?

  • Taille de fichier plus petite et frais généraux pour les utilisateurs qui n'accèdent pas à toutes les sections du site.

  • Option de "désinscription" de React et flux si et quand le besoin s'en fait sentir.

  • Authentification plus simple côté serveur.

6
AndrewMcLagan

Nous avons réussi à rendre un modèle de shell JSX (Html.jsx) Sur le serveur à l'aide de React.renderToStaticMarkup(), puis à l'envoyer comme réponse à chaque demande de route express côté serveur qui est destiné à fournir du HTML au navigateur. Html.jsx Est juste un Shell contenant des informations de tête html et GA scripts etc. Il ne doit contenir aucune disposition.

// Html.jsx
render(){
  return (
    <html>
      <head>
        // etc.
      </head>
      <body>
        <div
          id="app"
          dangerouslySetInnerHTML={{__html: this.props.markup}}>
        </div>
      </body>
      <script dangerouslySetInnerHTML={{__html: this.props.state}</script>
      <script>
        // GA Scripts etc.
      </script>
    </html>
  )
}

N'oubliez pas qu'il est tout à fait correct et même recommandé d'utiliser dangerouslySetInnerHTML sur le serveur lors de l'hydratation de votre application.

La mise en page dynamique doit être effectuée avec vos composants isomorphes via une hiérarchie de composants basée sur leur configuration d'état/accessoires. S'il vous arrive d'utiliser le routeur React, votre routeur affichera les gestionnaires de vues en fonction des routes que vous lui fournissez, ce qui signifie que vous n'avez pas besoin de gérer cela vous-même.

La raison pour laquelle nous utilisons cette technique est de séparer architecturalement notre "App" qui est isomorphe et répond à l'état de notre modèle côté serveur Shell qui n'est qu'un mécanisme de livraison et est en fait une plaque de chaudière. Nous conservons même le modèle Html.jsx Parmi tous les composants express de notre application et ne le laissons pas se mélanger avec les autres composants isomorphes React.

L'une des ressources les plus utiles que j'ai trouvées pour travailler sur l'architecture React/isomorphic était https://github.com/yahoo/flux-examples/tree/master/react-router qui est l'endroit où nous avons volé ce technique de.

Nous avons exploré l'idée d'intégrer le guidon comme moteur de modélisation pour les développeurs des clients utilisant nos produits à l'avenir, mais avons décidé qu'il était moins complexe d'écrire notre propre DSL dans JSX et d'utiliser des routines d'analyse simples pour analyser notre DSL de type HTML vers JSX par ajouter des choses comme export default (syntaxe du module ES6) au début du modèle, puis importer le modèle dans un composant de rendu.

Vous pouvez bien sûr suivre cette ligne de pensée et utiliser un compilateur jade pour cracher le modèle, puis ajouter la syntaxe du module autour de cela si vous pensez que des fichiers jade distincts sont essentiels. J'ai également remarqué ce projet même si je ne l'ai pas exploré avec colère: https://github.com/jadejs/react-jade .

2
rickard