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種類のソリューションに言及して、それぞれ利害がある。
リストに1つの正しい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