8
Facebook FluxでReduxを使用する理由 [閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 昨年休業。 ロックされています。質問はトピックから外れていますが、歴史的に重要であるため、この質問とその回答はロックされています。現在、新しい回答や相互作用を受け入れていません。 私はこの答えを読んで、ボイラープレートを減らし、GitHubの例をいくつか見て、少しやり直してみました(todoアプリ)。 私が理解しているように、公式のredux doc動機は、従来のMVCアーキテクチャと比較して長所を提供します。しかし、それは質問に対する答えを提供しません: Facebook FluxではなくReduxを使用する理由 それはプログラミングスタイルの問題だけですか?機能か非機能か?または、問題はreduxアプローチから続く能力/開発ツールにありますか?たぶんスケーリング?またはテスト? reduxは関数型言語から来た人々にとって流動的なものだと言ってもよろしいですか? この質問に答えるために、実装の複雑さを比較することができます。 公式のredux docモチベーションのモチベーションポイントは次のとおりです。 楽観的な更新の処理(私が理解しているように、5番目の点にほとんど依存しません。Facebookの変化に実装するのは難しいですか?) サーバーでのレンダリング(facebookフラックスでもこれを行うことができます。reduxと比較して何か利点はありますか?) ルート遷移を実行する前にデータを取得する(facebookフラックスではなぜそれができないのですか?利点は何ですか?) ホットリロード(React Hot Reloadで可能です。なぜreduxが必要なのですか?) 元に戻す/やり直し機能 その他のポイントは?持続する状態のように...