Gatsby: Créer des applications avec gatsby.js: quels sont les inconvénients?

Merci pour vos commentaires, @barbush. Je n'avais pas réalisé que 68 mots seraient trop.

Le titre dit essentiellement tout: Quels sont les inconvénients lorsque je crée une application avec gatsby.js?

Je sais qu'il est possible de créer une application. Ma question est - comme gatsby.js est optimisé pour la génération de sites Web statiques - quels sont les inconvénients? Y a-t-il quelque chose qui va me mordre le cul plus tard?
Cela me semble assez spécifique.

Woah woah woah @barbush Je ne veux vraiment pas que vous contrôliez des questions comme celle-ci. Si c'est une question terrible (ce qui n'est pas le cas), il est préférable de l'ignorer puis de dire à la personne de partir. Veuillez ne plus répondre à des questions comme celle-ci.

@bolus à votre question. Gatsby est conçu pour être assez similaire pour créer une application de réaction et d'autres configurations Webpack / react. Il est donc parfaitement capable d'être utilisé pour créer des applications Web. Si vous regardez dans le répertoire des exemples, il y a un exemple de redux. Les gens l'ont utilisé avec Apollo avec succès. Relay n'est pas possible à utiliser avec gatsby car notre utilisation de graphql est en conflit avec la leur, mais je suis presque sûr que ce sera facile à contourner à l'avenir.

Le principal inconvénient que je connais est qu'il suppose que vous construisez des "pages", donc si vous construisez davantage une application directe sans pages, cela ne vous donne pas grand-chose et limiterait également quelque peu votre liberté. Dans ce cas, vous feriez mieux d'utiliser une configuration plus vanille comme CRA.

Mais si vous créez des "pages", gatsby est génial car vous obtenez le fractionnement automatique du code et le SSR statique pour un démarrage rapide de l'application.

J'adorerais écrire un document de compromis plus formel à un moment donné, mais je serai heureux de répondre aux questions ici en attendant.

@KyleAMathews : Merci, c'est exactement ce que je cherchais.

Je prévois de créer un site Web axé sur le contenu (un blog, des pages de vente, de la documentation, etc.) et pour plus de simplicité, j'aimerais héberger quelques petites applications d'une seule page sur le même domaine.

On dirait que Gatsby est idéal pour cela.

limiterait aussi quelque peu votre liberté

Ce n'est probablement pas un problème pour mon cas d'utilisation, mais pouvez-vous me dire à quelles limites je peux m'attendre et à quel point il serait difficile de les contourner?

Merci d'avoir créé Gatsby, btw., Gatsby a l'air vraiment génial! :)

mais pouvez-vous me dire à quelles limites je peux m'attendre et à quel point il serait difficile de les contourner?

Gatsby essaie d'être aussi simple et modeste que possible, vous ne devriez donc probablement pas rencontrer de limitations, d'autant plus que vous créez des sites Web de contenu / page, ce pour quoi Gatsby est conçu.

Gatsby est conçu pour mélanger des idées d'applications Web et de sites afin de créer ce qui est dans notre esprit l'outil de développement et de production idéal pour créer des sites vraiment rapides aussi facilement que possible.

Vous ne rencontrerez des problèmes que si vous souhaitez utiliser React de manière à sortir du modèle de «page» - par exemple, plus d'applications de forme libre. Mais même là, Gatsby a une trappe d'échappement qui vous permet d'intégrer facilement des applications dans un site plus grand https://www.gatsbyjs.org/docs/creating-and-modifying-pages/#creating -client-only-routes

Ça a l'air parfait, merci encore!

salut @KyleAMathews et @bolus

commenter ici bc du contexte au lieu d'ouvrir un nouveau numéro heheh

que se passe-t-il si à l'intérieur de mon /app (c'est une route réservée au client), je veux créer un SPA (connexion / déconnexion / tableau de bord), je suppose que je dois créer un nouveau routeur à l'intérieur, est-ce correct?

que recommandez-vous dans ce cas d'utilisation @KyleAMathews , est-ce possible? ou serait-il préférable d'utiliser une _approche plus vanille_ comme vous l'avez dit?

Je vous remercie

@fernandes checkout https://www.gatsbyjs.org/docs/creating-and-modifying-pages/#creating -client-only-routes - faites-nous savoir si vous avez d'autres questions!

salut, @KyleAMathews merci pour la réponse rapide

J'ai joué avec Gatsby tout le samedi, j'ai vérifié cet exemple et en redux un ... Désolé de ne pas me rendre si brillant, j'aurais pu donner plus d'informations à ce sujet

Ce que j'essaie de faire, récupérez mon: https://github.com/fernandes/react-boilerplate et placez-le dans /app tant que chemin client uniquement

ce passe-partout est composé de:
react / redux (avec rechargement à chaud) / react router redux

Je n'ai pas tellement d'expérience avec JS; c'est peut-être juste un détail qui me manque .. merci encore!

Vous ne pouvez pas mettre Gatsby dans quelque chose comme un passe-partout. Gatsby veut gérer la construction et exécuter le site. Au lieu de cela, mettez des parties "app" dans Gatsby.

ouais, c'est ce que je voulais dire ... gatsby gère tout mon site Web et ses pages, et react-boilerplate entre dans gatsby sous /app tant que route réservée au client ... est-ce possible (compte tenu sa pile, spécialement le react-router-redux)?

Gatsby gère déjà toute la configuration webpack / Babel / other, donc le projet bootstrap n'est pas nécessaire.

@KyleAMathews Je trouve comment faire fonctionner mon application client uniquement avec le client redux + apollo .. merci beaucoup pour les réponses 😉 👍

@KyleAMathews Je suis confronté à un petit problème ici, j'utilise le client graphql apollo dans mes pages client uniquement, mais ils sont juste pour le côté client (une fois que vous devez être connecté), mais Gatsby essaie de générer le fichier d'index à la construction; ce qui, bien sûr, donne une erreur

une suggestion sur la façon de sauter cette création HTML ?

mettre à jour:
J'utilise https://www.gatsbyjs.org/packages/gatsby-plugin-create-client-paths/

J'ai créé un plugin qui deletePage basé sur page.path , il fonctionne parfaitement ... je ne sais pas si c'est le meilleur moyen, mais il fonctionne pour mon cas d'utilisation 😄 (oui, maintenant je dois créer une règle de redirection sur nginx pour toujours envoyer à mon app/index.html , mais c'est exactement ce que j'ai fait avec mon application précédente ...

Je m'habitue de plus en plus à gatsby, et je dois avouer que je suis plus heureux de chaque progrès que je fais ... travail formidable @KyleAMathews !! 👏

@KyleAMathews Je suis désolé de vous déranger ici, mais cela semble être un bon endroit pour poser des questions sur le routage côté client car je n'ai pas été en mesure de comprendre.

Donc, pour mon cas d'utilisation, je lis les données de Firebase mais ces données ne sont pas TOUTES disponibles au moment de la construction, car les utilisateurs peuvent les modifier.

Donc, dans une page Gatsby (ex: / podcasts), je peux facilement interroger les données de Firebase dans cDM. Mais ensuite, j'aimerais aller à la page de détails (ex: / podcast /: id) et c'est là que je me perds un peu. Dois-je essayer de déléguer cette route au routage côté client?

Si je comprends bien, l'idée de l'écoutille /app scape est d'avoir un endroit où vous pouvez simplement avoir un SPA en dessous, mais cela semble excessif pour ce que j'essaie de faire.

Merci pour votre travail chez Gatsby, ça a été une super expérience tout autour :)

@gafemoyano créer un itinéraire pour /podcast/:id tout à fait logique s'il y a des podcasts créés par les utilisateurs pendant qu'ils travaillent sur des choses. Un inconvénient est que cela ralentit le TTFP pour les personnes qui visitent directement les pages de podcast, car il y a maintenant du HTML rendu par le serveur à charger pour elles. Vous pourriez peut-être faire un hybride aussi - rendre statiquement les pages de podcast qui existent à la construction, puis en créer plus à la volée dans le navigateur au fur et à mesure que les gens les créent.

D'intérêt pour ceux qui sont sur cette page - j'ai rédigé cette nouvelle page de documentation sur la création d'applications avec Gatsby https://www.gatsbyjs.org/docs/building-apps-with-gatsby/

hey @KyleAMathews car cela est devenu le "problème côté client" officiel hahah une autre chose que j'ai envisagée sur ce problème de podcast, étant donné que nous contrôlons à la fois le frontend et le backend des podcasts, existe-t-il un moyen de déclencher la reconstruction d'une page spécifique uniquement ? ou simplement mettre en cache la construction et changer simplement ce qui a été modifié. Je ne sais pas comment cela pourrait fonctionner

possible lié à https://github.com/gatsbyjs/gatsby/issues/3444

vous avez commenté une API de cache clé / valeur à stocker sur https://github.com/gatsbyjs/gatsby/issues/3260#issuecomment -352856214, peut-être si nous avons la mise en page + le contenu de la page pour nous assurer que rien n'a changé (sur les données et visuel)

@KyleAMathews Merci pour votre réponse! Alors laissez-moi voir si je comprends bien. L'approche consiste à déléguer un chemin d'accès au code client à rendre, non? Je ne devrais donc pas essayer de définir mes routes statiquement dans gatsby-node.js comme:

` // page.matchPath is a special key that's used for matching pages
  // only on the client.
  if (page.path.match(/^\/podcasts/:id/)) {
    page.matchPath = "/podcasts/:id";

    // Update the page.
    createPage(page);
  }

Mais utilisez plutôt simplement ce qui est montré dans l'exemple:

''
// page.matchPath est une clé spéciale utilisée pour les pages correspondantes
// uniquement sur le client.
if (page.path.match (/ ^ / app /)) {
page.matchPath = "/ app /: chemin";

// Update the page.
createPage(page);

}

And on app/index.js I would define my routes by importing from ReactRouter directly:

importer {Switch, Route} depuis 'react-router-dom'
const AppIndex = () => (

Ce qui me permettrait de visiter / app / podcasts /: id et de rendre PodcastDetails où pourrait accéder à la partie: id du chemin pour récupérer les données dans le composant?

Désolé de vous avoir dérangé avec un scénario aussi simple, je n'ai tout simplement pas pu le comprendre avec les exemples existants. Peut-être devrions-nous inclure un exemple pour les applications hybrides si c'est une chose assez courante que les gens font avec Gatsby? Je serais prêt à vous aider si nécessaire.

Merci encore pour votre temps à construire et à soutenir cette bibliothèque @KyleAMathews .

La partie app du chemin dans l'exemple est arbitraire. Vous pouvez utiliser le nom dont vous avez besoin, par exemple podcasts .

Un exemple de site serait génial :-) j'espère avoir le temps bientôt. Invitez toute autre personne qui a déjà résolu ce problème à partager un exemple de code!

J'ai essayé et j'ai un exemple de code ici

Mais j'ai encore quelques problèmes.
Celui que j'ai décrit ici
En bref, lorsque je construis pour la production et que j'entre dans une route sous le répertoire /app/ , par exemple localhost:9000/app/posts/1 et que je rafraîchis le navigateur, j'obtiens une page vierge 404.
Lorsque j'actualise la page en localhost:9000/app/ cela fonctionne bien.
Peut-être que ma configuration prefixes pour le gatsby-plugin-create-client-paths est fausse.

module.exports = {
  ...
  plugins     : [
    {
      resolve: `gatsby-plugin-create-client-paths`,
      options: {prefixes: [`/app/*`]},
    },
    ...
};

Et un autre problème est (pas sûr que ce soit un problème) je ne peux pas envelopper mes <Route /> avec <BrowserRouter> .
Quand je construis pour la production (le développement fonctionne bien), je reçois un message d'erreur disant "L'historique du navigateur a besoin d'un DOM", je crois que c'est parce que Gatsby fonctionne dans un environnement Node et qu'il n'a pas de navigateur donc n'a pas de window etc.

Enfin, j'ai supprimé le wrap <BrowserRouter> et cela fonctionne très bien.
Je suis nouveau sur React, donc je ne suis pas sûr que ce soit la solution appropriée au problème.

J'adorerais avoir de l'aide :)

@danielemesh Salut Daniel. Je n'ai pas eu le temps de recommencer à travailler sur mon application gatsby, mais ce que je peux voir à partir de votre code source, c'est que vous avez placé le répertoire /app/* dans /pages .
Je ne suis pas sûr de savoir où il doit aller, j'essaierais de le mettre dans le répertoire src/ .

Laissez-moi savoir si cela fonctionne!

À votre santé!

@gafemoyano a essayé, n'a pas fonctionné :(
Gatsby ne le reconnaîtra pas.

Merci!

J'ai fait face à des plugins alors j'ai décidé d'écrire le mien (100% emprunté à l'original), pour que je puisse, heureusement, résoudre mon problème et apprendre à écrire des plugins gatsby

J'ai extrait d'une application, j'espère que cela aidera à résoudre vos problèmes, le problème a été rencontré bc à l'intérieur de app a des requêtes graphql qui ne devraient pas être gérées sur SSR, juste un navigateur

@KyleAMathews qu'entendez-vous par exemple de site? tu veux ajouter quelque part? Je peux travailler dessus.

gatsby-config.js

plugins: [
    `app-layout`, // I set my layout
    {
      resolve: `app-client-only`, // I handle app pages
      options: { prefixes: [`/app/*`] },
    },
  ],

plugins / app-layout / gatsby-node.js

// Implement the Gatsby API “onCreatePage”. This is
// called after every page is created.
exports.onCreatePage = ({ page, boundActionCreators }) => {
  const { createPage } = boundActionCreators;

  if (page.path.match(/^\/app/)) {
    // It's assumed that `app.js` exists in the `src/layouts/` directory
    page.layout = "app";
  }

  return true;
};

plugins / app-client-only / gatsby-node.js

// Prefixes should be globs (i.e. of the form "/*" or "/foo/*")
const validatePrefixEntry = prefix => {
  if (!prefix.match(/^\//) || !prefix.match(/\/\*$/)) {
    throw Error(
      `Plugin "gatsby-plugin-client-only-paths" found invalid prefix pattern: ${
        prefix
      }`
    )
  }
}

exports.onCreatePage = ({ page, store, boundActionCreators }, { prefixes }) => {
  const { createPage, deletePage } = boundActionCreators
  const re = {}
  prefixes.forEach(validatePrefixEntry)

  return new Promise(resolve => {
    // Don't set matchPath again if it's already been set.
    if (page.matchPath || page.path.match(/dev-404-page/)) {
      resolve()
    }

    prefixes.some(prefix => {
      if (!re[prefix]) {
        // Remove the * from the prefix and memoize
        const trimmedPrefix = prefix.replace(/\*$/, ``)
        re[prefix] = new RegExp(`^${trimmedPrefix}`)
      }

      // Ensure that the path ends in a trailing slash, since it can be removed.
      const path = page.path.match(/\/$/) ? page.path : `${page.path}/`

      if (path.match(re[prefix])) {
        page.matchPath = prefix.replace(/\*$/, `:path`)
        if (path != '/app/') {
          // <<<<<<<<<<<<<<<<< here is my modification >>>>>>>>>>>>>>>>>>>>>>>
          // do not try to process on SSR, user needs to be logged to
          // consume GraphQL API and render `app` pages correctly
          deletePage(page)
          // <<<<<<<<<<<<<<<<< here is my modification >>>>>>>>>>>>>>>>>>>>>>>
        }
        // createPage(page)
        return true
      }

      return false
    })

    return resolve()
  })
}

Donc, je ne suis pas sûr si ce problème est 100% lié à @KyleAMathews , mais quoi que je fasse, mon chemin d'accès client uniquement 404s initialement, puis il commence le chargement (et les utilisateurs partent avant de commencer le chargement)

pages / app / index.js:

import CreateSchedule from './components/CreateSchedule'
import ViewSchedule from './components/ViewSchedule'
...
  <ApolloProvider client={client}>
        <Provider store={store}>
          <Switch>
            <Route exact path="/app" component={CreateSchedule} />
            <Route path="/app/:id" component={ViewSchedule} />
          </Switch>
        </Provider>
      </ApolloProvider>

gatsby-node.js

exports.onCreatePage = async ({ page, boundActionCreators }) => {
  const { createPage } = boundActionCreators

  // page.matchPath is a special key that's used for matching pages
  // only on the client.
  if (page.path.match(/^\/app/)) {
    page.matchPath = '/app/:path'

    // Update the page.
    createPage(page)
  }
}

J'ai aussi essayé le plugin gatsby-plugin-create-client-paths sans chance.

Mon composant CreateSchedule fonctionne correctement sans 404ing: https://www.appointmentscheduler.org/app

Le problème se trouve dans la route / le composant ViewSchedule: https://www.appointmentscheduler.org/app/1b42d8e8-66b5-4a8d-a0b5-fd4bb13bed09

Oh et le 404 ne se produit qu'une fois construit - le serveur de développement n'a pas ce problème

Des idées?

@rozenmd Vous avez besoin d'un routage de serveur pour cela. Si vous utilisez netlify, vous pouvez installer gatsby-plugin-netlify et cela générera automatiquement la configuration de routage du serveur (je vois que vous avez netlify-identity-widget - je ne sais pas si cela signifie exactement que vous l'utilisez pour servir votre site)

Impressionnant!
Merci @pieh!
On dirait que le démarreur netlify que j'ai utilisé (https://github.com/konsumer/gatsby-starter-bootstrap-netlify) n'avait pas 'gatsby-plugin-netlify' dans gatsby-config.js

L'ajout et le déploiement ont résolu ce problème 😄

@KyleAMathews un problème supplémentaire potentiellement

@ cf73 avez-vous essayé de pointer votre DNS GoDaddy vers quelque chose de plus approprié pour Gatsby comme Netlify?

@rozenmd pour clarifier, le CMS sans tête drupal est hébergé sur GoDaddy; le site Gatsby fonctionne toujours localement. donc à moins que je ne vous ai mal compris, je ne vois pas comment Netlify pourrait vous aider?

@ cf73 https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-drupal/src/gatsby-node.js pourrait probablement utiliser une sorte de file d'attente (nous utilisons better-queue dans d'autres endroits) au lieu de Promise.all pour limiter les requêtes simultanées à quelque chose de plus gérable. Pensez-vous pouvoir le mettre en œuvre?

@pieh oui j'ai vu l'utilisation de better-queue, ça sonne comme une solution décente. peur de ne pas le faire moi-même - je suis tombé ici en essayant de résoudre l'erreur 503 pour un gros projet client sur lequel je travaille, pour lequel j'aimerais utiliser Gatsby. les délais sont serrés, donc s'il n'y a pas de solution pour cela dans les prochaines heures ou tout au plus le jour suivant, je vais devoir chercher une autre approche. Quelqu'un peut-il suggérer ce que je pourrais faire instantanément (y compris le changement d'hébergement si nécessaire) pour résoudre ce problème? existe-t-il un flux de travail Drupal + Hosting + Gatsby éprouvé?

@ cf73 Je vous ressens des délais - si vous pouviez partager la configuration de votre site drupal, j'aurais donc un site pour tester les modifications (soit publiquement ici ou en privé sur discord - https://discordapp.com/invite/0ZcbPKXt5bVoxkfV avec PM à moi - mon manche est grajen3), je verrais si je peux le faire moi-même aujourd'hui

@pieh ce serait incroyable, merci !!

@KyleAMathews Je suis confronté à un problème désespéré en travaillant sur un site client, ce qui, j'en suis sûr, est facile, mais il me manque quelque chose. Stack est l'API Drupal JSON du graphiql de Gatsby. Cela ne me permet pas de passer des arguments aux nœuds (voir ci-joint). Pour autant que je sache, c'est parce que le schéma Drupal de Gatsby n'est pas complètement étoffé? Ou est-ce que je manque une étape? Toute aide urgente et BEAUCOUP appréciée !!

La requête doit être:

NodeArticle(id: { eq: GUID }) {
  id
  ...otherFields
}

Vous pouvez également filtrer allNodeArticle par l'identifiant, mais si vous ne sélectionnez qu'une seule chose, il est plus simple d'interroger directement NodeArticle .

@KyleAMathews merci beaucoup! Pouvez-vous m'indiquer la documentation où cela est couvert? Je n'ai pas rencontré cela jusqu'à présent ... est-ce unique à la façon dont Gatsby parle avec Drupal, ou à un comportement standard de base de GraphQL que je viens de manquer? Cela pourrait être une idée de promouvoir plus visiblement toute documentation spécifique à la source comme celle-ci aux côtés du plugin source?

Il s'agit de la fonctionnalité principale de Gatsby (filtrage effectué au niveau de la requête racine), pas spécifique à Drupal. Les plugins sources ne peuvent pas définir le schéma graphql - c'est la tâche que Gatsby Core effectue sur la base des données "brutes" fournies par les plugins.