問題タブ [relay]

RelayフレームワークとGraphQLを学んでいます。公式ウェブサイトのチュートリアルに従っています。そのチュートリアルでは、GraphQL ミューテーションを使用してゲームを構築します。ゲームの目的は、9 つ​​の正方形のグリッドに隠された宝物を見つけることです。サーバー上で実行するとすべて問題ありませんでしたが、グリッドの 1 つに対してクリック アクションを実行すると、アプリがエラーをスローしました。

commitUpdate()コンソールのログから、 に関数がないことがはっきりとわかりましたが、 Relay のプレイグラウンドで に関数があることがわかり、this.props.relay混乱しました。commitUpdate()this.props.relay

何かご意見は？

シンプルなアプリケーションにさらにロードする機能を作成しようとしています。Sequelize と GraphQL を使用して MySQL からデータをフェッチします。アプリケーションの足場として、relay-starter-kit を使用しています。

データベース.js

schema.js

App.js

AppHomeRoute.js

このアプリケーションは簡単です。クリックすると「もっと読み込む」機能をトリガーするボタンがあります。関数は App.js で確認できます。関数が実行されるたびに、以下が返されます。

Cannot read property 'reduce' of undefined.

クエリが正しいことを確認しようとしましたが、GraphiQL を使用してクエリを作成しようとしたときに「興味深い」ものを見つけました。

フラグメントを使用する場合(サーバーにリクエストを行うときのアプリケーションの方法と同じ):

結果:

フラグメント(生のクエリ)を使用しない場合:

結果:

問題はクエリにあると思いますが、よくわかりません。私は今、少しイライラしています。どんな助けでも大歓迎です。

ありがとう。

フロント エンドに Javascript、バック エンドに C# を使用して Web アプリを構築し、GraphQL の価値を判断したいと考えています。

• 私の C# バックエンドでは、GraphQL for .NETという名前の GraphQL 実装を使用します。
• 私のフロント エンドには、ReactJS とうまく連携するRelayを使用したいと考えています。

次に、バックエンド用に、次のような例の 1 つのようなサンプル スキーマを実装しました。

私のフロントエンドでは、Relay にこのスキーマについて何らかの方法で伝える必要があります。何らかの理由で GraphQL クエリをトランスパイルする必要があるため、少なくともこれはチュートリアルを見ていくときに理解したものです。これは、すべてのドロイドをロードする方法の例です。

Relayの例の 1 つで、babel-relay-pluginが変換に使用されていることがわかりました。スキーマ ファイル (JSON) を取得します。Relayの入門ガイドには、graphql-js と graphql-relay-js を使用してそのようなスキーマを作成する方法が示されています。

今私の質問：

1. フロントエンドとバックエンドでスキーマを作成する必要は本当にありますか?
2. バックエンドはすでにスキーマを使用して適切な形式のデータを返しているため、Relay に自分のスキーマを教える意味は何ですか?
3. このシナリオで Relay を使用する利点は何ですか? パラメータとして GraphQL クエリを使用し、通常の REST エンドポイントを介してバックエンドにアクセスすると、何が失われますか?

コンテナに複数のフラグメントがある場合、そのうちの 1 つだけにするにはどうすればよいforceFetchですか?

ドキュメントによると、呼び出すthis.props.relay.forceFetch()と、コンテナに関連付けられているすべてのフラグメントが更新されます。

「そのまま」の強制フェッチが機能しますが、Relay の全体的なポイントは、オーバー/アンダー フェッチを回避することです。

何かアドバイス ？

私はこの種の話題について、白熱した矛盾した情報をたくさん読みましたが、私には闘争心はありません。私にはオープンマインドという利点があります。

台所の流しにあるboilerplateすべてのものにを使用した後、 のようなものが必要であると考えるようになった、非常に非公式な思考プロセスについて説明します。relayredux

• いくつかのシナリオでは、十分なボイラープレートは、十分なボイラープレートよりもredux時間がかからず、考える必要もありません。GraphQLrelay
• actions inの抽象化reduxは、多くのプログラマーが関心を分離し、リクエストの内部構造/リクエストの動作とその存在をカプセル化することを強制することで、多くのプログラマーをトラブルから守る良いことです。
• 具体的には、たくさんのツールやブラシを使ってキャンバス エディタを作っているとしたら、永続性に気をつけてそれらrelayすべてを正しい方法で作成し始めるには、長い時間がかかりそうです。mutatorsqueries
• しかし、アプリがすべての状態を把握する必要はなく、redux何らかの大きなコンテナ オブジェクトを介して状態を管理するか、それをウィングする以外に方法はありません。劣っているredux
• したがって、reduxこのシナリオに位置する私の本能は正しい本能です

GraphQLしかし、私はどのように使用されるべきかを理解していないかもしれませんrelay。

したがって、1)これはかなり客観的な質問なのか主観的な質問なのか、2)コンセンサスがあるかどうか、3)気にする必要があるかどうかについて、具体的な回答を求めています。

もう 1 つ - そのreduxようなシナリオで公正なゲームである場合、アプリが 1 つのストアを持つべきであるというのは経験則として適切でしょうか? reduxそれとも、よりモジュール化してさまざまな方法で使用を開始できadhocますか?

ところで、ここにもっと単純なシナリオがあります: Stepperfrom material-uiwhich requiresを使いたいですState。私の選択がなければ、それをレベルまたはそれ以下reduxで忠実に行うか、コンポーネントでウィングするか、何らかの方法でそれをごまかそうとするか、混合するかのいずれかです. relay唯一のサウンドオプションは最初のものであり、それには時間がかかります.

私は Universal Relay Boilerplate が好きです - 一般に、フォルダ編成などが意図された後付けであると思われるほとんどの定型文とは異なり、彼らはこの全体をどのようにまとめるかについて非常に思慮深いと言えます (私はあなたがそうしないからだと思います)。最初に重要なこと、または何か)... しかし、URB ではありません。または、少なくとも私たちは同じことについてうるさいです。

なぜ同じような迷惑なことをするのか...

...1 つを除いて: なぜ彼らがこれを行うのかわかりません。

...説明もなく2回接近？

これは、実際にはエイリアスのおかげでオリジナルとは少し異なる「タイプ」です。

彼らは明らかにそれを意図しています

これは、ボイラープレートで見つけることができるmodelとの最も劇的な違いの例です。type他は同じです。私は実際、他のガイドが を推奨したり言及したりせmodel.jsず、むしろ から始めることを知って少しイライラしましたtype.js。

だったら理解できた

• 一部のタイプは、セキュリティ、パフォーマンス、美学、デザインなどのためにモデルとは異なる必要があります
• 一部の型は意図的にモデルにまたがる
• 一部のタイプは、設計上の理由からモデルをカプセル化します

しかし、彼らはどこでもそうしているので、ここで重要なものが欠けていると思います。