Vue vs React vs Angular Part.2
レス数が1000を超えています。これ以上書き込みはできません。
実際どうなん？
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
-
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured
※前スレ
Vue vs React vs Angular
http://mevius.5ch.net/test/read.cgi/tech/1545395856/
★ここではjQueryの話題は禁止です
★jQuery房が書き込んでも無視してください ちゃんと料理するのが目的ではない。
食べるのが目的
手早く物を食べられる時代に自分で料理するとかマヌケがすること
自分で料理したからって美味しいものができるわけではない
フレームワークなんていらない 動的にフロントをカスタムってよく分からんが素のCSSを一から書きたくないから使うんだろ >>901
手料理なら健康だって勘違いしてる人？
外食だって手料理なんだが コピペで解決するようなことばっかしてたらコードが腐るって話だよ。 なんだまともにプログラム書いたことない人か。そりゃ話が通じないわけだ。 if else if else if if if if
みたいなやつ 100歩ゆずって論理的に場合分けが不十分でいかにもバグりそうな書き方は腐ってると思う
真理値表で no care が多すぎみたいなやつ なんかもう全部blazorでええわってなってきた
さようならjavascript メタタグにblazorで作ってますって書いとけよ。
中身ないくせにバカみたいな激重サイト開きたくないんでｗ componentが受け取るpropとか型あったほうが絶対ええやん 型はあったほうが良い。理由は型があったほうが絶対にいいからだ。 型はないほうが良い。理由は型がないほうが絶対にいいからだ。 書くコード量が増える
キャストがめんどい
オブジェクトの型宣言がめんどい ReactとReduxを入門したばかりの者ですが、react-reduxのconnectを各コンテナで行う意味がわかりません。Providerみたいに最上位コンポーネントだけで行えば？って思ってしまいます。詳しい方教えてください。 >>921
どこからでもアクセスできたら意図しない書き換えがあったときにどこで書き換えられたのかが絞りにくくなるとかいう思想からじゃない？ あとReducerの分割はstoreのを複数の要素で構成させるためですか？うまく説明できなくてすいません。 型がないと扱ってる変数の型が途中でキャストされてこちらが期待する型と一致しなくなってバグの発生に繋がるから、無いよりはあった方が良い。
それに型付けをきちんとしていれば、変数に間違った型の値を入れようとしてもIDEとトランスパイラが教えてくれるからバグの発生を防げる。
型宣言は面倒くさいかもしれないけど、ちゃんと定義しておかないと
プロジェクトが大きくなった時や過去のコードの整備する時に困る事になるよ。 >>922
fluxってグローバルにstateを管理するためのものじゃないんですか？
コンテナの子要素としかstateを共有しないという理解でいいですか？ >>923
別に並立でドーンって並べたいなら並べてもいいけど
機能ごとに状態グループを分けた方が管理しやすいじゃん？ >>925
だからConnectで使う状態とSetterを書いたコンポーネントからだけアクセスできるようにするモノ
四階層くらいコンポーネントをネストしてたら有効なもんだと分かると思う
あとredux-persistとか使えばブラウザのlocalStrageに状態を保存できるからリロードでも飛ばない状態が作れる >>926
https://ideone.com/wVwkT7
こういうstoreのとき
https://ideone.com/V4THFe
こういうreducerみたいに分割しないとネストしたstoreはreducerで定義できないんじゃっと思って。。。 >>928
つまり、storeのキー名と同じような名前のreducerを定義しないとstateで表現できないんじゃということです >>920
> 書くコード量が増える
書く量が増えるよりも、読む時にすばやく間違いなく読めるほうが重要 型は読むとき素早く間違いなく読むためのものではない。
コンパイラに論理的間違い探しをさせてあとで指摘させるために与える付加情報だ。 ていうかStoreに定義は書かんけどな
actionとreducerがあればいい >>933
reducerでstateいじったら自動的にstoreの要素に追加されるということですか？ >>934
react routerとセットになってるヤツだけどこれのexamplesみてどういう風に書かれてるか追ってみるのが一番手っ取り早いと思う
https://github.com/supasate/connected-react-router >>920は単に意味のない問答じゃない理由となり得る理由を挙げてみただけ
実際TS使う恩恵は>>931じゃなく>>932だと思う
ソースを読むのに必要なのは変数の型がなにであるかよりも変数が何に使われてるかで
読む際に助けになるのは型名じゃなく分かりやすい変数名
ロジック的な誤りは読んでて見逃す事もあるしな Angularの公式サイトってChrome以外で見ると重いっていうか場合によってはロードできないみたいだな >>937
> ソースを読むのに必要なのは変数の型がなにであるかよりも変数が何に使われてるかで
> 読む際に助けになるのは型名じゃなく分かりやすい変数名
それが成り立つのは、変数の型が文字か数値の場合だけ >>939
変数がオブジェクトの場合なんて尚更読みやすさのためじゃなくオブジェクト形状の妥当性の為に型を書く意味合いが強いじゃん 【速報】金券五百円分とすかいらーく優侍券をすぐもらえる
https://pbs.twimg.com/media/D8I_wvBU8AAkV4V.jpg
① スマホでたいむばんくを入手
② 会員登録を済ませる
③ マイページへ移動する
④ 招待コード→招待コードを入力する [Rirz Tu]（スペース抜き）
今なら更に4日18時までの登録で2倍の600円の紹介金を入手
クオカードとすかいらーく優待券を両方ゲットできます。
数分で終えられるのでぜひお試し下さい。 >>948
アロー関数「（あれ？なんで俺、、この世に生まれたんだろ？）」 func.call()にはthisパラメータ上書き機能まであるからな >>942
掲示板荒らすなってレビューすればいいのか？ 余談だけど
米オーディオ機器ハーマンの
Flashの移行サポートに使うフレームワーク
アパッチロイヤル？どうなのかな。
https://royale.apache.org/
https://services.harman.com/partners/adobe
ASって殆どTypeScriptだし
開発凄く楽そうなので興味はあるが。 Reactできる人が羨ましいっすな
よくわからずで挫折してもうた 流行ってるのが羨ましい
Angularは何とかギリギリ理解できてるから今後もっと流行ってくれないかなぁ・・・厳しいか＾q＾ reactは一歩一歩勉強できるツールなわけだが
どいつもこいつもその一歩一歩やることを拒否しやがる。 ①環境構築済みで
②コンポーネント作成者ではなく利用者側の場合、
めっちゃ簡単じゃない？
難しいのはreactではなくreduxの間違いでは？ reduxを使うからと言ってすべての状態をredux管理にする必要はないなって思った
ｒｅａｃｔ routerを使う場合にrouterを跨ぐ情報はreduxで管理した方が便利だし
routerを跨がないものは移動時のデータの破棄がひと手間になるからuseStateとかで処理した方がシンプルかなって それだったら分けずにreduxでまとめた方が俺は楽だけどな。 コードが少なければ少ないほど、変更する時に変更するコードが少なくなるんだが、
Reactとかreduxとか、コードが増えるので保守性が下がってる。 こういうバカはそのうちコードを書かずに人に命令するのが一番とか言い出す。 >>954
もう序盤も序盤でつまずいた
https://jsbin.com/ragufuguwe/1/edit?js,output
これを、
「何でキー入力でタイトルをリネームするのにファイルをまたぐんだろう？
そのままHeader.jsにぜんぶまとめた方が管理しやすいのにな」と思ったりね
（今思うとこれはApp.jsのstateをHeader.jsに渡す(共有)ための作業なのかなと）
低レベルなアレですまんw vueでcomponent間に微妙な空白ができるんですけど仕様でしょうか？ >>964
命令された人がコード書くじゃん
お前馬鹿なの？ >>967
さすがにそれくらいはわかるか。よかった。 じゃあ話を戻す
コードが少なければ少ないほど、変更する時に変更するコードが少なくなるんだが、
Reactとかreduxとか、コードが増えるので保守性が下がってる。 >>965
その小さすぎる例では理解し辛いだろうけど
機能やデータがそれぞれ「どこにあるべきか」というのは大事だよ
分割もバランスではあるけど
システムの規模が大きくなるにつれて管理しやすさは逆転し得る >>966
Vue使ってるけど気になったことないな
あとそんな仕様は聞いたことないが 「コードが少ない」の意味がだいぶ曖昧。
別に高圧縮かけた記号列が保守性が良い訳ではない。
つまり概念が直行してることが重要なわけだがそういう考察もなく
react, reduxのコード量だけで判断しているのはだいぶ愚かとしか言いようがない。 >>972
そんな定義次元の話してないよ
コードの量って言ったらステップ数に決まってる Reduxを使うかどうかは場合に応じて臨機応変にだと思うがな
フォームのパスワードみたいな値とか特にReduxで持つべきではないと思うしpersistで持つとかもってのほかだし
逆にログインセッションみたいな値はReduxにpersistで持つのが望ましいと思う
とは言っても特定の頻度でサーバー側にステータスチェックを投げるのは必要だとも思う 問題は、Reactのサンプルで、Reactを使うような例が
思いつかないってところなんだろうな
むりにつかっても、React使わないほうが
シンプルに実現できるじゃんって思われてしまう。 SimpleというかRecyclableにする為に使って大規模になった時に結果として使わないよりもシンプルになるってところかな ウェブでOfficeソフトを作ってまーすってのならわかるが
ほとんどのサイトは大規模になることはないというね そらWebサイトならWordPressなりWixなりで作ってりゃいいだろ
その分野に関しちゃフレームワークの出る幕も俺の出る幕もありゃせん >>966
原因調べないと何とも言えないけど、多分vue と言うよりかはbuefy や vuetify みたいなUIフレームワークが関与してる気がする。
原因を調べるならchrome の開発者ツールで空白の気になるcomponent 要素のcssを見て、
そのスタイルが何由来で当たってんのかを調べてみれば？ >>973
一つのステップに暗黙の動作を詰め込んだ言語だったら同じだろ。
それが本当にデバッグしやすいかと言えば全然そんなことはない。
ステップ数でなんでも測ろうとする奴が行き着くところが
自分でやらずに人売りするべしって発想だよ。 >>980
暗黙の動作を詰め込むとかデバッグがどうとか的はずれすぎるｗ
暗黙の動作を詰め込まないようにしつつ、コードは少ないほうが良いし、
デバッグしやすくしつつ、コードは少ないほうが良いだろ
なんでコードを減らすと、暗黙の動作が増えてデバッグしづらくなるって思ってるんだろ？ 単純な見方しかしてないのがよくわかる。
マクロを使うことで極限までコード量を減らすことはできるが
全く保守性はよくなってない事例を知らんだけの無知野郎にはこれ以上何もいうことは無いわ。 直交性とコードの量は関係ない
直交性かつコードの量 vueとかjqueryとか色々隠してて使いやすいけど後が怖いよ Windows APIとか色々隠してて使いやすいけど後が怖いよ よくわからんけど
高度に記号化されてコードが短くなってもそれで必ずしもわかりやすく
バグが出にくくなってるわけじゃないってことを言ってるんではないかな AとBが無関係。
そして、Aの中でコードが短ければ短いほど良い
コードっていうのはステップ数のことな
だーれも変数名を1文字にしろとか言ってないから それこそ誰も言ってない
複数行のコードが一行になったとして
aaa :: ?>?>? = bbb ?!!!? .kkk + aaa,dddd<=> ccc!!!?!!! ;
みたいな呪文コードだったら嫌だろうし生産性は落ちるしバグがでるだろうよってことだろさ >>989
>だーれも変数名を1文字にしろとか言ってないから
そうなんだよな
メモ帳で開発してる奴が居たら知らんけど さっきの記号コードで中で一か所評価順をミスっててバグが内部に出ていても
デバッグが異常に難しい
普通のコードのほうがメンテナンス性が高い >>990
> aaa :: ?>?>? = bbb ?!!!? .kkk + aaa,dddd<=> ccc!!!?!!! ;
> みたいな呪文コードだったら
だからだーれも変数名を1文字にしろとか言ってないから ＞ コードが短ければ短いほど良い
そんなことはない
わかりくいコードはいらない
perlでも触ってたらいい 可読性は読みやすいコードって勘違いしているやつが多いが、
読むコードを減らすことが本当の可読性
>>990みたいなのは読むコードが減ってない 関連するコードがあちこちにバラバラに成ってるのは良くない
VueとかReactとかはばらばらになってしまう それと同時にHTMLとJavaScriptという分けるべきものが一緒になって
可読性が下がっている。 レス数が1000を超えています。これ以上書き込みはできません。
