Vue vs React vs Angular Part.2

1 名前：デフォルトの名無しさん [2019/03/09(土) 22:02:33.71 ID:47IMMy0/.net] 実際どうなん？ 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 mevius.5ch.net/test/read.cgi/tech/1545395856/ ★ここではjQueryの話題は禁止です ★jQuery房が書き込んでも無視してください 321 名前：デフォルトの名無しさん mailto:sage [2019/04/10(水) 00:47:58.78 ID:92CfBwCq.net] Angular1の方が好評だったってこと？ｗ 322 名前：デフォルトの名無しさん mailto:sage [2019/04/10(水) 00:52:39.92 ID:UQDjmvEN.net] angular使うくらいならvueの方がええわなぁ reactは論理性高いから日本人には不向きやろなぁ 323 名前：デフォルトの名無しさん mailto:sage [2019/04/10(水) 01:08:10.98 ID:92CfBwCq.net] ググってみたけどreactはhtml側ではあまり小細工しない感じだねえ 論理的というのがいまいち分からないけど 324 名前：デフォルトの名無しさん mailto:sage [2019/04/10(水) 02:32:35.33 ID:RXzVAjqo.net] 個人的にはbackbonejsが好きなんだけどなあ。自分で自由に作れるし 有名どころ使ってるのに、扱いが微妙 325 名前：デフォルトの名無しさん mailto:sage [2019/04/10(水) 10:00:46.62 ID:/ZyB4+jc.net] そういえばchromium版Edgeのプレビュー出たけどおまえら使ってみた？ 326 名前：デフォルトの名無しさん mailto:sage [2019/04/10(水) 10:11:11.18 ID:AVnP0KfU.net] >>320 これ以上進化する予定のないものが残るわけないじゃん 327 名前：デフォルトの名無しさん mailto:sage [2019/04/10(水) 12:23:01.13 ID:CbhRNE87.net] >>326 進化させるのは自分の設計、コーディング次第なのがbackbonejsの思想だけど フルスタックじゃないから足りない部分は自分たちで補えばいいし そもそもbackbonejsは、つい最近更新されたばかりで死んでないけどな 昨今のフレームワークは全部入ってるから良いと思ってる Railsやcakeみたいに作るのが簡単ならわかるけど、複雑化したら折角のフルスタックフレームワークがゴミになるだけ 328 名前：デフォルトの名無しさん mailto:sage [2019/04/10(水) 12:30:50.16 ID:sSiaigIF.net] これ読むと良いかも。 フレームワークとライブラリの違いがわかってない人は特に フレームワークは善か悪か，その両方か？ https://www.infoq.com/jp/news/2019/04/frameworks-libraries-axon 329 名前：デフォルトの名無しさん mailto:sage [2019/04/10(水) 13:13:49.79 ID:AVnP0KfU.net] >>327 AngularJSの話してんだけどアンカ先くらい見ようや 330 名前：デフォルトの名無しさん mailto:sage [2019/04/10(水) 13:50:22.69 ID:sSiaigIF.net] >>327 > そもそもbackbonejsは、つい最近更新されたばかりで死んでないけどな https://backbonejs.org/#changelog 1.3.3 ? Apr. 5, 2016 ? Diff ? Docs 〜それから3年の月日が流れようとしていた〜 1.4.0 ? Feb. 19, 2019 ? Diff ? Docs ほぼ死んどるがなｗ 1.4.0リリース作業の前のコミットは2018年5月だし、 ドキュメントや些細なミスを除けば、機能追加は2017年じゃないか？ 331 名前：デフォルトの名無しさん [2019/04/10(水) 16:27:07.49 ID:p6PdlM/J.net] >>328 ひと言で説明すりゃいいのにくどくどとしつこい内容だな 332 名前：デフォルトの名無しさん mailto:sage [2019/04/10(水) 22:25:31.68 ID:pjgtumep.net] >>322 その文からは、お前さんに論理性が無い事しか分からんな。 333 名前：デフォルトの名無しさん mailto:sage [2019/04/11(木) 00:19:20.16 ID:SMdbPkuM.net] フレームワークは、先に全体の構造が決まっていて、そこにはめ込む部品を作る。 全体の構造が決まっているから、プロ向き ライブラリは必要な都度、組み込んで、部分から先に作っていくから、 全体の構造が最後まで決まらないので、スパゲッティ・泥団子になりやすいので危険！ 334 名前：デフォルトの名無しさん mailto:sage [2019/04/11(木) 00:20:57.76 ID:GHeRPenA.net] 全体の構造なんて先に決めればいいだけやんｗ 335 名前：デフォルトの名無しさん mailto:sage [2019/04/11(木) 00:26:50.15 ID:XplD4nHz.net] >>333 フレームワークに任せとけば安心って思考停止して、結局何と何が依存してるか わからなくなってそのフレームに閉じ込められるパターン。 336 名前：デフォルトの名無しさん mailto:sage [2019/04/11(木) 01:02:55.46 ID:YM8e11gX.net] >>335 Angularの悪口はそこまでだ！！ 337 名前：333 mailto:sage [2019/04/11(木) 02:29:16.00 ID:SMdbPkuM.net] 全体の構造を、各人が決めたら、ダメ！ 各人によって、構造に違いがあるから、他人と思いを共有できない Aが作った構造を、Bが気に入らないなど、トラブルになる だから、Rails などの既成のフレームワークを使う。 そのフレームワークの構造を共有できるから 多くのフレームワークも、Rails を基本としている 338 名前：デフォルトの名無しさん mailto:sage [2019/04/11(木) 02:33:37.60 ID:yn719c2N.net] nuxtの出力jsが乱数名みたいになるのなんとかならんのかな 339 名前：デフォルトの名無しさん mailto:sage [2019/04/11(木) 03:23:58.52 ID:GHeRPenA.net] >>337 > Aが作った構造を、Bが気に入らないなど、トラブルになる > だから、Rails などの既成のフレームワークを使う。 だからその「既成のフレームワーク」を作ったのAで それを使うBが気に入らないってトラブルになってるんだろ？ 340 名前：デフォルトの名無しさん mailto:sage [2019/04/11(木) 03:24:46.97 ID:GHeRPenA.net] Rails 作ったやつは他人なんだから 思いを共有できないわな 341 名前：デフォルトの名無しさん mailto:sage [2019/04/11(木) 08:16:15.03 ID:VwFYHZX6.net] >>335 規約に則って書きさえすれば、チームのスキル差を減らして、一定の品質が担保できるのがフレームワークのメリットじゃない？ フレームワークに閉じ込められるって表現してるけど、それ単にチームで設けた規約に不満を述べてるだけかと。 もし今使っているフレームワークに不満あるなら、そもそも最初のフレームワーク選定時に意見を言うべきだし、 発言権のない立場なら大人しく従うか、転職なりしてプロジェクトから抜けるしかないんじゃないかな。 342 名前：デフォルトの名無しさん mailto:sage [2019/04/11(木) 08:17:20.21 ID:w+9Uk8Mc.net] 思いは共有できなくても、実績があるフレームワークに従いましょう、ってことで平和に収まるって話だろ。 この効果は間違いなくある。 343 名前：デフォルトの名無しさん mailto:sage [2019/04/11(木) 08:18:25.70 ID:Z8bgf8oa.net] ジャップのくせに 344 名前：デフォルトの名無しさん mailto:sage [2019/04/11(木) 14:38:55.28 ID:DdORBuxD.net] japjs 345 名前：デフォルトの名無しさん [2019/04/11(木) 18:06:29.66 ID:6MYNEhnq.net] 某個人アプリ制作者のブログで「5ちゃんのプログラミングスレはqiitaと比べて全然遜色しない内容だ」 って感じで書かれてるから初めて見に来たけど生産性のあるレスほぼなくてワロタ 346 名前：デフォルトの名無しさん mailto:sage [2019/04/11(木) 18:32:42.76 ID:XplD4nHz.net] >>341 規約があればいいがほとんどない。 >もし今使っているフレームワークに不満あるなら、そもそも最初のフレームワーク選定時に意見を言うべきだし、 >発言権のない立場なら大人しく従うか、転職なりしてプロジェクトから抜けるしかないんじゃないかな。 そもそも選定時にはその会社にいないし選定してった奴は転職なりしてプロジェクトから抜けてるわけで マジクソだよ。 347 名前：デフォルトの名無しさん mailto:sage [2019/04/11(木) 18:33:55.90 ID:w+9Uk8Mc.net] >>346 さっさ転職しろ 348 名前：デフォルトの名無しさん [2019/04/11(木) 19:27:20.19 ID:oNR0Pr/A.net] >>345 このスレじゃなさそうだな。。今angularを勉強してるが、これじゃないとという理由が見つけられないでいる。学習曲線や人員的な問題は置いといて、明らかに有利な点や逆にangularで困る事があったら教えて欲しい。 349 名前：デフォルトの名無しさん mailto:sage [2019/04/11(木) 19:42:22.98 ID:GR4ezT/u.net] 日本にいるとVue人気だから勘違いしそうになるがやっぱ採用実績はReactが圧倒してるんだな。475kサイト vs 64kサイトか…… しかしなぜかGitHubのスター数だけタメ張ってるｗ Top JavaScript Frameworks For 2019 https://www.codementor.io/nikhil21tyagi/top-javascript-frameworks-for-2019-s8881i8ga パフォーマンスについてはReactよりVueのほうがいいな。 AppRunってやつ速くて気になる。 しかしAngularいくらなんでも酷すぎる…… A RealWorld Comparison of Front-End Frameworks with Benchmarks (2019 update) https://medium.freecodecamp.org/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075 350 名前：デフォルトの名無しさん mailto:sage [2019/04/11(木) 23:55:39.98 ID:yn719c2N.net] >>349 AngularJSは確かにダントツで遅いけどAngularは別に悪くないじゃん 351 名前：デフォルトの名無しさん mailto:sage [2019/04/12(金) 00:57:20.94 ID:P0axT3Q0.net] >>349 hyperAppもなかなか。 352 名前：デフォルトの名無しさん mailto:sage [2019/04/13(土) 12:59:41.28 ID:X1Oa/ukN.net] SPAでログイン画面というかログイン機構作る場合はどうするのがベストプラクティス？認証用のアカウント情報はサーバー側のDBにあるとして 353 名前：デフォルトの名無しさん [2019/04/13(土) 13:42:39.23 ID:Fox9b+v2.net] >>352 使ってるフレームワークとやりたい事で変わるからなんとも。。 例えばログイン後は各ユーザ用の専用ページがあるって感じ？でなければセッションに保存して分岐するだけで済むはずだが。 354 名前：デフォルトの名無しさん mailto:sage [2019/04/13(土) 14:51:30.35 ID:FJkq9BtI.net] Angularは脂肪確定でよろしいか？ ReactかVue.jsの二つやっとけはいいのかな 355 名前：デフォルトの名無しさん [2019/04/13(土) 16:25:49.51 ID:Fox9b+v2.net] >>354 俺も悩んでる。普段reactとvue(nuxt)使ってて、今angular勉強中なんだが乗り換える必然性が見つからん。もちろんangularは力技使わなくても色々解決出来そうな感じで良さげなんだが。 ただもう少し勉強せんと冷静な判断できんわ。 356 名前：デフォルトの名無しさん mailto:sage [2019/04/13(土) 16:36:03.16 ID:vPnUo7ox.net] >>352 Firebase Authentication使えばよくあるGoogleアカウントでログインだのFacebookアカウントでログインなんかが出来るよ。 面倒くさいDBでのアカウント管理も全部Firebase上で出来るから実装に無駄な時間を掛けなくて済むよ。 357 名前：デフォルトの名無しさん mailto:sage [2019/04/13(土) 17:51:56.66 ID:oqNH9LQH.net] Google I/O 2019 (5月7日〜9日)で Angularと対立することになる Flutter for Web (Hummingbird) の新たな発表があるそうだから Angularを考えるのはその後にした方が良いと思うよ 358 名前：デフォルトの名無しさん [2019/04/13(土) 21:46:54.35 ID:Fox9b+v2.net] >>357 Flutter面白そうだね。たしかにクロスプラットフォーム開発はスタンダードが無いから学習するなら狙い目なのかも。現状swiftとkotlinでゴリゴリ書いてるけどどうしてもrealmが必要なんだよね。 Webアプリの弱点の一つオフラインDBをある程度解決できるなら真面目に検討したいんだが。 359 名前：デフォルトの名無しさん mailto:sage [2019/04/13(土) 21:50:11.69 ID:XHhHrn1r.net] >>358 オフラインDBが弱点って具体的にどういうこと？ 360 名前：デフォルトの名無しさん [2019/04/13(土) 22:53:34.64 ID:Fox9b+v2.net] >>359 ユーザデータを大量に保存してローカルで処理する系のアプリは現状webアプリだと厳しい。主に速度面で。 indexedDB+lovefieldみたいな組み合わせでsqlぽい事はできるけど、flutterがアプリ+webのクロスを狙うならソコどうするのかなって。DBの同期まではできなくても、一つのスキーマから全プラットフォームで動作するDB作れたら夢だよね。 361 名前：デフォルトの名無しさん mailto:sage [2019/04/13(土) 23:59:03.97 ID:6byp94bf.net] もういい加減 "ウェブアプリ" なんてやめればいいのに ローカルでデータを大量に処理ってそれ、 ウェブである理由はアプリのインストールとアップデートのためだけじゃん 362 名前：デフォルトの名無しさん mailto:sage [2019/04/14(日) 00:10:50.46 ID:WjGL7oJM.net] サーバーでやっちゃだめなん？ 363 名前：デフォルトの名無しさん mailto:sage [2019/04/14(日) 00:30:22.71 ID:8JmU//KT.net] モバイル端末のストア経由っていうのが煩わし過ぎるからなぁ 364 名前：デフォルトの名無しさん mailto:sage [2019/04/14(日) 00:45:03.08 ID:/V8zrPr0.net] >>360 ごめん、おれの経験不足なのかやっぱわからん。 >>ユーザデータを大量に保存してローカルで処理する ↑ クライアントは1台だけなのに、速度が気になるほどデータを処理する例が全く思い付かない… 365 名前：デフォルトの名無しさん [2019/04/14(日) 01:13:17.48 ID:jIyXk5jh.net] バックエンド主義の人が強引に考えたついた難癖にしか見えない フロント処理で充分 366 名前：デフォルトの名無しさん [2019/04/14(日) 08:24:48.36 ID:Qhel4iVb.net] いやまあ、別に現状でも工夫すればできるからブラウザのローカルDBにそこまでこだわっては無いよ。課題も多いし。ユーザがいつでも削除できるとか。 ただネイティブアプリとwebアプリが同じコードとロジックを共有するなら避けられない課題だろうなと。 367 名前：デフォルトの名無しさん mailto:sage [2019/04/14(日) 10:03:52.66 ID:U21XdTdR.net] ユーザーが自由に削除できることが課題？？ 世の中のソフトウェア殆どがそうだけど何か困るのか？ 368 名前：デフォルトの名無しさん [2019/04/14(日) 11:45:21.51 ID:fnTRmDnx.net] ほんと早くMac死んでほしい 369 名前：デフォルトの名無しさん [2019/04/14(日) 13:07:21.11 ID:/kyrD1Ys.net] >>367 indexeDBのことだよ。ブラウザのキャッシュクリアで簡単に消えちゃうだろ。間違えて消してクレームくるんだよ。 370 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 12:25:48.71 ID:sResMPAv.net] Reduxわかんね 371 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 18:58:19.12 ID:r0ZMOOHm.net] >>370 大丈夫。俺もわからん てか、あんなの小規模なWebアプリケーションにはいらん 372 名前：デフォルトの名無しさん [2019/04/15(月) 20:20:50.21 ID:HmQvEiCf.net] Reduxわからんの？ かわいそうに 373 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 20:23:02.95 ID:S/0/c6v4.net] Reduxわかるの？ じゃあ、Reduxを使うことで、 どんなメリットがあったか教えて 374 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 20:25:51.20 ID:IXPbMXJW.net] 処理の流れが一方向なのでわかりやすい。 375 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 20:33:46.03 ID:S/0/c6v4.net] > 処理の流れが一方向なのでわかりやすい。 文章がつながってない。 処理の流れが一方向なのはまだいいとして、 なんでそれで、わかりやすいということになるのか？ そもそも "処理の流れ" が一方向であるならば、 何を使っても一方向にしかならないはず。 Reduxを使うことで、一方向になるわけではない。 また双方向とか一方向というのは、局所的に見るか 全体的に見るかの違いでしかないのではないか？ 例えば電話での会話だって、双方向に見えても、実際には自分の通話口から 相手のスピーカー、相手の通話口から自分のスピーカーへの一方向通信だ。 一方向も双方向も大した違いはない。 376 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 20:40:44.13 ID:IXPbMXJW.net] まあ実際、説明の難しいところではある。 >また双方向とか一方向というのは、局所的に見るか >全体的に見るかの違いでしかないのではないか？ これはその通りだがその違いが大きいとしか言いようがない。 treeをたどるロジックというのは一般に指定が複雑になりやすいとか、 ノード間のコミュニケーションがコールバックでつなぐと相当複雑になるとか 色々あるけれどその辺を単純化できてるようには思う。 電話の比喩を持ち込むならマイクとスピーカーが同じより違った方が良いとかになるのかな？ 377 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 20:43:17.24 ID:S/0/c6v4.net] もう少し具体的な例を出そう。 getterとsetterと言えば、俺が言いたいことが見えてくると思うが Reduxが言いたいことは、単にgetterは値を取得するだけ setterは値を入れるだけにしましょうってことだろう？ まあgetter/setterは別の批判も有るから、getter/functionの方が良いか？ もう一つの例としてRESTで例えるならば、GETは何度GETしても状態は変わらない。 単にデータを取得するだけ。POSTはデータを送信するだけ。 この考えかたと同じことだろう？ これをオブジェクト指向に当てはめるならば、このメソッドはデータを更新し、 このプロパティはデータを参照するという話でしか無い。 これは普通のオブジェクト指向のベストプラクティスとなんらかわりはないんだが、 Reduxを使う必要はあるのか？ このメソッドはGETかPOST（相当）であると ドキュメントに書けば済む話だろう？ 378 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 20:49:52.40 ID:S/0/c6v4.net] マイクとスピーカーで分けたほうが良いという考え方は 反対しないが、まともな設計能力が有るならば、最初からそうしているわけで、 Reduxを使う理由にはならない。 まともな設計能力がない人のための矯正器具=Reduxということか？ だが矯正器具はいつまでも使っているわけじゃあるまい？ まともな設計能力がついた人にとっては、邪魔な道具でしか無い。 379 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 20:53:26.60 ID:IXPbMXJW.net] >>378 そうだね。あなたはredux使う必要ないと思うよ。 あなたの素晴らしい設計でやりくりすれば問題ないんじゃないかな。 380 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 20:58:32.77 ID:S/0/c6v4.net] もちろん、Reduxが何の負担もなしに、もしくは低い負担で ベストプラクティスを実現できるというのなら導入する価値はあるが、 一方向を得るために、Reduxのやり方で設計しろっていうのは負担が高すぎる。 Reduxのやり方はルールが多すぎて単純ではないからだ。 Reduxの設計方針を理解しないまま、Reduxを使うよりも まずは知識をつけるのが先だろう？ このメソッドは書き込みを行うメソッド、このメソッドは読み込みを行うメソッド 明確に分けたほうが良いと。そしたらあとはメソッドのコメントに書けばすむだろう？ （普通はコメントで書くまでもなく、メソッド名からどちらであるかはわかる） それだけのことなのに、それを矯正するためのフレームワークというのは 意味不明すぎる。便利にするためのものじゃない。矯正するためのもの まったくもってReduxはわからん。 381 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 20:59:53.90 ID:r0ZMOOHm.net] スパゲッティになるならreduxは必須 でもそうならないなら本当に必要ない、とは思う コード量多くなるからね 382 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 21:02:11.16 ID:S/0/c6v4.net] >>379 > あなたの素晴らしい設計でやりくりすれば問題ないんじゃないかな。 だから聞いたんだよ 「どんなメリットが"あったか"教えて」 どんなメリットが "あるのか？" じゃない。"あったのか？" だ。 あんただってそれなりにまともな設計ぐらいできるだろう？ あんたの能力がどれくらいで、Reduxを使うことで どういうメリットが、あったんだ？ なにかを矯正されたんか？ 俺は矯正が必要なほど設計が下手なつもりはないんだが。 383 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 21:04:00.12 ID:IXPbMXJW.net] とりあえずメリットは書いたし、びっくりするほど文章読んでないのも理解できる。 384 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 21:06:15.53 ID:S/0/c6v4.net] Reduxがやってるのって、 1. オブジェクト指向のクラスがあります。 2. クラスから読み込み専用メソッドを抜き出します。 3. クラスから書き込み専用メソッドを抜き出します。 4. クラスに残ったものはデータのみです。これを一つのオブジェクトとしてPublicにします。 オブジェクト指向のクラスが、 読み込み専用メソッド、書き込み専用メソッド、データ の３つに分離されました。 ってだけだからな。 385 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 21:07:20.84 ID:S/0/c6v4.net] >>383 いうだけなら誰でもできる。 コミュニケーション取ろうぜｗ 386 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 21:33:29.21 ID:g9zAAmJv.net] 処理をAPI化するイメージかな必ずその経路を経由して状態を変更するからグローバル変数みたいなどこからでもアクセスできるけどちゃんとアクセス経路は限定できるみたいな 387 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 21:36:35.56 ID:S/0/c6v4.net] その "グローバル変数" をクラスにして、APIをクラスのメソッドにすれば 普通のわかりやすいオブジェクト指向設計になるんですが？ Reduxの存在意義って？ 388 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 21:40:15.54 ID:S/0/c6v4.net] そしてReduxは、クラスのメソッドを抜き出すだけじゃないからね メソッド（関数）は普通にメソッドに引数渡して普通に呼び出せるが、 Reduxは「引数つきでメソッドを呼び出すため」のデータを作って データを投げて、そのデータ解析して（←ここ自分で作る） そしてやっとメソッドを呼び出すという無駄なことをしてる。 389 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 21:46:24.27 ID:S/0/c6v4.net] 結局の所 Redux はわかりやすいものではなくて （わかりやすい = ただのセールストーク） オブジェクト指向 VS 関数型（？） の戦いから 俺たちはアンチオブジェクト指向で行くぜ！という派閥から 生まれたものに過ぎない。 それ自体は考え方の違いでありだとしても、 Reduxの仕組みは、それを実現するためのルールが多すぎて 百歩譲ってわかりやすいとしても、そのルールに従って コーディングするためのコストが大きすぎて小さいプロジェクトではペイしない （大きいプロジェクトでもはたしてペイできるかどうか） "設計方針の違いを反映させるためだけ" でしかなくて、 それしか得られない割に、コストが大きすぎる 390 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 21:55:58.52 ID:IXPbMXJW.net] 別にコールバックでdom treeたどるのが大変でないならredux使う必要ないわな。 それでいいと思うよ。 てか読んでないのにコミニュケーションを要求するとか まともに設計できる人間じゃないことはわかるよ。 391 名前：デフォルトの名無しさん [2019/04/15(月) 22:15:47.71 ID:HmQvEiCf.net] 一度Reduxで作ってみたら後は別のプロジェクトでも同じように作ればいいだけだから何も問題はない 最初だけ複雑に思うだけ 392 名前：デフォルトの名無しさん mailto:sage [2019/04/15(月) 23:37:35.47 ID:IXPbMXJW.net] 確かにreduxのproviderとconnectの対応は暗黙な繋がりでわかりにくいところはあると思うんです。 reduxというかfluxの実装として他に方法はあるかもとは思う。 393 名前：デフォルトの名無しさん [2019/04/15(月) 23:45:03.60 ID:o5Us7+p1.net] vue公式からの引用で恐縮だが、、 もし、あなたが大規模な SPA を構築することなく、Vuex を導入した場合、冗長で恐ろしいと感じるかもしれません。そう感じることは全く普通です。 あなたのアプリがシンプルであれば、Vuex なしで問題ないでしょう。単純な ストアパターン が必要なだけかもしれません。 しかし、中規模から大規模のSPA を構築する場合は、Vue コンポーネントの外の状態をどうやってうまく扱うか考える絶好の機会です。Vuex は自然な次のステップとなるでしょう。これは Redux の作者、Dan Abramov からの良い引用です: Flux ライブラリは眼鏡のようなものです: それらが必要になったときに知るのです。 394 名前：デフォルトの名無しさん mailto:sage [2019/04/16(火) 00:27:12.19 ID:+U4ppNzc.net] まあ大きなもの作ったことない人にはわからん世界だと思うよ。俺も学生の頃はフレームワークの必要性とかさっぱり理解できなくて制作者の自己満足だと思ってたもん。 そして必要になったことがない人にはどんなに説明しても納得してもらえないもんだよ。 395 名前：デフォルトの名無しさん mailto:sage [2019/04/16(火) 00:30:35.35 ID:QBtHnjEv.net] 今軽くReduxググってみたけど何がしたいのかさっぱり分からんｗ jsにprivateが無いからsetter/getterのレイヤー作ってんの？ 396 名前：デフォルトの名無しさん mailto:sage [2019/04/16(火) 00:42:55.64 ID:QBtHnjEv.net] いやfluxで調べたら少しわかった オブジェクト指向でいちいち相互参照とか面倒くさいから シングルトンにデータ全部詰め込んでおこうぜ見たいな話だな 397 名前：デフォルトの名無しさん mailto:sage [2019/04/16(火) 02:31:52.71 ID:+8WSocTt.net] おまいら、vueの利点として、サイトの一部分のjQueryで 作っていた部分をちょこっと置き換えるのに良いって 言ってるくせに、それがいつか大規模なSPAに変わると思ってんの？ 398 名前：デフォルトの名無しさん mailto:sage [2019/04/16(火) 02:40:36.60 ID:+8WSocTt.net] >>393 こっちのほうがわかりやすくね？ｗ Flux ライブラリはサスペンダーのようなものです: それらが必要になったときに知るのです。 （意味 デブになれば必要な理由がわかる。だがそもそもデブになんかならねーし、デブなのが一番の問題） 399 名前：デフォルトの名無しさん mailto:sage [2019/04/16(火) 04:49:30.73 ID:vZMMDQFG.net] 猫も杓子もreduxだけどほかのflux実装の感想聞きたいわ それなりの規模で使用した、もしくはしてるみたいな人おらんの? つかfacebookはfacebook/flux使ってるのかね メンテされてる感じせんけど 400 名前：デフォルトの名無しさん mailto:sage [2019/04/16(火) 07:41:32.20 ID:9wO+Q4tD.net] >>397 そんなこと書くと議論がすり変わりそうだぞ。 ID:IXPbMXJWが書いてくれたことで十分でしょ。それで納得できる人もいればできない人もいる。 万人が使うものでないことは間違いないわけだし。それはスレタイの3つがそもそもそうなわけだけど。 401 名前：デフォルトの名無しさん mailto:sage [2019/04/16(火) 08:31:26.34 ID:dFuxCqAG.net] よくまとまってる。 https://mizchi.hatenablog.com/entry/2018/10/04/101308 > Middleware に何を使うかで、 redux ユーザー同士の非同期のノウハウは共有できず、 > 分断されている(thunk, saga, steps, epic, no middleware) これが一番の問題点。 402 名前：デフォルトの名無しさん mailto:sage [2019/04/16(火) 08:57:52.42 ID:HGB3ondZ.net] >>401 suspence来たら全部ゴミ。 403 名前：デフォルトの名無しさん mailto:sage [2019/04/16(火) 14:12:45.48 ID:sdqnJ2Ku.net] suspence見たけど状態管理をsimple-cache-providerに移動しただけな感じがする 明確なIDが無いリクエストみたいなのが渡ってくる場合だと コンポーネントと非同期キャッシュの対応付けが面倒になりそう コンポーネントインスタンス毎に一意ID生成してstateに保持だと本末転倒な感じだし 404 名前：デフォルトの名無しさん mailto:sage [2019/04/17(水) 11:15:37.77 ID:CEJ7HETE.net] 静的サイトジェネレーターでBlog作りたいのだが情報少ないね。 VuePressがよさげなのだが 405 名前：デフォルトの名無しさん mailto:sage [2019/04/17(水) 12:37:53.92 ID:q/9NxBQE.net] なんでvuepress？nuxtよりいいとこある？ 406 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 01:12:24.22 ID:+Qj1NZId.net] ガチガチのSPA作ろうと思ったらAngularじゃねーの？ ionicでwebアプリ作ってみたけどストレスなく作れて良かったよ 407 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 01:21:26.96 ID:+Qj1NZId.net] まずフロントエンド周りに関わる仕事はしないほうがいいと思う 全てが無駄になる可能性が高い 408 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 07:16:50.87 ID:xDdfDEdP.net] reduxで一回のdispatchで2つのstateを一緒に更新したい場合ってreducerどう書くのが正解？ とりあえずreducerのreturnをjsonオブジェクトみたいにすれば良さそうではあるんだけど 409 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 09:46:39.79 ID:FtQwjU5R.net] ReactのReduxはそろそろ廃れて欲しい ホックで何とかなるでしょ Reduxは奇形的だと思う 410 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 10:58:53.81 ID:JWUHkBKS.net] >>405 じゃあNUXT.jsでｗ こっちもそんなに情報ないよね 411 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 11:12:33.86 ID:nwidurpX.net] vue関係は中国語が共通言語 412 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 12:26:49.21 ID:+Qj1NZId.net] Vue vs React vs Angular とあるがどれも学ばないというのが4の選択肢が正解じゃないか 他に時間を投資すべき どうしても必要ならVueを摘むの適切 それでもVueを深く学習してVueメインでガチャガチャ動くサイトなんて作っちゃいけない 413 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 13:18:32.08 ID:PeuY0IP9.net] >>412 それな。どうせどれ使っても数年で消える。 jQueryだけが今もこれからも使われて続ける 414 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 13:28:48.77 ID:f6QMigdn.net] いいんだけどさ、forthスレやqbasicスレ、coqスレなんかにも「必要ないって言ってるでしょ！」ってムキになって書き込みに行ってるの？ｗ 415 名前：デフォルトの名無しさん [2019/04/18(木) 14:17:31.95 ID:rqGOrs8Z.net] 一部にvue入れるのもアリだよ。検索や登録フォームはvueで置き換えると保守が凄く楽になるぞ。俺もそこから始めた。 416 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 14:22:13.48 ID:+Qj1NZId.net] jQuery固執おじさんもいらない 417 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 16:15:08.38 ID:FtQwjU5R.net] jQueryが神すぎて、これは捨てられない。 418 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 16:24:16.71 ID:PeuY0IP9.net] >>414 いったことないで？全く知らん分野だし 419 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 16:24:58.29 ID:PeuY0IP9.net] >>415 > 検索や登録フォームはvueで置き換えると保守が凄く楽になるぞ。 具体例で見せてほしい 420 名前：デフォルトの名無しさん mailto:sage [2019/04/18(木) 16:27:28.57 ID:uN7CTDaS.net] フォームはVueの練習には良いよね。 でも大きく要素が入れ替わらないTodoリストくらいだったらJQuery + HTMLのテンプレート要素で作ったほうが簡単に感じる。 テンプレート要素が適用しづらいなって思ったら使うべきか。 421 名前：デフォルトの名無しさん [2019/04/18(木) 16:34:11.27 ID:rqGOrs8Z.net] >>406 だよね。angular思ったより全然使いやすい。迷う事が少なくていい。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef