react.js を利用して、創建した挿絵の画像欄

react + redux を使って、Web アプリケーションを組み合わせた。それは pixiv.net の挿絵の画像欄であり、私はそれを pixivの「ラブライブ」発見 と呼ばれている。 pixiv.net 挿絵のインターネットにラブライブに関するラブライブ！学園アイドル祭の作品を用いる。ラブライブがそのアプリケーションが好きになると思う。

特徴

ラベルによって、挿絵を選別する
挿絵の詳細情報を調べる
pixiv に登録して、好きな挿絵にブックマークをする

主な技術:

react
react-dom
react-router-component
redux
redux-thunk
react-redux
react-mdl
whatwg-fetch
webpack

AJAX リクエスト

AJAX リクエストに関して、たくさんの選択肢がある: fetch 、 superagent 、 axios 、その上 jQuery.ajax 。総合的に比べて、標準的な fetch は必ず最高な選択である。

fetch の主な長所:

簡単な文法、更に語義化のようだ
Promise の標準に基いで、async/await にサポートする。
便利な同型定理

原生の支持率は高くない。しかし以下の polyfill を取り入れて、IE8 + にサポートすることができる:

IE8 は ES3 であるから、ES5 の polyfill を取り入れるのが必要である:es5-shim, es5-sham
Promise の polyfill を取り入れ: es6-promise
fetch 探測倉を取り入れ:fetch-detector
fetch の polyfill を取り入れ: fetch-ie8
選ばれ：もし jsonp も使えば、fetch-jsonp を取り入れる
選ばれ：Babel の runtime・モデルを開けて、今、async/await を使っていく

Fetch polyfill の基本的な原理は window.fetch の方法があるかどうかを測定する。ないなら、XHR を利用して実現する。これも github/fetch の方法であり、しかしあるブラウザー（Chrome45）は元で fetch をサポートする。これらの庫は今、毎日に数千万のリクエストが使用していて、問題ないである！

fetch のよくある質問

Fetch リクエストは既定に cookie が無いから、 fetch(url, {credentials: 'include'}) を設置するのが必要である。
サーバーは 400 、 500 ミス番号に戻る時、拒絶しない。ネットワーク・ミスのせいで、そのリクエストが完成できない場合、fetch が拒絶される。

性能合理化

このアプリケーションの中に、一つの長いリストがあって、すべての画像のモジュールで onClick 事件を縛って、もしリストの数量は上がってきて、性能の問題も明らかで、ソリューションは主に以下:

props の中で bind 方法を使えないでください。

onClick 中で bind(this) を操作しないでください。そうすると、毎回 render が新しい関数を形成するから、性能に対する影響は顕著である。同じ、矢じり関数 ()=>{} のを使う場合、同じ理論である。それも一回に自動 bind する。良い方案は constructor の中で事前にバンドしたそうである。Don’t Use Bind When Passing Props 。この文章は共に 9 種類のソリューションに言及して、それぞれ利害がある。

リストに１つの正しい key 属性をあげる

周知のように、react 循環中のリストは必ず key 属性を与えなければならなくて、この属性はユーザーが自分で使うのではなくて、React 自分で使ったのです。配列の元素に必ず唯一の key 属性を提供しなければならなくて、私達は直接に配列の index を使って key とする。実はそれが何度も一挙であり、 key を提供しないなら、react は黙認に採用したのが index である。良い方案は shortid を使って形成するのである。それは主に Index as a key is an anti-pattern を参考した。

setState 慎重に用いる

データを Redux に任せて管理したなら、できるだけ Redux でデータと状態 state を管理してください。少数の情況以外、 shouldComponentUpdate も state の比較が必要なことを忘れないでください。

Component が必要な props だけを順送りする

順送りしたのが多すぎ、あるいは段階が深すぎの場合、 shouldComponentUpdate のデータ比較の負担をもたらして、そして、慎重に用いてください。

shouldComponentUpdate 使用

shouldComponentUpdate は黙認状況で true に戻って、つまり props あるいは state が変化すれば、このモジュールは更新して、そのとおり、 props の変化のように、モジュールも更新する可能性がある。リストの VirtualDOM は毎回レンダリングする時、新生するから、最も簡単な方法はすべての Item の shouldComponentUpdate を実現することである（現在と取り入れた props を比較するのを通じて、更新するかどうかを判断する。属性は object であるのが、内部の変化を判断するのが必要ので、もし私達は immutable―js が必要である）。

PureRenderMixin

React が提供した PureRenderMixin は、実は以上の必要なことをやってくれて、ファイルの方法に基づいて、十分である。しかし、このプラグインはすべての属性を比較して、いくつか状況で予想するのと違う可能性がある。

モバイルサイドのロード最適化

Javascript を localStorage にキャッシュメモリして、バージョンが変動した後、サーバーで新しい js をダウンロードする。ソリューションはモバイル WEB 通用最適化策略紹介からのである。 localStorage は静態の資源をキャッシュメモリして、モバイルサイドと高いバージョンのブラウザーで試み価値があるそうである。ブラウザーを通じて、静的ファイルをキャッシュメモリすることができるけど、いくつか状況で（たとえば f5 の更新）、それども cache―control: max―age=0 のリクエストを提出する。リクエストを節約する目的で、静態資源のリクエスト方法を改造することができて、すべての静態資源をひとつのリクエストを通じてロードする。そうすれば、いずれにしても、ページはただ一つのリクエストを出す。もし静的なファイルは更新があれば、サーバーは更新するファイル内容に戻って、js を通じてページの中に挿入して、 localStorage の中でキャッシュメモリをする。もし静的ファイルは更新がないなら、直接に localStorage の中から取り出して、ページの中で挿入して十分である。モバイルサイドにとって、js と css これらの静的ファイルのリクエストをひとつに減らして、やはり効果があるそうである。具体的なものは百度のモバイル版、に参考してください。単のページの運用にとって、 localStorage の貯蓄枠板を使うのも良い選択である。

インターネット・リクエスト合理化

Ajax のリクエストもキャッシュメモリして、キャッシュメモリが必要なリクエストは期限が切れ時間のカラムに戻る。データを得た後、期限が切れ時間とデータを localStroage 中で保存して、次回にのリクエストは期限が切れ時間と現在時間に比べて、再度リクエストが必要かどうかを判断する。

その他、react 各種の問題の集合を進め:react-faq

プロジェクト・アドレス:
https://pixiv.moe
https://github.com/LoveLiveSunshine/pixiv.moe

1 枚の GIF プレビュー図:

Qiita