Twitterフロントエンドアーキテクチャの解析複雑なシーンデータ設計の学習


先日Twitterを使っていたら、Nicolas(Engineering [email protected] Lead for Twitter Lite)がこんなツイートを発表していました.
Twitterのフロントエンドが再構築され、React+Redux+PWAテクノロジースタックに完全に移行し、バックエンドもnodeJSを使用して「フロントエンドが天下を統一する」ことを実現した、lol.
このニュースを聞いて、TwitterのRedux storeの組織構造を深く掘り下げてみると、とても面白いと思います.これは複雑なシーンでのフロントエンドデータ学習,React,Reduxデータストリーム設計にとって非常に有意義である.
なぜなら,Reduxデータストリームフレームワークの考え方の下で,データの処理と割り当ては完全にフロントエンドによって把握されるからである.フロントエンドのデータがどのように設計され、設計の機能がどのようにプロジェクト全体の開発の進度とコードの強健性を直接完全に決定し、ページの性能さえ決定している.
この文書では、Twitterのフロントエンドのデータ構造階層を分析します.Reactテクノロジースタックをよく知らない場合は、読書を妨げることはありません.同様に、このテクノロジースタックに興味がある場合は、私の他の類似の文章を参照してください.
  • React Conf 2017乾物まとめ1:React+ESnext=♥
  • React+Reduxは「NEWS EARLY」の単ページを作成して1つのプロジェクトを応用して最先端の技術スタックの真の意味を理解する
  • react+reduxエンジニアリングの例
  • ......

  • 私のホームページに注目してください.もっと多くの技術的な文章を見逃さないでください.
    本文の主体内容はRyan Johnsonの文章:Dissecting Twitter’s Redux Storeから翻訳され、筆者はある程度開拓した.
    準備作業
    Redux storeを見るには、React Developer Tools(RDT)を搭載し、RDT tabでアプリケーションルートノードを選択する必要があります.選択した後、consoleパネルに次のように入力します.
    
    // $r is a shortcut that references the selected element in RDT
    $r.store.getState();
    

    次に、図に示すように、Reduxデータツリーが表示されます.
    せっけいぶんせき
    時間をかけてそれぞれのstateを展開し、勉強することをお勧めします.しかし、この文章では、紙幅が限られているので、私は選んで深く掘り下げます.
  • entities/tweetsおよび
  • homeTimeline

  • 2つの最も主要で最も核心的なstateを分析した.この2つのstatesにはtweetのすべての関連データが含まれています.
    次の図のようにtweetがあります.
    1つのtweetコンテンツのデータ情報はすべてentities/tweets/entitiesに格納され、entities/tweets/entitiesはnormalizedのdata tableと理解され、すべてのtweetsプッシュ文の情報を格納する.このtableでは、各tweetはキー値ペアタイプのjs object:keyがそのtweetのidであり、valueがそのtweetのデータであり、js objectでもある.
    次の図では、最初のtweetを展開します.
    Twitterのストレージ構造について詳しくは、Twitterのトップページのtimeline構造を見てみましょう.直感的にtimelineには、個人のホームページにツイッターを表示する情報が含まれているに違いない.tweet idは、先ほど紹介したentities/tweets/entitiesのtweetと一致し、最終的にtimelineに表示されます.次の図を示します.
    各ユーザーのトップページtimeline情報はhomeTimelines/timelineで入手できます.トップページのtimelineが示す順序は、timelineという配列の順序に従います.すなわち、timeline配列indexが0のエントリは、トップページのtimelineで見た最初のtweetです.
    重要なことはもう一度言います:トップページtimelineの各tweetには、entities/tweets/entitiesに格納されているtweet idと一致する唯一のidがあります.
    ここを見ると、感嘆するかもしれません.
    “This is pretty much normalizing state shape 101 from Dan Abramov!”
    そう、このようなモデルもReduxが推奨しているように、完全な扁平化設計による開発体験と性能向上は比類がない.
    もちろん、なぜRedux設計哲学がTwitterを含めて扁平化されたデータ構造を推奨しているのかを聞くかもしれません.この問題は参考にすることを提案します:Redux core concepts、ここで言うのはとてもはっきりしていて、Redux core conceptsの中で収録されて、強烈に読むことを提案します.もしあなたが英語が骨が折れるなら、伝言を残して私と交流することができて、もう展開しません.
    本題に戻り、スクロール時の非同期リクエスト設計について議論します.トップページtimelineで新しいtweetsをロードする方法は2つあります.
  • 上引張負荷track tweets by top
  • スライドロードtrack tweets by bottom
  • 1つ目は更新のためのtweetsを引き出し、2つ目はより古いtweetsを引き出すためのtweetsである.例えば、あなたが新しいtweetを出したら、timelineに表示されます.最新のものがなければ、下にスライドした後、自動ロード時間の早いtweets.1つの式で表現します.
    top = new tweets,
    and bottom = older tweets
    この場合、homeTimelinesのlastFetch.bottomとlastFetch.topは、それぞれタイムスタンプで、最後に更新されたデータの情報(上引きと下下がり)を記録します.
  • lastFetch.bottom:最後に下にスライドしてデータを更新した情報を記録する.
  • lastFetch.top:最後に引き下ろしてデータを更新した情報を記録する.

  • 同時にcursor.bottomとcursor.top値はそれぞれtweet idであり、現在のtimeline上、最上段と最下段がそれぞれどのtweetであるかを示す.
  • cursor.bottom:画面最下部tweet IDを記録する;
  • cursor.top:記録画面最上部tweet ID;

  • また、homeTimelinesにはisLoadingDirectionsも記録されています.俺達はここにいるtopは、データ・ロードのトリガ・ソースを表す.
    図:
    最後に興味深いことに、entitiesの下にはentities/tweetsのほかにcards、lists and usersがあります.
  • entities/tweets
  • entities/cards
  • entities/lists
  • entities/users

  • 異なる推文特性を表す.
    残りの3つを開くと、entities/tweetsと同じ構造に保たれています.fetchStatusのdata tableがあり、keyはtweet id、valueはロード状態です.統計によると、いくつかあります.
  • ‘none’;
  • ‘loading’;
  • ‘loaded’;
  • ‘failed’.

  • これらの状態の設定は、いくつかの目的にほかならない.
  • は、loading状態またはloadedのtweetがserverに要求を送信しないことを保証する.
  • は、ロードが完了していない場合に、ロードアニメーションまたはブースマップを表示することができる.
  • ロードに失敗した場合、失敗メッセージを表示するか、このリクエスト時に救済を行うことができます.

  • まとめ
    本稿では,Reduxアーキテクチャを用いたTwitterのデータ設計構造を解析し,複雑なシナリオの下で,reduxに対する読者のより深い認識を引き起こすことを望んでいる.
    本文の主体内容はRyan Johnsonの文章:Dissecting Twitter’s Redux Storeから翻訳され、筆者はある程度開拓した.
    Happy coding!
    PS:著者Github倉庫、コードの様々な形式を通じて交流することを歓迎します.