2017-10-14 13 views
0

私は以下のapollo-graphqlクライアントサイドコードを持っています。ここで30秒ごとにgraphqlクエリをトリガしてデータを取得します。Apollo Graphql:再取得中にインジケータを読み込まないようにする

import React, { Component } from 'react'; 
import { gql, graphql } from 'react-apollo'; 
import _ from 'underscore'; 

class Test extends Component { 

    render() { 
     if (this.props.TestData.loading) { 
      return <div>Loading...</div> 
     } 

     if (this.props.TestData.error && this.props.TestData.error !== null) { 
      return <div>Error...</div> 
     } 

     // Iterate through the this.props.TestData.getTestData and build the Table of data here 
     return (
      <table> 
       _.map(this.props.TestData.getTestData.testList, (test) => { 
        <tr> 
         <td>{test.testName}</td> 
         <td>{test.status}</td> 
        </tr> 
       }) 
      </table> 
     ); 
    } 

} 

const TestQuery = gql` 
    query TestQuery() { 
     getTestData() { 
      testList { 
       testName 
       status 
      } 
     } 
    } 
`; 

const options =() => ({ 
    pollInterval: 30000, 
}); 

const withTestData = graphql(TestQuery, { 
    name: 'TestData', 
    options, 
}); 

export default withTestData(Test); 

私が直面している問題は、クエリが再トリガされているので、すべてが30秒後に、私はLoading...を参照してくださいということです。 Loading...は、ページが起動されたときにのみ表示され、その後はスムーズな更新が必要で、ユーザーにLoading...インジケーターを表示したくない場合があります。これを達成する方法がわかりません。

答えて

1
私はドキュメントが data.loadingを使用することをお勧め知っているが、クエリの結果は全く同じようにnullの作品であれば、ほとんどの場合、チェック

// Should probably check this first. If you error out, usually your data will be 
// undefined, which means putting this later would result in it never getting 
// called. Also checking if it's not-null is a bit redundant :) 
if (this.props.TestData.error) return <div>Error...</div> 

// `testList` will only be undefined during the initial fetch 
// or if the query errors out 
if (!this.props.TestData.getTestData) return <div>Loading...</div> 

// Render the component as normal 
return <table>...</table> 

はGraphQLは、いくつかのエラーを返すようにするためにそれが可能だとあまりにも覚えておいてくださいと依然として返されるデータ。つまり、実稼働環境では、エラーが存在する場合にページがレンダリングされることを必ずしも妨げない、より堅牢なエラー処理動作が必要になります。

+0

素晴らしいです。否定が見つからず、正しいフィールドを指すように変更されたため、コードを編集しました。 –

関連する問題