Next.js: Minimales Apollo-Beispiel

Einige Beobachtungen: Dieser Ansatz geht nicht tief in die Komponenten ein, um alle Graphql-Abfragen zu laden, auf die er stößt (etwas, das Sie serverseitig mit React-Apollo aktivieren können).

Ich glaube, das ist bei next.js ein bisschen problematisch: Sie sind nicht wirklich dazu gedacht, Daten tief in die Komponentenhierarchie zu laden - wenn Sie möchten, dass dies sowohl auf der Client- als auch auf der Serverseite geschieht. Es gibt nur einen Punkt, um die Daten zu laden: in getInitialProps in der Root-Komponente. Ich weiß nicht, ob sich das in Zukunft ändern wird, aber wenn nicht, dann müssen wir es tun

1. unsere Apps so zu gestalten, dass wir von Anfang an alle relevanten Daten für eine Seite laden, oder
2. ein Teil der Daten nur auf dem Client (nämlich alles, was wir nicht in getInitialProps laden), mit einer anderen Strategie

In beiden Fällen sollte der obige Ansatz für die Daten, die in getInitialProps geladen werden, in Ordnung sein.

Und wenn es einem Core-Entwickler gefällt, kann ich mit dem Beispiel einen Pull-Request erstellen.

Informationen zu getInitialProps, die nur von Root aufgerufen werden, finden Sie unter https://github.com/zeit/next.js/issues/192. Würde gerne eure Ideen dort haben.

@sedubois , auf welche Probleme hattest du react-apollo ?

@nmaro Ihr https://github.com/nmaro/apollo-next-example ist leer.

@amccloud sollte besser @nmaro danach fragen (ich muss noch in den Code zurückkehren).

Danke @sedubois , es ist jetzt online (vergiss immer, beim ersten Mal push origin master statt nur push auszuführen).

Hoppla, ich habe die falsche Person erwähnt. @nmaro welches Problem hattest du mit React-Apollo?

Die Daten wurden in den Server geladen, sobald der Client mit dem Laden begann, war die Seite wieder leer. Ich habe mir dann die Implementierung von @sedubois angesehen (https://github.com/RelateMind/relate) und dachte, dass sie für einen schnellen Proof-of-Concept schon ziemlich komplex ist, also habe ich es schließlich mit der untergeordneten API versucht.

@stubailo , da Sie sich gefragt haben, warum es so schwierig ist, Apollo mit next.js zu integrieren - es sieht so aus, als ob der einzige Ort, an dem Sie Daten sowohl auf dem Client als auch auf dem Server abrufen können, die Stammkomponente der Seite innerhalb einer asynchronen Funktion namens getInitialProps ist. Ich denke, die übliche Art, React-Apollo zu integrieren, wäre nur auf der Client-Seite sinnvoll.

Interessant - gibt es noch andere Datenintegrationen mit Next.js? Es sieht so aus, als ob die Verwendung von Redux auch ziemlich schwierig ist, basierend auf den Beispielen, die ich gesehen habe.

Die meisten modernen Datensysteme haben eine Art globalen Cache (Redux, Apollo, Relay), daher muss es meiner Meinung nach in Next eine Art Einrichtung geben, um dies zu ermöglichen.

Wie können wir Next.js mit modernen Datensystemen mit einem globalen Cache (Redux, Apollo, Relay) besser spielen lassen? Ich denke, dass dies eine große Priorität für die nächste Veröffentlichung sein sollte. @stubailo @rauchg

Absolut. Wir haben ein Redux-Beispiel im Wiki, wir müssen mehr davon erstellen :)

Es ist übrigens nichts, was wir auf Veröffentlichungsbasis tun müssen. Wir können einfach jederzeit ein Wiki-Tutorial schreiben.

Übrigens @nmaro , dieses Beispiel sieht wirklich gut aus, danke für deinen Beitrag. Das können wir als Basis nehmen und erweitern

Oh, seltsam - ich habe die damit verbundenen Probleme nicht erkannt. @nmaro was macht React-Apollo die Dinge schwierig? Es scheint, als sollten Sie in der Lage sein, dem Redux-Beispiel fast genau zu folgen, aber machen Sie new ApolloClient , wo dies createStore verwendet, und verwenden Sie ApolloProvider anstelle von Provider .

Ich würde gerne mit jemandem zusammenarbeiten, um ein Minimalbeispiel zu erstellen. Dies ist unser „Hello World“-Beispiel für React, es wäre großartig, einen Port für Next.js zu haben: https://github.com/apollostack/frontpage-react-app

@stubailo Ich würde gerne mit dir an einem Minimalbeispiel arbeiten. Ich habe das universelle Apollo-Mikroframework Saturn für ein paar Projekte verwendet und würde es liebend gerne auf Next.js + Apollo portieren :)

Schön - ja, nur minimale Änderungen an der Frontpage-App vorzunehmen, damit sie auf next.js statt auf create-react-app läuft, wäre meine Präferenz. dann können wir es auch auf unserer Homepage auflisten!

@stubailo

Ein kleines Problem war, dass Daten auf den Server geladen und gerendert wurden, nur um beim Laden auf dem Client durch nichts ersetzt zu werden - ich glaube, ich kenne Apollo und Next nicht genug, um es richtig zu machen. Bei direkter Verwendung von Apollo-Client hatte ich dieses Problem nicht.

Schwieriger wird es beim Server-Rendering, wenn Sie Abfragen tiefer in der Hierarchie haben. React hat keine Möglichkeit, Dinge asynchron zu rendern, dh zu warten, bis jede Komponente bereit ist, bevor sie gerendert wird. Was bedeutet, dass ein SSR-Framework entweder muss

1. Gehen Sie zweimal durch den gesamten Komponentenbaum, einmal zum Laden der Daten und einmal zum Rendern.
2. Stellen Sie einen asynchronen Einstiegspunkt im Stamm bereit - dies ist der Ansatz von next.js mit getInitialProps

Nun stellt sich die Frage, ob Apollo eine Möglichkeit hat, alle Datenaufrufe zu erkennen, die zum Rendern eines Komponentenbaums erforderlich sind, und dies alles in einem Funktionsaufruf zu tun, der getInitialProps bereitgestellt werden kann.

@stubailo Gibt es dafür eine Lösung? ^

@nmaro @ads1018 hast du getDataFromTree gesehen? Wie zB in meinem Beispiel verwendet: https://github.com/RelateMind/relate/blob/master/hocs/apollo.js

Übrigens frage ich mich, ob die Dinge jetzt vereinfacht werden können, da https://github.com/zeit/next.js/pull/301 zusammengeführt wird. Habe das noch nicht recherchiert.

@sedubois Ich habe das überprüft, danke fürs Teilen! Ja, ich kann mir vorstellen, dass Ihr Beispiel mit „react-apollo“ mit der neuen programmatischen API (#301) vereinfacht werden kann, die gerade in Master integriert wurde, sodass Sie nicht alle Seitenkomponenten mit Ihrem eigenen HOC umschließen müssen. Wenn Sie diesbezüglich Fortschritte machen, lassen Sie es mich bitte wissen! Wäre cool ein next.js Beispiel auf der Apollo Homepage zu bekommen :)

NB @ads1018 https://github.com/zeit/next.js/pull/301 befasst sich mit dem Extrahieren von allgemeinem Code mit CommonsChunkPlugin, nicht mit der Programmatic API. Aber ja, die programmatische API wird definitiv auch helfen, und ich freue mich darauf, sie veröffentlichen zu können.

Hat jemand Glück gehabt, React-Apollo mit der neuen Version 2.0.0-beta.2 zum Laufen zu bringen?

@sedubois @stubailo Ich habe meinen Versuch von next+react-apollo hochgefahren, falls du mal schauen willst. Sie finden es hier: https://github.com/ads1018/frontpage-next-app

Ein Problem, mit dem ich gerade konfrontiert bin, ist, dass Komponenten nur clientseitig und nicht serverseitig gerendert werden. Vielleicht können wir die getDataFromTree -Methode von respond-apollo in server.js verwenden? Oder vielleicht in unserem eigenen <document> ? Anregungen/Pull-Requests sind willkommen!

Würde dieses Hallo-Welt-Beispiel gerne irgendwann in den Next-Beispiele-Ordner und die Apollo-Homepage aufnehmen.

Die einzige Voraussetzung für das Server-Rendering der Daten ist, dass sie als Objekt in getInitialProps zurückgegeben werden, Überschreibungen sind nicht erforderlich.

Erwischt. Ich denke, das ist mit React-Apollo etwas schwierig, denn wie @nmaro betonte:

Die Frage ist, ob Apollo eine Möglichkeit hat, alle Datenaufrufe zu erkennen, die zum Rendern eines Komponentenbaums erforderlich sind, und dies alles in einem Funktionsaufruf zu tun, der getInitialProps bereitgestellt werden kann.

Erwischt

@ads1018 Wenn die Komponente der obersten Ebene auf getInitialProps verfügbar gemacht wurde, könnte sie nach ein wenig Herumstöbern mit dem Apollo -Hilfsprogramm in eine Zeichenfolge gerendert werden.

Das _document würde dann etwa so aussehen:

export default class MyDocument extends Document {
  static async getInitialProps ({ app }) {
    const wrapped = React.createElement(ApolloProvider, { client }, app)
    const rendered = await renderToStringWithData(wrapped)
    return { html: rendered, initialState: client.store.getState() }
  }

  render () {

    return (
      <html>
        <Head>
          <title>My page</title>
        </Head>
        <body>
          <ApolloProvider client={client}>
            <Main />
          </ApolloProvider>
          <NextScript />
        </body>
      </html>
    )
  }
}

@rauchg Es scheint eine einfache Änderung zu sein, app zusätzlich zu renderPage freizulegen, aber gibt es etwas, das ich übersehe?

@bs1180 ah genial. Das habe ich gesucht. Hoffentlich ist es eine einfache Änderung, app zu machen. Es würde Next sofort zu einem graphql-clientfreundlichen Framework machen.

@bs1180 Ich habe app innerhalb des Rückgabeobjekts renderPage exponiert. Stimmt das mit dem überein, was Sie dachten?

@ads1018 Nicht ganz - in Ihrer Version wird immer noch render aufgerufen, was eine unnötige Duplizierung wäre, wenn renderToStringWithData manuell aufgerufen wird.

Ich habe noch etwas daran gearbeitet und mein Endergebnis ist nicht annähernd so hübsch, wie ich es mir zuerst vorgestellt hatte, vor allem, weil die Haupt-App als untergeordnete Komponente der <Main /> -Komponente (in das __next div) gerendert wird, was durchbrennt verhindern, dass jeglicher Kontext von oben an Ihre Anwendung weitergegeben wird. Es wird also immer noch ein HOC benötigt, um den Apollo-Kontext erneut hinzuzufügen.

@ bs1180 Ich verstehe. Ist es möglich, <Main /> als untergeordnetes Element von ApolloProvider , damit wir den Kontext weitergeben können?

Ich bin mir nicht sicher, was du meinst, aber ich denke, es ist die falsche Richtung. Perfektes SSR kann mit nur einem HOC erreicht werden - hier ist meine zusammengeschusterte Version als Ausgangspunkt:

export default (options = {}) => Component => class ApolloHOC extends React.Component {
  static async getInitialProps (ctx) {
    const user = process.browser ? getUserFromLocalStorage() : getUserFromCookie(ctx.req)
    const jwt = process.browser ? null : getJwtFromCookie(ctx.req)

    if (options.secure && !user) {
      return null // skip graphql queries completely if auth will fail
    }

    const client = initClient(jwt)
    const store = initStore(client)

   // This inserts the context so our queries will work properly during the getDataFromTree call,
   //  as well as ensuring that any components which are expecting the url work properly 
    const app = React.createElement(ApolloProvider, { client, store },
      React.createElement(Component, { url: { query: ctx.query }}))

 // this is the most important bit :)
    await getDataFromTree(app)

    const initialState = {[client.reduxRootKey]: {
      data: client.store.getState()[client.reduxRootKey].data
    }}

    return { initialState, user }
  }

  constructor (props) {
    super(props)
    this.client = initClient()
    this.store = initStore(this.client, this.props.initialState)
  }

  render () {
    return (
      <ApolloProvider client={this.client} store={this.store}>
          <Component url={this.props.url} />
      </ApolloProvider>
    ) 
  }
}

Die initClient und initStore sind dem Redux-Beispiel nachempfunden. Jede Seite sieht dann so aus:

import ApolloHOC from '../hoc'
import { graphql } from 'react-apollo'

export default ApolloHOC({ secure: false })(() => <b>Hello world</b>)

Hoffe, das ist nützlich - ich würde gerne wissen, ob es andere Möglichkeiten gibt, nachzuforschen, oder etwas, das ich übersehe.

@bs1180 Cool, das ist super nützlich, danke fürs Teilen.

Gibt es noch etwas, was wir tun können, um Seiten mit graphql-Daten innerhalb _document.js zu rendern? Es wäre schön, wenn wir diese HOC alle zusammen umgehen könnten, wie Sie ursprünglich vorgeschlagen haben.

Ich glaube nicht - nach dem, was ich sehen kann, entfernt das clientseitige Rendern alles, was im Kontext weitergegeben wird (sei es Apollo-Client, der Standard-Redux-Store, Themen usw.) aus dem benutzerdefinierten _document.js . Obwohl ein Teil der Apollo SSR-Logik dorthin verschoben werden könnte, wird immer noch eine Art HOC/Wrapper-Komponente erforderlich sein, um die erforderlichen Objekte wieder in den Kontext einzufügen.
Jemand mit besseren Kenntnissen der Interna von next.js hat jedoch möglicherweise eine bessere Idee.

Nun, wenn Sie es schaffen, ein funktionierendes Beispiel auf die Beine zu stellen, würden Sie es gerne ausprobieren. Ich kämpfe immer noch damit, das zum Laufen zu bringen.

Ich habe ein funktionierendes Beispiel für React Apollo und Next 😄 🚀 Ich hoffe, viele von euch finden es nützlich. Sie können es hier ausprobieren: https://github.com/ads1018/next-apollo-example (Ich habe auch eine Demo mit Now bereitgestellt.)

Am Ende habe ich ein HOC in meiner Seite namens withData() verwendet, das die Seite mit ApolloProvider . Ich war anfangs abgeschreckt von der Verwendung von Anbietern auf Seitenbasis im Gegensatz zu einmal in einer einzelnen Datei, aber einige wirklich schlaue Leute haben mich davon überzeugt, dass dies für die Lesbarkeit und Skalierbarkeit besser ist. Ich denke eigentlich, dass withData(MyComponent) ganz nett aussieht und dem Leser einen guten Kontext bietet (kein Wortspiel beabsichtigt), dass eine bestimmte Seite Daten abruft.

Danke @bs1180 und @rauchg , dass sie mich in die richtige Richtung gewiesen haben. Wenn Sie dem Repo ein with-apollo -Beispiel hinzufügen möchten, lassen Sie es mich wissen und ich kann eine Pull-Anfrage erstellen.

Danke @ads1018 😊 Löst dieses Beispiel im Vergleich zu meinem Beispiel https://Relate.now.sh das Problem der Verwendung von Apollo in tief verschachtelten Komponenten (Vermeidung der Kaskade von getInitialProps)? Vielleicht sollte das Beispiel das zeigen, da es der Hauptschmerzpunkt ist. Und ich bin mir sicher, dass es sehr wünschenswert wäre, dies zum Ordner mit den Beispielen hinzuzufügen.

@sedubois Ich kann den Fehler, auf den Sie in # 192 verwiesen haben, nicht reproduzieren. Ich verwende Apollo problemlos in verschachtelten Komponenten. Wenn Sie mein Beispiel herunterziehen und in der Lage sind, es zu reproduzieren, lassen Sie es mich wissen?

Danke @ads1018 , mit den Fixes in https://github.com/ads1018/next-apollo-example/issues/2 funktioniert alles super 🎉. Ich habe auch mein Beispiel aktualisiert: https://github.com/RelateNow/relate

Gute Arbeit, @ads1018 @sedubois! Ich habe dies und #192 verfolgt, ich habe auch Prefetching/Async-Ansichten mit Apollo und Vanilla React untersucht .

Haben Sie Leistungsprobleme bei der Ausführung getDataFromTree bemerkt oder erwarten Sie Leistungsprobleme, bevor jede Seite angezeigt wird? Da diese Methode technisch gesehen den gesamten Baum rekursiv rendert, und dann, wenn getInitialProps zurückkehrt, rendert React den Baum erneut (allerdings mit Daten aus dem Cache).

Wirklich gute Lösung 👍 Ich denke, dass zweimaliges Rendern die einzige Option ist, um sicherzustellen, dass alle untergeordneten Daten zwischengespeichert werden. Ich bin nur neugierig, was Sie über die Leistung denken.

Hey @estrattonbailey – Ich habe keine Leistungsprobleme bemerkt und erwarte auch keine. Tatsächlich ist es super bissig! Was das Ausführen getDataFromTree , habe ich diesen Methodenaufruf in eine Bedingung eingeschlossen, die prüft, ob wir uns auf dem Server befinden, sodass sie immer nur aufgerufen wird, wenn ein Benutzer die App zum ersten Mal lädt, und bei allen nachfolgenden Routenänderungen umgangen wird . Sie können mit der Demo herumspielen , wenn Sie die Leistung überprüfen möchten. Bitte lassen Sie mich wissen, wenn Sie Feedback haben!

@ads1018 einige Ideen für Ihr Beispiel:

• Vereinfachen Sie initialState so
• Separate Middleware, Store und Reducer in solchen Dateien
• Vereinfache isServer zu typeof window !== 'undefined' , lösche !!ctx.req
• extrahieren Sie diese IS_SERVER-Konstante nach lib, Sie müssen sie nicht als Parameter weitergeben

@ads1018 Schön zu hören! Schöne kleine Demo.

Was ich fragen wollte, ist: Wie gut wird diese Skalierung? Obwohl ich Next noch nicht verwendet habe, ruft Next nach meinem Verständnis getInitialProps bei jedem Routenübergang auf, sofern auf einer Seitenkomponente verfügbar, dh pages/page.js . Bei einer groß angelegten App/Website mit Hunderten von Knoten und vielen eingehenden Daten stelle ich mir vor, dass das zweimalige Rendern auf jeder Route zu einer gewissen Latenz beitragen könnte.

Das Projekt, an dem ich arbeite, ist eine groß angelegte redaktionelle Website, daher hoffe ich, ein Benchmarking verschiedener Ansätze durchführen zu können, einschließlich Ihres. Würde gerne mehr auf Twitter diskutieren, wenn Sie möchten. Danke für deine Arbeit!

@estrattonbailey Gotcha. Ich kann mir vorstellen, dass es sehr gut skalieren wird. Beim anfänglichen Laden der Seite wird getInitialProps nur auf dem Server ausgeführt. Sie haben Recht, dass getInitialProps erneut auf dem Client ausgeführt wird, aber keine Daten zweimal angefordert werden, da getDataFromTree in eine Bedingung eingeschlossen ist, die prüft, ob wir uns auf dem Server befinden oder nicht.

Nebenbemerkung - Wenn Sie sich Sorgen über die anfängliche Seitenladezeit machen, weil viele Komponenten und Daten auf einer Seite angefordert werden, können Sie apollo jederzeit anweisen, bestimmte Abfragen während SSR absichtlich zu überspringen und sie an den Client auszulagern, indem Sie ssr: false übergeben.

Ich werde mich mit dir auf Twitter verbinden, wenn du weiter diskutieren möchtest :)

Sie haben Recht, dass getInitialProps erneut auf dem Client ausgeführt wird, aber es würden keine Daten zweimal angefordert, da getDataFromTree in eine Bedingung eingeschlossen ist, die prüft, ob wir uns auf dem Server befinden oder nicht.

Wichtig zu beachten: getInitialProps wird auf der Clientseite nur beim Übergang mit <Link> ausgeführt, nicht nach dem anfänglichen Laden

@ads1018 @estrattonbailey AFAIK, es gibt immer noch 2 serverseitige Renderings beim Laden der ersten Seite: getDataFromTree wird ausgeführt und rendert den gesamten Baum intern, dann wird das Rendering erneut aufgerufen, um die HTML-Antwort zu erstellen. Denken Sie nicht, ob es eine Möglichkeit gibt, dies zu vermeiden, aber ich denke, dass es dank der von SSR vermiedenen Netzwerk-Roundtrips immer noch recht leistungsfähig ist.

Ich denke, die Leistung ist maximal, wenn der GraphQL-Server auf demselben Computer wie der Next.js-Server gehostet wird, also könnten Sie das immer versuchen, wenn Sie sich Sorgen um die Leistung machen würden (an diesem Punkt prototypiere ich meine App mit Graphcool für die Backend, während Next.js mit Now/Zeit World bereitgestellt wird).

@sedubois @estrattonbailey Korrigieren Sie mich, wenn ich falsch liege, aber wir rendern immer noch nur einmal . getDataFromTree rendert den Baum nicht, es gibt einfach ein Versprechen zurück, das aufgelöst wird, wenn die Daten in unserem Apollo-Client-Speicher bereit sind. An dem Punkt, an dem das Promise aufgelöst wird, wird unser Apollo-Client-Speicher vollständig initialisiert und wir können den Baum optional rendern, wenn wir die stringifizierten Ergebnisse in der Antwort auf eine HTTP-Anforderung übergeben möchten, aber das tun wir in meinem Beispiel nicht.

getDataFromTree rendert den Baum nicht

@ads1018 AFAIK und beim Betrachten des Apollo-Codes wird der Baum rekursiv gerendert (nur um das Abrufen der Apollo-Daten auszulösen). Das sind also 2 serverseitige Renderings beim Laden der ersten Seite.

Aber wie auch immer, dank Ihrer Demo haben wir jetzt eine brauchbare Integration zwischen Apollo und Next, und die verbleibenden Fragen zur Leistung von Apollo SSR haben meiner Meinung nach nichts Spezifisches mehr für Next.js. Ich würde vorschlagen, dort drüben Fragen zu stellen.

@sedubois was ist überhaupt ein render? Ich würde es „gehen und den Baum schütteln“ nennen. Scheint ziemlich gut optimiert zu sein – setState unterdrückt und keine Abstimmung in DOM.

@ads1018 schönes Beispiel! Sieht so aus, als ob es hier auch zum Wiki hinzugefügt wurde, also könnte dieses Problem wahrscheinlich geschlossen werden?

cc @rauchg

Wir sollten einen Blogbeitrag über Apollo + Next.js im Apollo-Blog erhalten!

Das Beispiel von @stubailo @ads1018 ist großartig 👏 Für etwas Größeres, das dieselben Apollo-Prinzipien verwendet, kannst du meine App überprüfen: https://github.com/relatenow/relate

Danke @helfer. Ich bin begeistert, wie es herauskam. Ich habe das Gefühl, mit Next.js + Apollo den heiligen Gral der App-Entwicklung entdeckt zu haben. Ich wollte schon lange einen Blogpost veröffentlichen, um das Evangelium zu verbreiten, bin aber einfach nicht dazu gekommen. @stubailo Ich würde mich freuen, an einem Artikel für die Veröffentlichung des Apollo-Mediums mitzuarbeiten :)

Großes Dankeschön an @sedubois für seine Hilfe bei dem Beispiel und seiner süßen App. 😄

@ads1018 würde Sie gerne in den Blog aufnehmen. Wenn Sie bereit sind, darüber zu plaudern, pingen Sie mich (thea) auf Apollo Slack an. :)

@helfer Du hast vollkommen recht. Ich sollte einen neuen Ausgabenpass machen, um zu sehen, ob Ausgaben geschlossen werden können 😄

@stubailo @theadactyl tolle Idee ❤️

Kennt jemand ein Problem/eine PR, die es zu beachten gilt - in Bezug auf das zweimalige Anfordern von Daten auf der Serverseite? Nur neugierig