Пікірлер

• 
  @_daisakkai22 сағат бұрын

  最近Tailwind触りだしたので、めっちゃ参考になります！ TailwindVarianatsはstichesとかvanilla-extractでいうところのrecipesみたいな感じで使えて便利。

• 
  @null776Күн бұрын

  間違っていたらすいません。 むーさん、MONGOL800でギター弾いていましたか？

• 
  @moozaruКүн бұрын

  残念ながら..弾いておりません。

• 
  @TAIRANOBUHIKO2 күн бұрын

  すごく便利で使い易くて、その上動画が分かりやすいです！！🤩

• 
  @mk-tomato2 күн бұрын

  すごくわかりやすいです😢

• 
  @moozaru2 күн бұрын

  良かったです😆

• 
  @user-ph1oq8bi4o12 күн бұрын

  勘違いだったらすいません… propsから情報漏洩する対策がDTOというところ、「Server->Client間の転送層としてのDTO」という独自の設計前提でお話しされてる気がしました。 主にバックエンドの世界におけるDTOはサーバー内処理において不変なデータ転送であることを示すこと使うので、最初「あー、React Taint APIでDTOを転送禁止にする話かな？」と思ったんですが、どうもそうではなさそうでかつClientへの流出をDTOなら防げるような言い回しが、本来のDTOの意味に沿ってない気がして気になってしまいました。

• 
  @moozaru2 күн бұрын

  ちょっとわかりにくい話しですいません。 話したかった意図は、ServerComponent内部で、DBから取得したデータをpropsなどで伝搬する際にDTOの考え方を適用したいということでした。Prismaで取得したオブジェクトをそのまま渡さず、DTOで明示的にフィールドを渡す。ServerからClientという意味では仰るとおりReact Taintが有効になりそうですね。

• 
  @engineer_training964616 күн бұрын

  まさに今日ハマってた テンプレートリテラル使いたい

• 
  @LiuXingJIN17 күн бұрын

  まさに今週ハマってた

• 
  @yutoriotsu884818 күн бұрын

  他の人も指摘していますが機能追加や仕様変更が多くて全然技術スタックとして枯れないところが嫌いですね Reactのメタフレームワークだけあって影響力も大きく、言ってしまえば生煮えの技術スタックなのに新規開発でむやみに採用されがちなところも嫌いです🤪

• 
  @wakachama554718 күн бұрын

  カジュアルにITの面白さを学べて、いつも為になってます！ 動画投稿ありがとうございます✨

• 
  @fujinoco601221 күн бұрын

  vue , nuxt からフロントエンドに入った身ですが違うフレームワーク知れて興味深いです

• 
  @ThrowAWAYSUTEAccount21 күн бұрын

  普段置換でやってたけど、そっちの方が効率良さそう🎉

• 
  @kumonopanya21 күн бұрын

  クライアントコンポーネントの下にサーバーコンポーネントが必要なとき

• 
  @kumonopanya21 күн бұрын

  revalidatePathの使い方はそんなふうに使うのか、単にキャッシュ再読み込みして現在のデータ取ってくるのだと思ってた。

• 
  @kumonopanya21 күн бұрын

  フロントエンドとバックエンドでそれぞれ作るという考えから、 開発はデザインと機能にそれぞれ集中できる時代になっていくってことかな。

• 
  @kumonopanya21 күн бұрын

  sql は Next.js + Prisma の合体技かな？

• 
  @nospamarinointhechatarino424722 күн бұрын

  全体的にNextjsの良いところと言うよりReactの良いところって感じがしたんですが、ここで紹介されたうちではNextjsならではなところってなんですか？

• 
  @moozaru21 күн бұрын

  revalidatePathでしょうか。これのお陰でグローバルな状態管理をせずとも、データ更新時に最小限に画面の再描画をしてくれます。また、動画では紹介しませんでしたが、Parallel Routesは個人的にお気に入りです。これを上手く使うとClientComponentの境界線を突破してServerComponentに切り出せるので、状態管理が楽になります。 React19新機能をフルサポートしているのが現時点では実質Next.jsだけなのでどうしても被っちゃいますね。今後、他のフレームワークがサポートを始めたら違いが出てくると思うので楽しみです。

• 
  @user-tg6fn9fe2g22 күн бұрын

  Nextめっちゃ好きなんだけど、更新が早すぎてベストプラクティスが確立してなかったり、結構問題ありのバグ含んでたりする、、、新機能にインフラ側がなかなか対応しなかったり、、、

• 
  @moozaru21 күн бұрын

  そうですねー。僕も今苦労している点は世の中的にもこう書いたほうが良いなという経験に基づいたベストプラクティスが確立されていない点ですね。なるべく改善されるべくアウトプットをするように心がけていますが、こればかりは時間がかかりそうです。バージョンアップが不安定という問題も、v13-14時代ではすごかったですね…。今はかなり改善されたなという印象はあります。

• 
  @fetboba221022 күн бұрын

  このようなスタイルを採用するとフロントの人間にもバックエンドの責務が増えそうで嫌だな いち労働者視点では見渡すべき範囲は狭い方が楽

• 
  @takumifujise613722 күн бұрын

  この動画のおかげでNext.js勉強したくなりました。 質問です。実案件ではライブラリやフレームワーク、テストツール、ビルドツール等をどのくらいの頻度もしくはタイミングで最新に追従されてますか？ もしくはフロントは流行り廃りが早いので、フルスクラッチで書き直して移行するのが多かったりするのでしょうか？ その辺の苦労話もあれば動画にしてほしいです。

• 
  @moozaru21 күн бұрын

  基本、各プロジェクトとチーム体制に合ったものを選定するという前提を置きつつ、最新に追従という意味ではなるべく早く対応しています。極端に言うと毎日npm updateします。これは各ライブラリのバージョンが古い状態のまま放置すると、現実的にバージョンアップが無理という状況が生まれてしまうからです（工数が膨大になるため）。ただ、まったく別の最新フレームワークやライブラリで作り変えるということはほとんどしません。それをしても事業の価値につながるケースはほとんどないため。…雑に書くとこんな感じです！

• 
  @takumifujise613721 күн бұрын

  ​@@moozaru > 極端に言うと毎日npm updateします。 なるほど。毎日というのは考えたことなかったので参考になります。

• 
  @xxx8562xxx23 күн бұрын

  動画の内容と少し逸れますが、最近Nuxt.jsで初めて開発しました！とても楽しいです！Next.jsもやってみたい！

• 
  @null77623 күн бұрын

  状態管理が減らせるというのは、サーバーコンポーネントでfetchできたり、サーバーアクションを使えるからで合ってますか、、、？ だとすると描画ごとにDBに問い合わせることになると思うのですが、状態管理でグローバルに管理するものの境目というか使い分けはどういう基準がありますか？

• 
  @moozaru23 күн бұрын

  今の所、グローバルに状態管理するものはほぼないですね。あるとしたらuseContextで認証したユーザのパーミッション情報や色などのテーマカラーなど、サイト全体で使う設定値のようなものです。それも外部ライブラリを使わずにReactだけでやっています。

• 
  @bbieye23 күн бұрын

  前回の動画の続きということでとても楽しかったです。ありがとうございました revalidatePath というものがあるのですね、とても便利ですね。Next.jsをもっと触ってみたいと思います。とても勉強になりました🥰 質問よろしいでしょうか。LaravelもRailsも経験と実績があるお二人はNext.jsでのバックエンドの書き方や、各種機能などを力不足だな、または苦労した。というところはありますでしょうか？ といいますのは、お二人の動画を拝見してNext.jsの魅力をたくさん知ることができフロントもバックエンドも全部TSでやってみよう😍と思ったのですが、Next.jsのバックエンドは他のバックエンドとどう違うのかなと思いました。私はLaravelでのバックエンドに慣れているので、これからNext.jsでバックエンドも勉強か。。。と躊躇してしまいました。 いつも楽しい動画ありがとうございます。次の動画も楽しみにしています🥰

• 
  @moozaru23 күн бұрын

  動画視聴ありがとうございます！まずNext.jsの学習についてですが、今Laravelをやられているのであれば、それをそのまま継続した方がいいと思います。というのも、同じ領域のフレームワークを同時に学ぶのは普通に疲れちゃいますw 一通り使いこなせるようになってからの方が違いが認識でき面白く学べると思います。

• 
  @moozaru23 күн бұрын

  Next.jsで苦労したところや力不足だと感じたのは、なにかトラブルが起きたときにNext.js自体のソースコードを読んで原因を探るのですが、コードが難しすぎて全然理解できなかったことですw 別の言い方をすると、レアな不具合に遭遇するとかなり迷子になります。

• 
  @bbieye22 күн бұрын

  @@moozaru ご回答ありがとうございます。原因究明のときですか、レアな不具合とかもあるわけですよね。とても参考になりました。ありがとうございました。☺

• 
  @bbieye22 күн бұрын

  @@moozaru アドバイスありがとうございます。そうですよね。同時に複数のことをすると深く学べなくなりますし、しんどいですよね。どうもありがとうございました🥰

• 
  @kakamax1423 күн бұрын

  next初学者なのですが、server actionsがあれば以前紹介されてたtRPCはもはや不要なんですかね？？🤔

• 
  @moozaru23 күн бұрын

  フルスタックにNext.jsを使うのであればtRPCは使わなくても良いかなと思います。ただ、tRPCは特定のフレームワークに強く依存するわけではないので、バックエンドをNestJSやExpressで、フロントをNext.jsやSvelteなど他のものを使うことが出来るのが魅力ですね。

• 
  @user-mm7vl5er8c27 күн бұрын

  非常に役立ちます。わかりやすい説明でかつ、例題もあるのでありがたいです。

• 
  @kumonopanya28 күн бұрын

  どんな技術も使う人の力次第。面倒になったと思う人は技術力が未熟なわけだし、便利になったという人はうまく道具を使える人ってだけ。 さもNext.jsが悪いみたいに評価しているって人は、自分の力をまず評価してみては？

• 
  @gontacode302028 күн бұрын

  これ世の中のサイトでlayoutで認証やってる人多そうですね

• 
  @user-ng3on3nf9f28 күн бұрын

  初心者です！ Server Actions 内でセッション情報確認しなければならないということですが、それは middleware にてチェックできるのでしょうか？？

• 
  @user-ng3on3nf9f28 күн бұрын

  いや、厳しそうですね... 例えば Auth.js を使っている場合は、server actions 内で getServerSession とかでチェックしないといけないですよね。

• 
  @moozaru28 күн бұрын

  そうですね物理的にはできなくもないですが、Server ActionsのEndpointを特定するのが非現実的なので関数内部でチェックする必要があります。

• 
  @user-ieffc29 күн бұрын

  髭剃ったほうがよさそう、、、 生やすならおしゃれな感じで生やしてみては

• 
  @moozaru29 күн бұрын

  ありがとうございます。 苦手領域なのですが、がんばらないと、、

• 
  @user-re8tg7oh1k29 күн бұрын

  バックエンドをメインでやっていたのでNext.jsは知れば知るほど不便でめんどくさい。

• 
  @EICHANNELS29 күн бұрын

  Nextはちゃんと触ったことないのですが、こんな面倒なんですね。非常に面白い視点での会話でした。 開発規模にもよると思いますが、そこまでのリスクを背負って利用するメリットはあるんでしょうかね。。。優秀なエンジニアさんであれば生産性は上がって良いんでしょうが。

• 
  @takumifujise6137Ай бұрын

  これは言われないと気づかなそう。 私は普段Rails(+フロント構成のSPA)しか書いてないので、ここで話された地雷は意識しないと踏みそうだなと思いました。

• 
  @bbieyeАй бұрын

  いつも楽しく動画を拝見しています🥰 素人なのですが教えていただけないでしょうか。いろいろと気を付けないとNextの セキュリティは難しいということがわかりました。どうもありがとうございます😍 セキュリティを楽にできるように考えるとバックエンドを railsやLaravelでおこなって必要なデータだけフロントに出すようにしたらなど 考えてしまったのですが、お二人はバックエンドもNextでやる メリットや理由というのをお伺いしたいです。

• 
  @moozaru29 күн бұрын

  コメントありがとうございます！ まず、そもそもフロントエンドとバックエンドの距離がある事自体に不満がありました。従来のRailsだけ、Laravelだけで作る形式は良かったですが、そこからReactやVueが入ってきた時に２つのアプリを作っているかのような手間を感じてしまいました。そこにフロントとバックの境界線をなくしたように感じるNext.jsは個人的にはすごく良いです。 セキュリティに関してはNext.jsが弱いという事はなく、どのフレームワークを使っていても同じような問題は起こり得ます。 なので、あとは開発体験として自分にとってしっくりくるものを選んでもいいかなと思います。

• 
  @bbieye29 күн бұрын

  @@moozaru すぐに返信をいただいてどうもありがとうございます☺ 私はLaravlerだったのですが、今までは全部Laravelでやっていました。しかしフロントを柔軟に作りたいと思い、今バックエンドはLaravelそしてフロントはReactでやっているところです。 はい。おっしゃる通り、２つのアプリを作っている感じがありますね。Authなど、認可のCROSで手間取ってしまったりしてこれが、Next.jsで全部すればこういう苦労もないのかなと動画を拝見しながら考えました。 また、２つの開発サーバーを立ち上げながら、あそこを修正しないと、ああ、こっちのVSCODEじゃなかった、という感じも煩わしいなとも思いました。 Next.jsはDBを使わないちょっとしたものしか作ったものはないのですが、今後は丸ごと全部、Next.jsでやってみようと思います。どうもありがとうございました🥰

• 
  @user-vn4gn8ln3mАй бұрын

  dockerを覚えたくて以前見てて、まだ覚えられないですが、しばらくして見返してみるとめちゃくちゃ面白いですね！二人の会話が漫才に見えます✨🎵w

• 
  @SP-ct8ipАй бұрын

  クッキー🍪を、もぐもぐする説明がわかりやすくて覚えました😆 ありがとうございます!

• 
  @yutoriotsu8848Ай бұрын

  A philosophy of system designはコメントの書き方とか関数や名前の付け方みたいな経験則で流してたようなところもきちんと言語化されてたので面白かったです！ 他の2冊も読んでみたいです。

• 
  @moozaruАй бұрын

  おお！面白いですよね！ philosophy 読まれていたら tidy の方は読み応えがないかもしれませんが… ぜひ！

• 
  @user-zc5dk2jv9dАй бұрын

  オライリーさん、PDF版があるので好きです（英弱の私でもサクッとコピペでChatGPTに聞けるとこが特によいｗ）

• 
  @moozaruАй бұрын

  たしかにコピペで聞けるのめっちゃいいですね！ 僕は紙しか読んでないので…使えない技ですw

• 
  @yas-156Ай бұрын

  コンピュータ関連の用語はそのままカタカナになるパターンが多いし、使われる単語は大体決まっていて同義語を使いまくることもないし、構文も簡単で読みやすいと思います。慣れてくると日本語訳をせずに読めるようになってきますね。それで英語に自信が持てたと勘違いして他分野の書物に手を出してショックを受けることが多々ありますが。

• 
  @moozaruАй бұрын

  …ぼくも小説に手を出して一瞬で挫折しました。。

• 
  @user-uo4cx9su3xАй бұрын

  おひさしゅう😊

• 
  @user-gl2pj7wr4tАй бұрын

  素晴らしい👍

• 
  @user-pc6yw5ge4dАй бұрын

  いつも動画楽しく拝見してます！ 8:55 分割代入だとreadonlyが外れる、ということに触れられていましたが、これは特に問題ではないように思います。 関数の引数の型として設定するreadonlyの意図は、渡されたオブジェクトを書き換えないこと（副作用を生まないこと）がメリットです（そのため、 @ typescript-eslint/prefer-readonly-parameter-types のようなルールも存在します）。分割代入された場合、すでに元のオブジェクトとは切り離されて値のみが代入されていて、副作用を与える心配はないため、問題ありません。 Next.jsの件も、再代入することではなく、副作用を与えないことが目的だと思います。 引数への再代入を禁止したい場合は、ESLintの no-param-reassign ルールを使うのがよさそうです。 ちなみに自分もreadonlyをできるだけ使いたいと思っているのですが、実際のところ外部ライブラリの型が入ってくると途端に困難になるため諦めました…。

• 
  @moozaruАй бұрын

  コメントありがとうございます！ 副作用を生まないことというメリットの観点がすっかり抜けておりました..。おっしゃる通りですね！ また eslint についても教えて頂きありがとうございます！ > 困難になるため諦めました → なかなか難しいのですね...。

• 
  @naninanyaАй бұрын

  はじめてreadonlyを知ったときは、へーくらいだったけど、イミュータブルが実感できると好きになる。

• 
  @user-lm7sw1zb3oАй бұрын

  as const触れて欲しかったなぁ

• 
  @moozaruАй бұрын

  触れようかと思ってたのですが、長くなりそうで端折っちゃいました…涙 また機会ありましたら！

• 
  @mozart-2003Ай бұрын

  本当に強制しちゃうならESLintとかのLinterで縛るのが楽ですね

• 
  @willywonka6697Ай бұрын

  関数型プログラミングとは何ぞやっていう話が聞きたいです

• 
  @tomahoukuАй бұрын

  更新待ってました！

• 
  @moozaruАй бұрын

  ありがとうございます！

• 
  @yunWkcan8477Ай бұрын

  0:00 雑談 3:15 本編

• 
  @user-qf5rw4ky7l2 ай бұрын

  とても勉強になりました

• 
  @akakuro2242 ай бұрын

  いつかvimしたいなーと思い、gvim使っています。

• 
  @gohho_stpr3 ай бұрын

  ロック画面、莉犬くんじゃないか❤

• 
  @Futo210_MCJE3 ай бұрын

  初手からすんだもん女の子概念で脳が破壊された