まえがき
現在の認識。雰囲気を掴むために。
設計思想・背景は置いておく。
できるだけ簡単なJavaScript知識で例えて、難しい部分は脇においておくが、誤解は恐れているため誤解させたくはない。
React.jsとは～という巷の諸解説が既に難しすぎるので、これで噛み砕いてから挑みたい。挑みたい…
本当にHello Worldもしてないのにしったかぶって書きます
まとめ
- 耳慣れない単語が多いけど、要はDOMを作る関数を作って使っていく感じ
- 書き始めるために覚える必要がない単語もよく出てくるよ
- Reactはネイティブの書き方とコンパイルが必要な書き方の2パターン
- コンパイルする方ならnode.jsのwebpackの勉強が必要(とnpm)
- 頑張ってwebpack勉強した方が他にもよく使うし、記述が楽になると思うよ
- Reactを使っても、全部1ページでこなす必要は無いよ。ページの考え方は今までのままでもOK!
- 旧来のDOM操作は出来ない！全部React経由でね。
- 旧来のDOM操作は出来ないから、jQueryのDOM操作も使えないよ。ただそれだけ。
- 動的書き換えのための通信まではカバーしていないから、なんとか頑張って。
$.ajax使ってもいいのよ。
Reactってなんですかそれは
JavaScriptでHTML(body内)を書きます。
HTMLで作るコンテンツの大体を書きます。
ただ、古いPHPの様にHTMLを文字列で打つのではなく、関数とデータで作ります。
コンポーネントってなんですか
関数です。HTMLのパーツです。関数です。HTMLを作る関数と、内容を書いたJavaScriptの普通のオブジェクト{}との組み合わせです。
作ったHTML反映するぞ
HTML作るぞ({こういった内容で作るぞ})
Reactさん「おう、処理してやんよ」
ネームでつまづきポイント。
バーチャルDOM、一方性ってなんですか
最初はわからなければ意識しなくていいかもしれません。
JavaScriptでHTMLをまるっとまるごと作る。あとから(DOMの直接操作で)微調整はしない。
程度に捉える。
説明されると難しいが、知らなくてもなんとかなる可能性があるポイント。
Fluxってなんですか
(ひとまず)考えなくていいです。
機能やツールではなく考え方なので、理解を前提としなくても大丈夫です。
大事だけど説明始めるとお話広がっちゃってるポイント。
Reactってどうやって書くの
ネイティブの構文で書かれたそのままのReact関数を使う方法(以下、生記述)と、JSXという糖衣構文を使う方法があります。1
どちらで書いているのかは、話題の中で略されている可能性がある。
記述量が多いらしいけど
- 関数にすると、行数が増えることは経験があると思います。その現象かも
- 生記述では確かに記述量が多く見える。
->JSXでは糖衣構文らしく記述量が減ります。
2で齟齬発生ポイント
JavaScriptの中にHTMLタグが入り混じっている…
<?php echo '<div>'; > う…頭が…
JSXの文法がHTMLに似ているだけであり、直接HTMLを書いているわけではありません
コンパイルされると普通のJavaScriptになります。
onClick=～というゲッっとなる記述もでますが、イコールHTMLのonClickとはなりません。
初見、忌避感・誤解ポイント
総じて
解説の中で生記述で見たときの気になる点と、JSXで見たときの気になる点などが頭の中で入り交じることがある。
トランスコンパイラが必要と聞きました…
生記述を使った場合は不要。
ただし、JSXを使った場合は糖衣構文なのでコンパイルが必要になります。
その場合はnode.js環境と、webpack2を使ったトランスコンパイルが必要になります。
誤解・導入躊躇・挫折ポイント
じゃあJSXを使わなければReact.jsだけ勉強すればいいんですね
今はそう認識しているが、風潮やら記述のわかりやすさを見ていると、挫折しそうな雰囲気を感じる。
生記述 -> 記述が大変で死ぬ。サンプルコードの多数がJSXで死ぬ…かも。
JSX -> node.js、webpackから派生するエコシステムと、高速参勤交代並のトレンドの移り変わりで死ぬ。
そういった印象です。
関係薄いですがyarnとか湧き出ている感じをリアルタイムで体感中。
画面遷移せず、一枚のページを書き換え続けることで各ページを表示することについて
実践的かつ本質的に正しいと思われるが、簡単に考えるとまずは関係ない。かも。
ReactはHTMLを作るものと捉え、MVCのVと考えれば、テンプレートエンジンの変わりに1ページ1Reactで画面を表示することも当然できると思われます。
ついでにAjaxから結果を受けて、valueをいじったりしていたところをReactで書き換えれば、Reactの書き換え処理、Reactの扱いがわかると思います。
このレベルなら、テンプレートエンジンの置き換えレベルで挑戦できるのでは？
HTML(DOM)を、好きなHTMLを作る関数で書き換えるという考えを拡張すれば、データだけJSONで受け取り、書き換え続けることによってページは一枚で済むということも可能になる。
でも、それをする必要は今から学ぶ初心者にはそこまでする必要を感じていない。といった感じです。
壮大な表示手法の変更っぽいことも可能ゆえの躊躇ポイント。
余談のURL
DOMを書き換えページ遷移したように見せかけるように、URLの表示を変更しているときがある。Qiitaとか。
そのURLならこのHTML、と考えれば、最初はページ遷移しちゃっても別にいいんじゃないかなあ。
生DOMをさわれないと聞きました
書き換えについては、
ReactがDOMデータをレンダリングごとに、JavaScriptオブジェクトで持つ表示データから作ったDOMでまるごとドンと置き換えるようにみえるのですが、(仮にそうでも結果的に生DOM触れても次レンダリングで無駄になりますよね)
レンダリングのときに、前回のレンダリング結果の(DOMツリー)と、今回作るレンダリング結果を使うので、Reactだけで操作していたDOMを横から操作していると、前回のレンダリング結果との不正合が起こります。
ReactがことDOM操作については排他的とも言えそうですし、単純に相性が悪いで済ましてもいいと思います。
生DOM操作していたところはReactに適した形でStateを書き換える～っといった、「できない」ではなく「別の方法・アプローチがある」ということが可能かもしれません。使ってないのでわかりませんが。
毎回DOMを全部作り直すのに、差分表示が高速とはどういうことですか
差分、ということを考える必要はありません。
生DOMを部分部分で書き換えるのではなく、
作ったHTML反映するぞ
HTML作るぞ({こういった内容で作るぞ})
Reactさん「おう、処理してやんよ」(再掲)
という風にDOMをまるごと作る記述をするのですが、
Reactさんが処理する中で、差分をとって、そこだけ変更してくれます。
つまりReactさんは賢い。
書き手は常に完成品のみを考えていればいい。差分うんぬんはシステムのお話だと思います。
Reactを使うとjQueryが不要(邪魔)って本当ですか
見出しの質問に関してはNO。
Reactを使っても、jQuery自体は使えます。
jQueryの機能のうち、主観的によく使われると思われる、DOM操作は前述の理由で使えません。
ただし、DOM操作以外の機能もあるため、それに関しては使えます。
…わかりづらいですよね。
なので、当時はjQueryを不要とする記事でのコメント
「$.getJSON('/api/items').then」のところjQueryじゃないなら何使ってるんだよ、そこ紹介してくれよ！！
というのは非常に頷けました。
主語が大きかったり色々省いていたり背景がぞろぞろあったりで、要るのか要らないのか非常にややこしい。
ので、もう少し噛み砕きます。
ネイティブJSとブラウザは進化した！
React関係無しに。
昔はjQueryを使わないと簡単には出来なかった処理が、APIの充実とともに、ネイティブのJavaScriptでもいろいろ書けるようになってきました。
しかし、できるというだけで、
- ブラウザ互換性
- 学習コスト
- 記述の書きやすさ・読みやすさ・保守性
などなど…主に後者。を忘れてはいけません。
jQueryを使わない理由になることはあっても、不要な理由にはなりません。
…ニュアンスを感じ取って下さい。
なくてもできるし、あっても別の書き方でできる。
jQueryを捨てることができるという選択肢が見えてきた状況、でしょうか。
要不要の論点が食い違っちゃったりしちゃいそうなポイント。
ReactとjQueryのDOMを操作する主機能群は相性が悪い
生DOMをいじるという繰り返しの説明なので省略します。
jQuery不要のいち構成要素かと。
Reactは簡単なAjax機能までは提供してくれていない
ReactはWebAPIからJSON受け取ってDOMを書き換える？
じゃあ通信は？
$.getJson？
jQueryじゃねーか！
という。
DOM操作部分の相性の悪さからjQueryのDOM操作機能をまるごと受け付けなくするReactの強制力がありながら、DOMと無関係な部分はjQueryに頼っているややこしい構成ですね。
ここだけ見ると言行不一致にも見えるポイント。
そのためだけならjQueryじゃなくていいよね
Reactを使うことで、jQueryを読み込んだとしても、(主観上)よく使われるDOM操作を使わず、僅かな$.ajax系のみ使われるのならば。
それはそれでもいいのだけれどajaxの機能だけを提供してくれる小さなライブラリとか、もっとjQuery以外の道もあるよね？
と言えるようになります。
jQueryがReactにより大半の機能を封じられた結果、残った部分を別ライブラリ(あるいはネイティブ)で補うことが現実的になり、
jQueryを捨てることができるという選択肢が見えてきた状況、でしょうか。(再掲)
そしてjQueryはサイズが大きいよね
見出しそのまま。
結局、不要っぽい論調->jQueryいいとこあるじゃん->jQueryじゃなくてもいいじゃん(ファイルサイズもうんぬん…だし)
という、記述不足・読み落とし・スタンスもろもろによって灰色になり、なんとか自分で飲み込むしか無い状況なんだと感じています。
まとめは初めに
謎
- 実際にどう書いてどうレイアウトを組むのか
- MVCフレームワークならテンプレートエンジン全殺しで、サーバーサイドはReactと入れ物のHTMLだけを返すものとJSONを返すだけのものになりそう
- 1ページで全部こなすとすると、最初の読み込み時点で全ページ(扱い)のReactの記述を読み込み、使い分けるの？大変そう
- JSXを使うならnode.jsまで管理しなきゃいけない大変さ
- コンポーネントの再利用性？
- React以外、通信以外のJavaScript処理って何があるんだろう
- サーバーサイドは、今までのDOM操作と同じく、JSONを返していけばいいのだけれど、書き換えるデータだけを渡していた今までと異なり、DOMの構造の記述までサーバーサイドのビュー以外の部分にJSONとして書かなければならなくなるのではないか？
流し見した記事
Reactタグをフォローすらしていない自分は、ほぼはてブなどで話題になった記事しか目に入っていません。
それと裏付けのために少し調べたものを。
-
JSといえばjQueryだったWebデザイナーが、Reactを1年間使って感じたメリット | dwango creators' blog（ドワンゴクリエイターズブログ）
データバインディングとコンポーネント指向の画像がとっかかりをつかみやすい -
Reactを使うとなぜjQueryが要らなくなるのか - Qiita
他の記事も読み、数週読むと意図がなんとなく読み込めてくるのですが、最初はうまく飲み込めませんでした。 -
You Don't Need jQuery - Qiita
投稿者の追記と最初のコメントが(それがなかったことが)、結局誤解を生む根底なのかなあと今回は思いました。 -
jQueryで楽になる部分、楽にならない部分、顧客が本当に必要だったもの - Qiita
上記の記事(の反応)をうまーく噛み砕いてくれます。上記記事の投稿者のコメントも含めて。jQueryと十把一絡げすると…。座標系についてはよくわからないのですが。 -
あなたがReactを使うべき理由 - mizchi's blog
結局mizchiさんなのですが、ここまで上から順番に見ていると、だいぶわかりやすい言葉遣いで書かれているんじゃないでしょうか。
もちろん最初に読んでもわかりやすいだろうと今なら思います。
生でもいけるかもしれないという可能性の記事。
-
なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita
当時は全くわからず、今は前よりほんの少し前進。
結局$.ajaxはどう代替するのだという問題は自分の中で解決していません。
とりあえず製品にはならないのでjQueryですまそうと考えているのですが、ネイティブでさっくり書ける可能性はあるのかという問題。
では、Reactの前にBabelとwebpackの勉強に戻ります。