webpackを自分でセットアップしなくて済むのはビギナー的には大きい

>>450
だから具体的理由も書けよいつも糖質君

>>451
LaravelMixのこと言ってる？
あれ独立して使える時点でLaravelとの相性は関係なくないか？

そもそも言うほどwebpack自分で設定するか？
vue create か create-react-app コマンド打つだけで雛形用意されるし、そこから追加の設定が必要ならLaravelMixでも変わらない。

>>452
お前が書けよ

>>453
でもそれバックエンドとの結合テストでデバッグする際に毎回サーバーにdistのjsをコピーするって事っしょ？

>>455
つまり？

>>456
ごめん、24歳保育士の彼女と電話してた

やめたれｗｗ
>>456だって彼女ぐらいいるよ・・

>>457
俺の成りすましすんなゴミ

>>456
つまりLaravelはフロントフレームワークとの相性がかなり良い
他フレームワークと違って細かい制御が可能でビギナーにも優しい

>>459
24歳保育士の彼女との電話がなりすましってことは
彼女いるのは嘘なんですか（；ω；）

>>461
55歳保育士のおかんと電話してた

>>461
彼女どころかすでに結婚してるから
ちなみに俺フェラーリに乗っていてコロナ自粛前は
毎日スポーツジムに通ったり映画館や近くの高級店で優雅な朝食を
食べたりしていたな　ごめんねレベルが違う話しちゃって

結婚しているはまあいいとして
普段の生活情報いりますかね？

>>460
細かい制御って？

>>465
知らないなら自分で調べろよ

変なやつ増えたなぁ

いや昔のメンバーが戻ってきたとみるべきだろう

>>466
具体例出せって言われてるのいつ理解するの？

>>463
なんか一般人が必死に考えた金持ちのイメージって感じなんだけど・・・・

HTTPメソッドの使い分けはその操作が安全であるかどうか、べき等であるかどうかで判断するのが原則。

安全→サーバ、特にDBなどの状態を変化させないこと
べき等→その操作を何度行っても結果が同じであること

検索のような安全でべき等な処理はGETが推奨。
要はGETを使う場合はブラウザ側でキャッシュしても問題ないようにしておいてねということ。

POSTはリソースの新規作成など安全でもなくべき等でもない操作に使う。
ただし、クエリパラメータに出したくない項目がある場合や、検索項目がとんでもなく多くてURLが長くなる場合などに、安全でべき等な操作であってもPOSTを使わざるを得ないこともありうる

GETであることの他の利点は、Google検索のようにURLだけでそのまま検索結果の表示ができること

つまりjsonだけで行う通信は脆弱性があるということ

× つまりjsonだけで行う通信は脆弱性がある
○ 話は変わるがjsonだけで行う通信は脆弱性がある

>>471
× つまりjsonだけで行う通信は脆弱性がある
× 話は変わるがjsonだけで行う通信は脆弱性がある
○ つまりどんなプロトコルだろうとPOSTのような処理には作り方次第で脆弱性を生むリスクがある

①edit画面が呼ばれ、DBから初期データ取得してフォーム要素にセットして表示
　⇒ この画面で編集されて[確認]ボタン押されPOST送信される

②confirm画面が呼ばれ、フォームデータを取得しバリデーションして以下２通りの処理に分かれる
　その１) ⇒ バリデーションＯＫの場合、確認画面を表示。return view('path.to.confirm', compact('data'));
　その２) ⇒ バリデーションＮＧの場合、edit画面に戻しエラー表示。return view('path.to.edit', compact('data', 'error'));

以上のような画面遷移があるとすると
path/to/edit.blade.phpのフォーム要素valueの書き方をどうすべきか迷っています。

DBから取得し、そのままビューに渡すと value="{{$data->hoge}}" 形式で書きます。
edit画面に戻す時にそのまま渡すと配列のため value="{{$data['hoge']}}" こう書くことになります。

なので両方に対応するには value="{{$data['hoge'] or $data->hoge}}" のように書くことで対応できそうです。
でもスマートではないのでedit画面に戻す時は $data = (object)$data; のようにキャストすることで value="{{$data->hoge}}" だけでよさそうになりそうです。

これって他にもっといい方法ありますか？

個人開発アプリが月30万円以上安定して稼ぐまでの紆余曲折http://note.com/toconakis_tech/n/n85fdcdc63661
個人で作るならゲームよりもツール系アプリだと思う理由http://megumikan.work/2018-08-24/tool/
SES出身、累計売上900万円以上の個人開発者に聞いた「売れる開発者のなり方」http://and-engineer.com/articles/Xqv_HBAAACQAdx-B
世界中でヒットしたアプリ開発の勝因は「あきらめない」こと【小林高志さんインタビュー】http://itpropartners.com/blog/13546/
個人アプリ開発で一文無しから1000万円稼げるようになった成功事例http://growthhackjournal.com/article/development/how-tasnim-ahmed-went-from-jobless-to-making-100k-with-apps/
自分たちを信じて「つくっては壊して」を6ヶ月くり返した。日本発のゲームアプリ
「Brain Dots」世界2,000万ダウンロードの裏側と2つのプレッシャー。http://appmarketinglabo.net/braindots/
「これならアプリで食っていける」世界2300万ダウンロードの脱出ゲーム「DOOORS」
作者がデザイナーからアプリ開発者へ転身したワケ。http://appmarketinglabo.net/dooors/
「渋谷で数人でつくったゲーム」が世界150カ国で1,000万ダウンロード。
脳トレ対戦アプリ「BrainWars」創業者がソシャゲじゃなく教育ゲームをつくった理由。http://appmarketinglabo.net/brainwars/
なぜそこにアラブ人。スマホゲームに飢えた「アラブの課金王」国境を越える。そこに
「存在しないはずのアラブ人」が欧米のアプリストアをつかう真実。http://appmarketinglabo.net/arab-mobilegame/

書いてあげたぞ
http://paiza.io/projects/XrMo0UYmazpxy6h5np-9YA

Oracle「Laravelもボクが管理するよ」
ってなったら終わりだな

FormRequest使うと入力エラーだと入力画面に戻ってoldで入力値が取れるけど、その時にFormRequest内で入力値に追加することってできないのかな
やりたいことは画像アップロード付のFromでエラーで戻った時に正常にアップロード済みの画像は再選択しなくてもいいようにしたいです
画像でエラーが出た時はもちろん再選択でいいです
なので入力エラーの時は入力データに別のキーでアップロード済み画像のフルファイル名と元ファイル名を持たせようかと思ったんだけどうまくいかない

そういう用途用のlaravel用ライブラリ誰かが作ってた気がするけど
ライブラリ名が思い出せない　すまんな

>>479
画像ファイルそのものをpostするのではなくbase64エンコードした画像をpostしちゃえば、ただのstringのやりとりだし簡単に解決じゃね？

つか最初からSPAならそんなこと悩まなくて済むのにね。

こういうのがいるからセキュリティリスクを生むんだよな

>>479
SPAにしちまえYO

>>483
SPAだのjsonだのbase64だの言ってる情弱共は脆弱性の「ぜ」の字も知らないんだろうね
何が脆弱なのかも分かってないから「根拠ガー」って連呼するしかできない

設計レベルの質問でないのに、すぐSPAにしろとか回答するのは傍から見てもムカつくよな。

>>485
いつまでふんわり指摘俺カッケーやってんの
具体的根拠が示されないまま進むふわふわ議論を良しとする考え方の方が危険だわ

お前らってJavascript側ではバリデーションやって、
サーバ側ではバリデーションやらないという片手間落ち実装してそう
ちゃんと両方に実装しなきゃ駄目daz


dareka zenkakunyuryokunimodosuhouhouwooshietekudasai

>>488
次元が低すぎる議論はしてないです

>>488
何言ってるの。SPAにすればすべて解決するのに。

SPAはLaravelとの相性がかなり良いから正直バリデーションもあんまりしなくて良いとも思う

>>491
ほんとにそれな

バリデーションないアプリとか怖すぎてリリースできねーよ

>>488
まさかいまどきサーバーでバリデーションしてるの？

普通は両方でバリデーションやるだろ

確かにフロントとバックのバリデーション分担って悩ましいよね
結局のところどっちもやるべきなんだと思うけど

最近昔のシステムの改修しててソース見ると
フォームポスト
↓
バリデーション→確認画面表示
↓
バリデーション→本登録

みたいになってるけどこの二回は流石に要らんだろと思って
一回目のバリデーション通ったらその結果をセッションにぶち込んで二回目のところはセッションから取り出した値そのまま通すことにして
UI側にアクティブなバリデーション入れた
画面遷移の確認→確定シーケンスは保持
ただ確認画面はページは遷移せずにDOMの表示切り替えにした

VueとかReactみたいなハイカラなもの使いたいけどまだ実用できるレベルじゃないから勉強中で悩ましい

どんなにJavaScriptでガチガチにバリデーションしてもセキュリティ考えると結局サーバーサイドでバリデーションしないといけないのは変わらないしな
ユーザビリティとしては一旦JavaScriptでバリデーションしてエラー出した方がいいけど、バリデーション処理が2箇所になってメンテナンス性が悪くなる

早い時点でチェックすればいいんだから、クライアント側でやっておけばいいじゃん

セキュリティ面の考慮を除いても、DBが必要なバリデーションがあるだろが（Uniqueとか）。
フォーマットチェックだけならJSで済ましてもいいけどさ。

JSON君に倣って冗談で>>494書いたつもりだったのにマジでサーバーでバリデーションしてないやつがそこそこ居て笑えないわ