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
LoveLiveSunshine/pixiv.moe
1枚のGIFプレビュー図:
