はい、少なくとも自分がこれまでReactを学んでこなかったのはReduxがあったからで、逆に今学ぼうとしているのは、Reduxを学ばなくて良くなりそうな確信が持てたからです。Reduxは使ったことないんですが。
自分は今は小規模なものしか使っていませんが、大規模になった場合でも他のライブラリを選ぶでしょう。
Reactをしっかり学び始めたのは最近ですが、情報については収集してて、Reactの概念とか、仮想DOMとかはちゃんと学べば理解できました。Immutableとか、関数型の概念とかも特に問題ありませんでした。Javaとかでも必要なので。
例えば仮想DOMって仰々しい名前ですが、ただの状態を表したJSONです。それをDOMに変換しているだけです。実際には難しいことは色々ありますが、一言で言えることは大事です。
ただ、Reduxについては最初から違和感がありました。ボイラープレートが多いとかそういうのもありましたが、もっと根本的な違和感がありました。ただ自分はバックエンドばかりやってたので、しばらく無視していました。
個人的に開発しているDjangoで作っているアプリは、ずっとDjangoテンプレートだけでやってきたのですが、そろそろフロントエンドもちゃんと作った方がいいなぁ・・・と思ったところ、この記事を見ました。
これで
… (もっと読む)
そもそもReactは難しいものではないです。
仮想DOMとJSXについて少し調べれば、すぐに納得がいくはずなのです。
ましてやReduxなんてもっと単純です。
そこで、当回答ではいかにReduxの簡単かを説明することにします。
まず、Reduxのユースケースは複数コンポーネント間での状態共有です。
Reduxを知らない状況で、コンポーネント間で値を共有をしたいと思ったとき、みなさんだったらどうしますか？
一番簡単な方法を思い浮かべてください。
。
。
。
もちろん、ミュータブルなグローバル変数を使いますよね。
- export let state = {
- count: 0
- }
これだけです。
使う方は state.count++ とかすればいいのですが、この変更を他の利用モジュール（コンポーネント）にも通知したいです。
なので、状態を変更する関数を用意し、状態そのものは直接変更できないように隠ぺいし、なおかつ変更した際の通知を購読できるように利用側がフックの登録をできるようにします。
- // 初期状態
- let state = {
- count: 0
- }
- // 状態を変更する関数
- export function increment(num) {
- state.count += num
- // 状態が変われば、フックが呼び出される
- // フックには状態が引数として渡され、通知が行く
- hooks.forEach(hook =>
Reduxが難しいと思われているものがいくつかあります。
Reduxが扱っている状態管理がそもそも難しい領域
Webでもモバイルアプリでもフロントで状態管理を正しく行うというのは一番難しいところになります。そもそも一番難しい領域を扱うライブラリだからこそ難しいと思われています。そして状態管理はフロントの根幹であるので色々な箇所でReduxと連携する必要があるので、Reduxの難しさが目立ちやすいです。
シンプルなものでも組み合わせていくと難しい
実はRedux本体自体はすごく小さなライブラリです。React自体も提供している範囲は少ないです(React hooksが入る前なんかはさらに小さかったです)。
ただし、Redux × React × TypeScript × react-router × redux-sagaのように一つ一つは小さいライブラリや仕組みであっても組み合わせていくどんどん難しくなっていきます。
React自体がそういう小さなライブラリを組み合わせて使っていくという思想であるので、プロジェクトが大規模になってもライブラリの取り替え可能である反面、組み合わせた時にそれぞれのライブラリを理解していないと上手く動かないことが多々あります。その場合Reactとの組み合わせよりも、Reduxとどう組み合わせるのかというのが経験上多いのです。そのためReduxが難しい印象となるのかもしれません。
状態中心で考えていく
サーバサイドの考え方でReduxを理解しようとするとつまづきます。基本的にサーバサイドはリクエストという何らかのアクションから計算をしてDBに反映させることが一連の流れになりますが。Reduxの場合は大雑把にいうといきなりDB(状態)を更新してDB(状態)に合わせてUIの変更が走るので発想が違います。別にこれはReduxの考え方というよりもリアクティブプログラミングの話になります。つまり、Reduxが難しいというよりもリアクティブプログラミングが難しいのだと思います。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
上記のことを考慮すると、もっとシンプルな状態管理ライブラリやReactのみの機能を使用すればいいという流れも理解できますし、大規模なプロジェクトじゃなければ使わないというの判断もあります。
しかし、プロジェクト序盤でこのプロジェクトが大規模にならないと判断するのは難しくないでしょうか？
個人サービスならともかく企業の新規サービスとなるとより判断が難しいです。しかも、状態管理ライブラリというのは一度導入したら後で変えるというのはかなり大変です。サーバサイドで例えるなら今までOracleで動いていたDBをPostgreSQLに変更するみたいなことです。
また状態管理だけであればもっと最新のシンプルなライブラリがあるかもしれませんが、今後ルーティングも管理したいとなった時にルーティング用のライブラリと状態管理ライブラリの相性を考える必要があります。結局そのコストまで考えるとメジャーなReduxの方が情報が多く良かったということはありえそうです。そのため状態管理ライブラリだけを比較してもあんまり意味がないと個人的には考えています。
よくReactがフロントのフレームワークとして紹介されますが、個人的にReduxの方が実はフレームワークの役割が大きく、そりゃあ難しいよなと実感します。
Reactを使ってプロジェクトのさまざまな問題を解決したりとかしてきて、Reactコンポーネントのコツみたいなのもわかってきたと思いますし、関数コンポーネントなんかも使ったりでいろいろやってきました。2年半くらい。
そんな自分ですがReduxは使いたくないです。
直感的ではないし、使うメリットを感じません。面倒さと複雑さがます気がしています。
あれを使いこなせることが、高い技術を持っていることの証だと思う人が積極的に使っていた時期がありました。
でも、見ている人はちゃんと見てましたよね。あれはいけてないライブラリだと。複雑さを隠蔽して楽に何かを行うのではなく、複雑さを隠蔽できてなくて逆にプログラムが読みにくくなると。
プログラムってシンプルに保っておかないといろいろあとから苦労します。Reduxを使うとコードはシンプルにならずに逆に複雑化します。そういう技のは術的負債になりかねない気がするのでなるべく避けて組んだ方がよいと今の所は思っています。
next.jsやgatsbyjsなどのメリットは、SSRやSSGなどを利用して、様々な用途のWEBページの作成ができることです。
一般的なWEBサービスは、下記の種類のページを組み合わせていることが多いと思われます。
- 静的サイト ・・・ ランディングページなどに使えます。
- ビルド時動的生成 ・・・ ビルド時に、動的にページを生成し、結果的には静的になります。サイト内の小さいグッズ売り場などは、ユーザーによるポストもなく、数と運用の面で最適です。
- 動的サイト ・・・ quoraの質問ページのようにURLを割り当て、Googleのクローラーがインデックスできるようにしたいページです。SSGのようにホスティングサーバーのストレージにすべてのページを置けるような量ではないと思うので、SSRが必要になる場合があります。
- SPA ・・・ ユーザーにアプリを提供する為の部分で、webアプリにログインした後のマイページなどです。Googleのクローラーによるインデックスが必要なく、URLも#を含めたフロントエンドルーティングで十分なページです。
これらを、ライブラリを組み合わせてスクラッチから構築するのはコストが大きいので、最初はnext.jsやgatsbyjsを使うべきです。
そして、特に3.の動的ページに関しては、その後のユーザー数やトラフィックの増加に合わせて、パフォーマンスをチューニングする為の施策をしていく必要に迫られるとは思います。
このように、next.jsはホスティングサーバー構築のベストプラクティスを詰め込んだフレームワークなので、RouterやReduxの使用と直接関係するものではありません。
それらをインスタントに導入したい場合は、create-react-appの方が、近道かと思います。
ReactはVirtualDOMの概念を認識するところから始めるのが良いです。
もしVirtualDOMについてよくわからない場合は、Reactは一切絡まないJavaScriptで使うDOMについてまず把握し、かんたんなHTMLファイルと普通のJavaScriptで「documentとは何か」「イベントリスナとは何か」を把握すると良さそうです。そのあとでReactをやって「なぜプレーンのJavaScriptではなく、Reactを使うのか。そのメリットは何か」という部分を明らかにしてから取り組むといいと思います。
そして、Reactのstate（状態）やHooksについて学習して、なぜそこに書くか、どうしてそれで動くかを把握すると良いです。カスタムHooksの作り方を知るとかなり良いです。
以上の部分が重要な部分であり、あとは「より簡単に書けるようにする」とか「別のライブラリを使う」という、エコシステムの部分です。たとえば、ESLintをどのように使うのかだとか、webpackをどのように使うのかだとか、TypeScriptを使って開発するにはとか、CI/CDをどうするかだとか、Reactとは直接関係ないものが多いと思います。
これらのエコシステムを「Reactとは直接関係ない」というふうに認識できると、だいぶわかりやすいはずです。
またReactとは別に、JavaScriptを関数型言語的に扱う方法を覚えるとわかりやすくなります。これもReactとはなんら関係ありませんが、現代のReactは関数型言語的に使うことを前提にしていることが多いので、わかりやすくなると思います（絶対にそういうわけではありません）
こちらについてはEcmaScriptの仕様を見ると良いです。
概念を覚えたあとに、簡単なtodoリストを何も見ずに作れれば、あとは根気だと思います。
react-reduxは7.1以降Hooksとしても利用できるので、今やそれは排反の選択肢ではありません。
Hooks導入後のコンポーネントの状態管理の選択肢は、主なものとして
- useState単独
- useState+useContext
- useReducer単独
- useReducer+useContext
- action抽象を導入する
- action抽象をあえて導入しない
- React-Redux 7.1以降(useDispatch+useSelector)
- Redux Toolkit(旧名Redux Starter Kit)(5+Immer+ducks module+action creator自動生成)
があります(他にもあると思います)。
1はクラスコンポーネントでのstate相当ですが、それと全く同じバケツリレー問題を抱えていて、状態やその変更のためのコールバックを複数のコンポーネント間でとりまわすと早晩に限界が来ます。逆に、コンポーネント内に閉じた状態が主だったり、コールバックをとりまわさずに済むのであれば1でも問題ありません。
2は、個人的には中途半端に感じられます。集約の結果としてstateが大きくなれば、reducer的なものが必要になります。
3は意味ない気がします。
4aは実質5を自前でやることです。4に対する5の利点は、オレオレではないこと、reduxミドルウェアやredux devtoolが利用できることです。ミドルウェアの必要性は、各種hooksや導入予定のsuspenseによって低減されている・され得るとは思います。しかしredux-sagaの代替はできないでしょう。ただ確かに、4 vs. 5は考えどころです。
その上で6が登場してきたのですが、5の利点をすべて持ち、sagaなどももちろん使おうと思えば使え、さらに冗長性が低くなる仕掛けが効果的で、Reducerも破壊的操作のように簡潔にかけ(Immer効果)、4,5よりもメリットが大きいので、私としては6をおすすめします。
ちなみに4bはそういう記事を見たのですが、action抽象はビューからロジックの依存を逆転させ、ビューの再利用性や試験可能性を向上させます。ので私としては却下します。
まとめると、Hooks makes redux great again!です。
参考
Vueをおすすめします。
自分の背景：最近、バックエンドからフロントに転向して、そのときに同じくReactとVueで悩んで、自分の場合は最終的にReactを選びました。そのときに調べた内容＋今の所感をまとめます。ちなみに、一昨日くらいから仕事でVueも書き始めました。
Reactについて
- Reactは学習曲線が、かなり急勾配（Vueの公式ドキュメントにその旨書いてあります）。つまり、学習してから、それなりに使いこなせるまでに時間がかかる、だと思ってる。
- 更に、難易度がそれなりに高いReduxの学習も大抵必要
- 更に、ReactはJSの力を最大限に活用する＝ES6+も使いこなす必要がある
- 更に、最近、パラダイムシフトが起きて、ClassComponentからFunctionalComponentに完全に変わったのでライフサイクルも理解し直す必要がある。
- 初学者的には、メリット。ただし、現場のReactのバージョンが古かったりしてClassComponentしか出来ないなら、焦ったほうが良い。
Vueについて
- Vue自体がProgressive な開発を売りにしているので、学習してからすぐにアプリとして導入できる
- ＝ただ、その分、緩い書き方を許容している分、特にコードがカオスになりやすい
- Vueを導入しているプロダクト自体も、ゆるやかに成長する可能性があり、タイミングが良ければ自分の成長とプロダクトの成長が同時にできる
- Vueを導入しているのは、サーバーサイドが片手間に行う系、など、フロントの人が本腰でやる系、ではないケースが多い
- もちろん、フロント強い系の人がバリバリVue書くケースもある。
- どちらかというと、「管理画面をReactで」、みたいなケースはあまり聞かない（自分の観測範囲で）。
- 日本だと特にVue採用している現場がかなり増えてる。（VueというかNuxt.js ）
VueとReactの対比
- よく言われるのは、VueはEasyでReactはSimple。
- 初学者などをターゲットにしているのがVueで、玄人好みなのはReactな印象。
総括
- 「エンジニアを目指している」レベルなら、そもそもフロント以外にも学ばないといけない内容がメチャクチャ多い。なので、フロントに本腰を入れるのは、その後でもいいかと思う。
- フロントは技術の移り変わりが激しい説もあるし、今は仮想DOMによる宣言的記述可能なライブラリ（React、Vue、Anguler）の全盛期だけど、次はどうなるかわからないので（しばらくは、このままだと思うけど、WebAssemblyか、WebComponentsとかが、出張ってくるかも？）
- フロントエンドのエンジニアとしてはReactを推すが、初心者のエンジニアならVueを推してる。浮いた時間でバックエンド・インフラ・開発手法などなどを学習したほうがいいと思うから。
- 所感：本腰を入れてフロントをやるならReact、そうでないならVue。
reduxとapollo clientで全然役割が違います。
reduxは状態管理を行うためのframe workです。データの永続化云々でなくて、変数などを管理するためのものです。現在はreduxでなく、reactが自前で持っているreact hookを使うべきです。
apollo clientはGraphQLを使うためのframe workです。
求められているシチュエーションが全然違います。まだ、GraphQL使わなくて良いんじゃないか？と思うなら使わなければ良いと思います。
いま react で実装しているものと同じものを react 無しで書けるかどうかだと思います。もし書けない気がするなら、 react のコードを読んで、中で何が起きてるかを追ってみると良いかと思います。
ポイントとしては、TypeScriptという独立した言語はない、ということです。
PythonやRuby3がそうであるように、ベース言語に型アノテーション記法が追加されているというだけです。型アノテーションのあるPythonをPythonではないという人はいませんよね。jsdocで型コメントがつけられたjsをjsではないと言う人もいません。
同様に、TypeScriptは型アノテーションが書けるJavaScriptです(enumやnamespaceは無いものとする)。型アノテーションはすぐにはがせます。それがtscが常にやっていることです。
ごくごく初期は、ReactのサイトでもサンプルコードがJSなのでJS部分のみで回して良いでしょう。
しかし、create react appでプロジェクト生成するときは言語をtsにしておきましょう。なんのデメリットもなく、IDE補完、ホバーによるドキュメント参照、F12ジャンプのメリットはjsとは比べ物にならないぐらい絶大で当然学習の役にも立ちます。静的型を全く意識せずにです。拡張子はjs,jsxのままでもいいし、気が向いたらts,tsxにして、anyを多用します。
そして、props周りで仕様変更のときのバグが多いなと思ったら、propsの型定義をTypeScriptの型アノテーションで行います。まかり間違ってもJSのPropTypesで型指定しようと思ってはなりません。ただの地獄です。
それぐらいで良いのです。
TypeScriptをJavaScriptと別に「学ぶ、使う」と思うのが間違いで、それはそこに自然とあるものです。
最近チャットのシステムを作る機会があり、そこで選択したのはVue.jsでした。
なぜReactじゃなくてVueなのかというと、あまり深く考えてのものではないんですよw 単にJSXが馴染まなかったからです。
また、Vueは日本語ドキュメントが豊富だったというのもありますね。
チャット的なものであればどちらで開発しても大きな差はないかもしれませんが。
VueはNuxtを利用すればさらに今までのWebアプリと感覚も近くなるので、昔ながらのWebシステム開発者からは移行しやすいと思います。
Reactの状態管理、ややこしいとこです。
最近、ようやくわかってきました。
アプリケーション全体のルートの部分でステートを作り
const [値, set値] = useState(初期値)
この 値, set値 この2つを
createContext と .Provider で、下位コンポーネントに配布して
下位コンポーネント側では、useContext でうけとって実行すれば
アプリケーション全体のどこでも、アプリケーション全体のステートの値を取れるし、変更も容易です。ということで、Redux は不要と思います。
そもそもですが React Hooks 関係なく
Reduxは実に使いにくいライブラリかと思います。
React Hooks 登場前から Redux使うくらいなら自作するわと、思っていたのですが、React本体側で非常に便利なものを作ってきてくれたので、今は自作するまでもなく十分に React Hooks のみで対応できると思います。
GraphQLは関係なく、Reduxをdisってしまった回答を最近書きましたので、何か参考にしたり参考にしなかったり適当にしてください。
最新技術を投入して、技術で世界を変える、みたいなモダンでキラキラ案件的なところでは、大体next.js は使われてると思います。next で構築されているところ多いです。
Reactなのに、静的サイトジェネレートで高速webページSEO対策もばっちり、ってところが人気なのではないでしょうか。
プロジェクトではよく使われているのですが、私はあまりnext.js 意識してコード書いていっている覚えがなく、普通にreact使ってるだけの意識低い系のフロントエンドなのかもしれませんが、まあ、普通に仕事しています。
むしろ、next.jsってのは、単にReactを知っているだけで、新たに学ぶこと少なくてもサーバーサイドでのレンダリング処理も行える、という便利フレームワークなような気がします。
なので、よく使われてはいるけれども、next.js をあえて学ぶ必要があるのかどうなのか、というのはわからないところです。
「フロントエンドエンジニアを目指す」とのことなので、最近、勢いのあるゆめみ社さんのフロントエンドコーディング試験が公開されているので、トライしてみてはいかがでしょうか。
自分は4Hくらいで主な処理が出来たので(自慢やで！自慢やで！)、あとは面倒でCSSとかは放置してしまいました。
ゆめみ社さんは、CSSをこだわってる作りをみたいとのことでCSSフレームワーク使うな縛りがあったのですが、個人的にはCSSはもうEmotionで全統一してCSSの命名規則なんてどうでもよくなりそうなので、そこは技術者の仕事じゃなくなった感じするとこです。(Emotionばんざーい！)
普段、プロジェクトに途中から加わる場面ばかりなので create-react-appとかほとんど使った事がなかったので、最初からアプリ作るってどうやるんだっけか、と練習がてらの戸惑いながらでしたが、やったら結構うまくできました。
まちがってレンダリング時に常にRESASAPIを呼びまくってしまい、呼び過ぎたらアカウント凍結されたりして30分から1時間くらい無駄にした気がしますが、
それなりの時間で出来てよかったです。現役エンジニア感出せてよかった。
GitHub - standard-software/yumemi-graph-app
APIキーは、
kfcnhSd0N6aeTCxUCQI8yfgHgiP8Z7EdcNdOu5nj
これ使ったらええで。
「都道府県」をクリックしたら一覧が更新され、チェックボックスでグラフ表示できます。
React(React.jsのことですよね)に限らず、リアクティブなプログラミングは、綺麗な依存関係を持ったモデルから、そのまま画面に表示すべきものが構築できる、というようなアプリケーションの場合はその力を大いに発揮するのですが、一旦時間的な依存関係があり、例えばそれがサイクルを持つ依存関係をもたらすようなことになると、結局は「フレームワークの機能とやりたいこととのミスマッチを以下にすり合わせるか、ということに手間を取られ、「これってもしかしてフレームワークなしの方が良いんじゃないの？」という疑問を持つことになります。
例えば、ビデオチャットアプリのようなものをReactで書いている時に、「コンピューターで使用できるカメラの一覧」を取得し表示したいとしましょう。単純には、そのページが開かれた時にカメラ一覧という論理的な状態を取得することにし、結果を画面に表示すれば良いように思いますが、その一覧を取得するには非同期的なAPIを使わなくてはなりません。しばらくしてリストが取得できると、Reactはそのリストが変更されたことに反応し、そのページを再描画しようとします。そうするとそのコードの中でまたカメラの一覧を取得するコードが走り、というサイクルになってしまいます。
そのような副作用を処理するために副作用フックという追加的機能を使い、その中には依存関係を破るようなコードを書いて良いわけですが、その入力となっているデータの表現を変えないと、場合によってはその副作用フックが何度もなんども実行されることになります(useCallbackを使うなど)。それでその入力状態の表現を変えるために、その入力を変え、というように結局大きなコード変更が必要となることがあります。
ブラウザー用のフレームワークでは、フレームワークが仮定すること以外をJavaScriptで書けることが普通ですが、それは「leaky abstraction」つまりは抽象化のレイヤーを跨いだプログラミングをしているということであり、事実上問題がなかったとしても「美しくない」ですし、実際にはleaky abstractionはプログラムの複雑性を大きく増加させる元となります。
というあたりが辛いところではないでしょうか。
フロントエンドの開発やReact、Typescriptなどは学校で習うものではないのではじめはみんな未経験です。
SPAを容易に開発する技法を提供しました。具体的には、
- 巨大な大域変数としてのDOMツリーを、以下によって分割統治。
- 「Reactコンポーネント」単位でDOM構造の部分的な断片を定義していき、コンポーネントを組合せることでボトムアップにDOMツリーを構築する。
- DOMツリーと同じ構造のバッキングストアを配備して、部分的な更新を行なえるようにする。
- DOMツリー更新を高速にするための最適化を行う。(仮想DOM)
これだけといえばこれだけです。
Reactをよく使っていますが、たいていどの仕事場でも採用されているので、右へならえの日本のITでは、普及しまくるので、シェア的にもう大丈夫なんじゃないですかね。(Vueはよく知らないのですが、シェアもあるので、そちらもある程度安泰ですよね)
Reactのクラスコンポーネントの時は、今どきクラス的なオブジェクト指向かよ、ダッセー。って感じで苦しみが多かったですが、ちょっと前に関数コンポーネント(hooksというのかな)が主流になり使いやすくなったので、他のものに移行する動機はもうなくなりました(よね？)
もはや以前のReactとは全然別モンともいえるくらいのバージョンアップですが、以前のコードも動くわけなので、みなさん便利に移行していることでしょう。
そういうわけでReactはとても使いやすくていいと思います。
以前はReact-Reduxであわせて語られていましたが、状態管理のReduxは廃れて、これもよかったと思います。Reduxは複雑すぎてだいぶいけてなかったでしたからね。Mobxも結局は不要になったりで。
この業界、見極めって難しいですね。いまいちなライブラリが「人気」だから、といって採用されたりします。
ある程度は、自分(たち)で作れるものは自分(たち)で作れるものは作っておいたほうが、自由度も高くてある程度よかったりすることが多いので、
人気だからといってそこまで優れているものではないものを採用するってのは、ちょっと控えたほうがいいだろうな、という感じで、観察眼を養うように心がけています。
じっくり使ってみた感じ、Reactはhooksの機能を見ていると、開発陣は相当頭がよくて、使う人のことをよく考えている優れたライブラリだと思います。
えーっと、Reactの周辺のものは……それぞれですが、広く普及していてもいけてないように感じるものが多かったりするので、自分で使ってみたりして、よく観察してみるのがいいんじゃないかなと思います。
後で廃れてしまったりして、プロジェクト全部のコードが技術的負債みたいになって痛い目みたりする(可能性が増える)んじゃないのかなと思ったりです。
Reduxのコードなんて、プロジェクトによっては今では全部技術的負債になっちゃいますよね。激しい時代の移り変わりで、なかなか大変じゃないですかね。みなさん。
ぼちぼちじゃないですかね。
Vueとか、他の言語のスキルの人も求められているみたいですよ。
フリーエンジニアのIT案件ならレバテックフリーランス
100万超えが相当増えてきたような感じで、またこの数ヶ月で上がってきたような気もします。
単価が高いってのは、それなりに他にいってほしくないから高い金額で引っ張る、って効果があったりしますのでひとつの指標かもしれません。
まあ、一流企業の会社員で役職つきの人とかよりまだまだな気もするので120–150くらいの帯域で仕事がどっさり増えるといいなあと思ったり。
Pugそのものは単なるテンプレートエンジンなので、比較する対象としてはReactよりも内部で記述するJSXですね。
ReactでJSXの代わりにPugを使うこともできますので、必要なライブラリ等の導入は大変ですが、記述量を減らす役には立つと思いますよ。
それって比較できないと思います。
ハンバーグのどんなところがひき肉より優れていますか？っていう質問と同じです。加工しなくても食べれる、保存が効くくらいですかね。それって優れてるっていうのかな。
reactとjsをくらべると、reactはjsよりすぐに具体的なものを作れますね。
Reduxは、Reduxを使わずにいた場合の複雑さが、とても耐えられなくなったときに耐えられるように低減するために使うものです。
Reduxが難しいと感じるなら、Reduxが解決するかもしれない問題がまだそこまで難しくなっていないのでしょう。
あと、スターターキット使うと相当かんたんになってますよ。
変化の激しいフロントエンド界隈ですのでコロコロとおすすめが変わりますが、個人的にはReactをおすすめします。どちらもメジャーですが、定量的なトレンドや開発コミュニティの盛り上がり方を見るとReactに軍配があがるのではないかと。
別に必ずセットで使うことが保証されているものでは無いですからね。
調査の目的によっては、Reduxが範囲に含まれない場合もあるでしょう。その場合、Reduxを含めるのは無駄です。関連する技術を全部調べていると時間がいくらあっても足りませんからね。
そしてその場合、Reactが簡単だったのは事実ですし、嘘じゃありません。
何となく自分が知っていることを相手が知らないから批判するのでは、本質を理解しているとは言えず、そっちの方ができないやつっぽいですよ。
もちろん、それなりの規模のSPAを作成するための調査としてReactを調べた結果その知識だと、ダメですけどね。
回答つかないですね； きっと他に例えて理解できる代物じゃないのかもしれません＞Next,Nuxt。
実は次期プロジェクトでNuxtの使用が決まっていて、Nuxtなにそれ？を調べているのですが、難しいですね。正直、いつまでたってもすっきり理解できた気にならないです。いろんな解説を読んでNuxtで何ができるのか？はわかる気はしてきますが、じゃあ、なるほどコレはアレだ！という納得がおりてきませんTT
私の次期プロジェクトはSPA開発なので、であれば必ずしもNuxtは必要ないような気もします。だとしてもcreate-nuxt-appから始めた方がその後の作業の展望がしやすい気がします。通話しかしないならガラケーでも十分だけど、通話しかしなくても電話帳が管理しやすいのでスマホにする価値はありそうです。
まあ本丸はSSRですよね。同じコードをサーバーサイドでも動くようにできるんじゃね？と閃いたんだと思います。携帯電話に液晶つけてみたら、いつのまに液晶だけになったスマホがPCを食ってしまったように、Nuxtは従来のRailsの領域を一部食ってますよね。ガラケー（react,vue）まではそこまでの危機ではなかった。ということでガラケーとスマホほど違うと考えるので良い気がします。どうでしょうか？
stateは仮想DOM(ブラウザが保持する実DOMと同型のJSインタプリタ内に閉じたデータ構造)の中に保持される、Reactコンポーネントが保有する状態の領域のことです。
stateはReactコンポーネントのインスタンス化・マウント時に初期化され、マウスイベントなどのイベントハンドラの処理においてthis.setState(),もしくはuseStateの返り値の第二要素のセッター関数の呼び出しによって更新されます。
stateの更新は、そのコンポーネント及びその子供コンポーネントのrender()、関数コンポーネントであればその関数の再帰的な呼び出し(及びそれに引き続くリコンサイラ処理)を引き起こします。
propsは、このrender()の呼び出しにおける意味的な引数であり、親から子供へ、任意の値を伝播させていくために使用されます。
関数コンポーネントの場合は、propsはコンポーネントを表現する関数の実際の引数に対応します。
Railsを6年ほど書いています。Vueは2年程度、Reactは未習です。Vue3をそろそろやらねえとなあつらいなあと毎日嘆いています。
気になるプロダクトがどちらで書かれているかで決めるのがよろしいかと思います。多分Reactの方がいいんでしょうけど、小規模開発でサクッと動くものが作りたいのならVueでよろしいのではないでしょうか。
Reactの初心者かどうかはほとんど関係ないと思いますよ。
そもそもプログラムが初めてならReactがどうかに関わらず時間はかかると思います。
チュートリアルにTodoアプリ？が必ずあると思いますが、そこを理解した上でなら「認証」がどういったものかによりますが一日数時間作業で数日で十分できるのではないでしょうか？
他の言語がある程度できる方でしたらそれは単純にプログラムの問題じゃなくてReactと他の言語の違いの戸惑いだけですので数時間って言う感じですかね？
あくまでチュートリアルのTodoが終わってて、そこに認証を付け加えるような意味合いでの想定です。
現時点の話であれば、今風だなと思うかもしれません。では、1年後は？5年後は？
自分も現役時代は、パートナー企業からこんな技術者がいますとポートフォリオというか、職務経歴書的なものを見せていただくことがありました。その手のものはMERNだなんだなんてレベルまで書いてあることは少なくて、WindowsでVisualC++で〇〇アプリ作ったとか、LinuxでJavaで〇〇システム作った、程度のことしか書いてありません。でも、それで十分なんです。
技術者を探す側として職務経歴書とかポートフォリオを何のために見ると思います？求めているターゲットの技術スキルや、業務レベルを理解しているか、あるいはできそうかを確認するために見る訳です。ああ、この人は色々やってるなとか、この人はWeb周りに特化しているな、とか。
ポートフォリオが元々は金融関係、投資関係で使われている言葉だということはご存じかと思います。例えば、株のポートフォリオといった時に、どこそこの会社の株があるということ自体にはあまり意味がありません。そうではなくて、投資対象としてどういう対象を選んであって、こういう状況の時に伸びる、伸びないを考えてリスクヘッジできているか、全体としてどう構成されているかを見る訳ですよね。（って、投資は大してやってない自分が言っても説得力がないですけど）
エンジニアのポートフォリオだって同じです。ポートフォリオの中の個々の案件を単独で見たってあまり意味はありません。どういう立場で、どういうシステムをどう経験していたかを総合的に見ます。
その認識が誤りかもしれませんし、そうではないかもしれません。
それはともかく、クラスコンポーネントにせよ、関数型コンポーネントにせよ、あるいはVue3にむけhooks採用含め、どんどんReactに近づいているなあという感想です。良いことです。
Vueのよさはかなりの部分、アイデアやツール含めReact発のイノベーションから来ていることは確実にあって、昔からそうで、これからも多分そうで、それはVueの良さで、だから利用者が減ってReactの開発が活発でなくなると、Vueにとっても良い事はありません。
簡単ではないと思います。とはいえ、
Vue is Easy , React is Simple
というのはよく使われる表現でして、私自身どちらも使いますが、まったくもってそうだなぁと感じています
なので、簡易さを求めるならReact Native より Vueでしょうね
ただですね、Vueでアプリを使って開発するということは、それはブラウザ上で動くんですね。ハイブリッドアプリとか言われてます
React NativeはAndroidやiOS上で直接動くようなものです
そうすると、タッチしたあとの画面遷移の軽快さ一つとってもReact Nativeに圧倒的に軍配があがります
ハイブリッドアプリもチューニング次第で近づけるんですが、初めて作ってみる難しさとは比較にならない難易度の高さです
そこが判断基準になることが多いですかね
ちなみにReact.jsでハイブリッドアプリという選択肢もあったりしますよ
そして、本題ですが、本流はReact Nativeな気がします
「アプリですか、React Nativeでいいなら人員用意できますよ」という開発会社がなんだか多い気がするためです
ただですねぇ、Angularが、、、な空気感も出ちゃってる昨今、フロントエンド界隈では、これやっとけば安心みたいなことは絶対にありません
スキルを装着してもそこで慢心せず、常にモダンを追い続ける気概と努力が必要です
なので言ってしまえば、どっちでもいいんじゃないですかねってところなんですが
個人的には途中で嫌になる可能性が低い、Vueで普通にWebサイトとして動くものを作る
から始めるといいんじゃないかなぁなんて思います
VuexとかNuxtとか使ってみてそこで得た知識はReactになると、全く活かせないなんてことは全然ないですよ
jQueryの主な機能はホストオブジェクトの操作でDOM操作と非同期通信です。
この二つは実装によってかなり機能が違うので、jQuery経由で扱わないとなかなか大変です。
Reactがやっている主なことは、ブラウザ側の本物のDOMと別に、React内に別の仮想的なDOMを構築して、その操作を通じてDOMの複雑な操作を行うというものです。
Reactを採用すると、jQueryの機能と重なるだけでなく、DOM等の操作が干渉する可能性が高いので、jQueryは使用しないのが普通です。
仮想DOMはすごく便利とか革命的とか言われますが、実装によってかなり癖が強く流儀に合わせなくてはならないことや、結構重たいことなどから私は採用していません。
DOMの中にdata-hogeタグを書き込んで、そこにDOM操作に必要なデータを書き込むようにして、jQueryでDOM操作するインハウスのツールを作ってます。仮想DOMほど大掛かりでないのでデバッグもしやすく、操作もとても軽いので今の所気に入っています。
仮想DOMは長期的にはブラウザが賢くなって廃れていく、もしくはブラウザに取り込まれると思ってます。
1つはタイミング。SSRは初回表示のみで実行され、RSCはアプリ実行の全般で実行されます。
次に、SSRはルートとなるコンポーネント(普通はページ全体)の子供全てをサーバサイドでHTML化します。
これに対してRSC(React Server Component)はルートとなるコンポーネントの子供や子孫のうち、サーバコンポーネントのみ、つまりクライアントコンポーネントを除いた部分のみをサーバサイドでHTML化します。(歯抜けのサーバサイドレンダリング)
歯抜け部分をプレースホルダとして、レンダリング結果はクライアントにHTMLに対応がつくとある形式で転送され、歯抜けだったクライアントコンポーネントの部分が充足されるようにクライアントサイドレンダリングが部分的に行なわれ、仮想DOMを経て全体が実DOMへマップされます。
なお、再レンダリングの動作は、情報転送の単位としてはページ全体の転送なのですが、クライアントではクライアントコンポーネントの部分を上書きせずに、propsのアップデートになるように、状態が保存されるように、合成が行われます。
SSRと比べると、サーバサイドでページ全体を完全にHTML化するのではなく、クライアントレンダリングする部分を「残す」のが違いということになります。またRSCにおけるサーバコンポーネント部分は、SSRとは異なりクライアント上では絶対実行されることはないので、nodejs固有の機能を使ったりでき、またサーバコンポーネントのJSコードをクライアントに転送しないことでバンドルサイズを小さくするなどができます。
RSCにはSSRの目的である初回表示の高速化やSEO対策の利点はありません。なお、初期表示SSRで後続実行をRSCにつなぐ併用の可能性はあります。
参考
OSSに戦争も勝ち負けもありません。お気に召すままの方を使えばよいでしょう。
Angular vs React: 5 Key Differences - The Official Tabnine Blog
妖精さん！
あなたの願いを叶えましょう。
ポニーとお話がしたいの！
で、AngulerとReactのどちらを使うべきかというと？
0 コメント:
コメントを投稿