フロントエンドの最適化の感想とreduxチュートリアルの第1部(計4部)
6022 ワード
自分の英语は普通で、レベルは有限で、原文の住所を献上して、それから私の翻訳の中国语の住所、みんなの勘违を歓迎します
以下は自分の感想です。
Modelsはstores のようですユーザーイベント、データ操作とデータ変更は「action creators」->action->dispatcher->callback のように(view)ビューレイヤは、React view のように
だから、fluxは単語だけなのか.いいえ、そうではありません.しかし、この単語は重要です.私たちがもっと正確に表現できるからです.これらの用語(つまり、fluxは名前だけなのか、その核心概念はmvcと同じです.そうではありません.実はmvcの考えとは違います.しかし、fluxのこの単語も軽視できません.新しい用語を提出することで、flxuというアーキテクチャをより正確に説明することができますから).例えば、バックグラウンドにデータを要求することはactionと呼ばれ、クリックイベントもactionであり、inputのchangeイベントもactionであるように...そして私たちの操作はactionと呼ぶことができます.actionはただの名前です.fluxは、すべてのactionがdispatcherという名前で発行され、私たちのstoresを通過し、最後にstoreを傍受して通知を発行することを保証します.モデル層とView層をactionに直接修正させるのではなく、dispatcherによって開始する必要があります.その後、storesの変更を引き起こすことができます.storesの変更は通知され、mvcのように、イベントが来て、このイベントのコールバック関数でモデルを直接変更したり、viewを変更したりすることはありません.
mvcアプリケーションに古典的な用例1)ユーザがボタンA 2)をクリックするボタンAのクリック処理関数はModel(モデル)「A」の変更3)Model「A」の変更をトリガーし,Model「A」を傍受する関数を実行し,この関数はModel(モデル)「B」の変更4)Model「B」の変更をトリガーし,Model「B」を傍受する関数を実行し,この関数はView Bの再レンダリングをトリガーする
このような環境でバグの源を素早く見つけようとすると、それは大きな挑戦になるだろう.これは、Viewが各Modelを傍受し、Modelが他のModelを傍受しているため、データは多くの場所から来ることができ、多くの状況が変更される可能性があるため(viewsもmodelsのためかもしれない)(データの変更は多くの状況から来る可能性があり、混乱し、予測できない)
そしてfluxとその一方向データストリームアーキテクチャを用いると,上記の例はこのようになっている1)ユーザがボタンA 2をクリックする)ボタンAのクリック処理関数はdispatchを1つのactionから離れ,Store「A」を受信通知に変更する3)dispatchに使用するこのactionも他のstoreに通知するので,Store「B」が通知を受けることによっても対応する変更が起こる4)Store「A」は,Store"B"の変更はView Bに通知され、View Bが再レンダリングされる
だから、Store AとStore Bの直接的なつながりを防ぐ方法を知っていますか?各storeの修正はactionでしかできません.他の方法ではできません(だからwatch Store Aを阻止してStore Bを直接変更します).このacitionに関連するすべてのstoreが応答する変更viewsも最終的に更新されます.データは次の線に沿ってしか伝達できません
action -> store -> view -> action -> store -> view -> action -> ...
私たちの例がactionから始まるように、私たちのチュートリアルもactionとactionの作成から始めましょう.
翻訳を続ける
以下は自分の感想です。
まずwebpackについてお話ししますが、フロントエンドの最適化にはいくつかのステップがあることを知っています.
最初のステップ
まず、1つのアプリケーションは多くのjsファイルに依存し、ブラウザは1つのファイルをロードし、これを実行してから次のファイルをロードすることを知っています.だから、遅いので、私たちはそれらを合成しなければなりません.
ステップ2
ブラウザにキャッシュがあることは知っていますが、新しいバージョンをリリースするときにブラウザキャッシュを防ぐために、新しいバージョンをリリースするたびに前のファイル名とは異なるので、md 5要約アルゴリズムでjsファイルの生産要約をjsファイル名の一部として使用します.
ステップ3
しかし、ブラウザキャッシュを利用して、リクエストを減らして、ロード速度を速めたいと思っています.私たちはよく私のアプリケーションのビジネスロジック部分のjsを変更していますが、jsの依存はほとんどありません.そして、jsの依存体積はまだ小さくありません.だから私たちはjsのすべての依存を1つのファイル(vendor.js)に置いて、ビジネスロジックは1つのファイル(app.js)に置いて、それからそれぞれmd 5暗号化します
ステップ4
単ページアプリケーションで、しかも膨大なアプリケーションであれば、上がってくるとすべてのjsをロードしてしまいますが、もったいないのではないでしょうか.多くのページなので、私たちは注文しません.必要に応じてロードする必要がありますロードするページにアクセスする場合にのみ、関連jsをロードします.
ステップ5
やはり1ページのアプリケーションで、最初のロードの速度を速めるために、cssもオンデマンドでロードできればいいと思います.私たちはどうしてjsダイナミックオンデマンドでcssをロードしないのですか.いっそcssとjsを一緒に書いて(私たちはどのように書くか、webpackを一緒にさせます)、jsをロードするとcssをロードして、1つのjsリクエストには同時にcssが含まれます.これでcssのリクエストも少なくなり、二人でgzipで圧縮することができます.
ステップ6
アイコンなどいろいろありますが、リクエスト数を減らすために合わせているのではないでしょうか.スプライトを生成します.これにはまだ完璧ではありません.jsと一緒にいられたらもっとよかったのに.のどうしますか.base 64で文字列にします.そしてjsと一緒にいられるようになりました.これでgizpを利用して75パーセント圧縮することもできます.ただし、小さな画像や小さなアイコンが前提です.いいえ...画像が大きすぎるとやはり.の以上の6ステップです.のWebpackの十数行のコードはあなたを実現することができます.ここを見てcn
そしてreact性能についてお話しします
性能の大きいデータ量の高いインタラクティブな応用は、同じ2つの牛で、reactとangularをそれぞれ使って、reactはangularよりずっと性能がいいと思います.私の前提に注意して、私は1年半angularを使って、最后にやはり彼の污い検査を受けて、心を痛めて、私达は1つの双方向のバインドが1つのwatchを代表することを知っていて、1列の污い検査を代表して、データが大きい时.ああ...
最後はメンテナンス可能
まず、一方向データストリームはmvcよりずっと強いと結論しました.翻訳したreduxチュートリアルで詳しく説明します.
こんなにたくさんくどくどしてチュートリアルを始める
チュートリアル0-説明
なぜこのチュートリアルがあるのでしょうか。
私がreduxを学んでみたとき、読んだ文章と個人の経験に頼って学んだfluxに関する知識には、多くの間違いがあることに気づいた.fluxに関する文章が悪いとは言っていないが、私はこれらの概念を正しく身につけていない.最終的には、異なるfluxフレームワーク(Reflux,Flummox,FB Flux)のドキュメントと、彼らと私が読んだ理論概念(actions/actions creators,store,dispatcher,etc)を使ってハードカバーを生み出そうとしただけで、私がreduxを使い始めたとき、私が想像していたよりずっと簡単であることに気づきました.これはreduxが非常に優れた設計を持っていて、私が以前使っていたフレームワークと同じではないおかげです.多くの「anti-boilerplate features」(逆パターンの特徴)がありますが、今ではreduxを通じてfluxを学ぶのが他の多くのフレームワークよりずっといいと大げさに言えます.私自身の言葉で言えば、これはなぜ私が掌握したreduxに関するflux概念をみんなに分かち合いたいのか、下図が有名な単一データストリームfluxアプリケーションであることを知っているかもしれません. _________ ____________ ___________
| | | | | |
| Action |------------▶| Dispatcher |------------▶| callbacks |
|_________| |____________| |___________|
▲ |
| |
| |
_________ ____|_____ ____▼____
| |◀----| Action | | |
| Web API | | Creators | | Store |
|_________|----▶|__________| |_________|
▲ |
| |
____|________ ____________ ____▼____
| User | | React | | Change |
| interactions |◀--------| Views |◀-------------| events |
|______________| |___________| |_________|
このチュートリアルでは、上記のグラフの概念を徐々に紹介します.私たちはそれぞれ各モジュールの存在理由とどのような役を演じているのかを理解しようとします.上から図全体を説明するのではなく、みんなが頭を大きくします.もしあなたがすべての部分を理解すれば、ドラゴンボールを集めて、神龍を召喚することができます.ハハハ.
しかし、始める前に、fluxがなぜ存在するのか、なぜそれをつまむ必要があるのかについて話しましょう。
Webアプリケーションを開発しているとしたら、何から構成されていますか?1)Templates(テンプレート)/html=View(ビュー)2)と我々View(ビューレイヤ)にバインドされたデータ=Models(モデル)3)データの論理を取り、各種ビューレイヤの切り替えをスケジューリングし、ユーザイベントに応答し、データの修正など=Controller(制御レイヤ)
これは私たちがよく知っている非常に古典的なmvcモードです.あなたの心の中にも、表現を少し修正すると、実はmvcモードもfluxの概念が恋しいという疑問があるのではないでしょうか.
なぜこのチュートリアルがあるのでしょうか。
私がreduxを学んでみたとき、読んだ文章と個人の経験に頼って学んだfluxに関する知識には、多くの間違いがあることに気づいた.fluxに関する文章が悪いとは言っていないが、私はこれらの概念を正しく身につけていない.最終的には、異なるfluxフレームワーク(Reflux,Flummox,FB Flux)のドキュメントと、彼らと私が読んだ理論概念(actions/actions creators,store,dispatcher,etc)を使ってハードカバーを生み出そうとしただけで、私がreduxを使い始めたとき、私が想像していたよりずっと簡単であることに気づきました.これはreduxが非常に優れた設計を持っていて、私が以前使っていたフレームワークと同じではないおかげです.多くの「anti-boilerplate features」(逆パターンの特徴)がありますが、今ではreduxを通じてfluxを学ぶのが他の多くのフレームワークよりずっといいと大げさに言えます.私自身の言葉で言えば、これはなぜ私が掌握したreduxに関するflux概念をみんなに分かち合いたいのか、下図が有名な単一データストリームfluxアプリケーションであることを知っているかもしれません.
_________ ____________ ___________
| | | | | |
| Action |------------▶| Dispatcher |------------▶| callbacks |
|_________| |____________| |___________|
▲ |
| |
| |
_________ ____|_____ ____▼____
| |◀----| Action | | |
| Web API | | Creators | | Store |
|_________|----▶|__________| |_________|
▲ |
| |
____|________ ____________ ____▼____
| User | | React | | Change |
| interactions |◀--------| Views |◀-------------| events |
|______________| |___________| |_________|
このチュートリアルでは、上記のグラフの概念を徐々に紹介します.私たちはそれぞれ各モジュールの存在理由とどのような役を演じているのかを理解しようとします.上から図全体を説明するのではなく、みんなが頭を大きくします.もしあなたがすべての部分を理解すれば、ドラゴンボールを集めて、神龍を召喚することができます.ハハハ.
しかし、始める前に、fluxがなぜ存在するのか、なぜそれをつまむ必要があるのかについて話しましょう。
Webアプリケーションを開発しているとしたら、何から構成されていますか?1)Templates(テンプレート)/html=View(ビュー)2)と我々View(ビューレイヤ)にバインドされたデータ=Models(モデル)3)データの論理を取り、各種ビューレイヤの切り替えをスケジューリングし、ユーザイベントに応答し、データの修正など=Controller(制御レイヤ)
これは私たちがよく知っている非常に古典的なmvcモードです.あなたの心の中にも、表現を少し修正すると、実はmvcモードもfluxの概念が恋しいという疑問があるのではないでしょうか.
だから、fluxは単語だけなのか.いいえ、そうではありません.しかし、この単語は重要です.私たちがもっと正確に表現できるからです.これらの用語(つまり、fluxは名前だけなのか、その核心概念はmvcと同じです.そうではありません.実はmvcの考えとは違います.しかし、fluxのこの単語も軽視できません.新しい用語を提出することで、flxuというアーキテクチャをより正確に説明することができますから).例えば、バックグラウンドにデータを要求することはactionと呼ばれ、クリックイベントもactionであり、inputのchangeイベントもactionであるように...そして私たちの操作はactionと呼ぶことができます.actionはただの名前です.fluxは、すべてのactionがdispatcherという名前で発行され、私たちのstoresを通過し、最後にstoreを傍受して通知を発行することを保証します.モデル層とView層をactionに直接修正させるのではなく、dispatcherによって開始する必要があります.その後、storesの変更を引き起こすことができます.storesの変更は通知され、mvcのように、イベントが来て、このイベントのコールバック関数でモデルを直接変更したり、viewを変更したりすることはありません.
mvcとfluxの違いを明確に理解するために
mvcアプリケーションに古典的な用例1)ユーザがボタンA 2)をクリックするボタンAのクリック処理関数はModel(モデル)「A」の変更3)Model「A」の変更をトリガーし,Model「A」を傍受する関数を実行し,この関数はModel(モデル)「B」の変更4)Model「B」の変更をトリガーし,Model「B」を傍受する関数を実行し,この関数はView Bの再レンダリングをトリガーする
このような環境でバグの源を素早く見つけようとすると、それは大きな挑戦になるだろう.これは、Viewが各Modelを傍受し、Modelが他のModelを傍受しているため、データは多くの場所から来ることができ、多くの状況が変更される可能性があるため(viewsもmodelsのためかもしれない)(データの変更は多くの状況から来る可能性があり、混乱し、予測できない)
そしてfluxとその一方向データストリームアーキテクチャを用いると,上記の例はこのようになっている1)ユーザがボタンA 2をクリックする)ボタンAのクリック処理関数はdispatchを1つのactionから離れ,Store「A」を受信通知に変更する3)dispatchに使用するこのactionも他のstoreに通知するので,Store「B」が通知を受けることによっても対応する変更が起こる4)Store「A」は,Store"B"の変更はView Bに通知され、View Bが再レンダリングされる
だから、Store AとStore Bの直接的なつながりを防ぐ方法を知っていますか?各storeの修正はactionでしかできません.他の方法ではできません(だからwatch Store Aを阻止してStore Bを直接変更します).このacitionに関連するすべてのstoreが応答する変更viewsも最終的に更新されます.データは次の線に沿ってしか伝達できません
action -> store -> view -> action -> store -> view -> action -> ...
私たちの例がactionから始まるように、私たちのチュートリアルもactionとactionの作成から始めましょう.
翻訳を続ける