依存する変数、プロパティ等に変更があると、
処理が発火すると理解している。

本システムで、どういうタイミングでしようするのがいいのか
現状あまりなさそう？

AmplifyがNextJS14に対応
server actionもできる

※この新機能を使用するには、アプリの最初のデプロイである場合、カスタムビルドイメージの値として amplify:al2023 を設定します。逆に、アプリがすでにデプロイされている場合は、ドロップダウンから Amazon Linux: 2023 イメージを選択します。

もっくん

プライベートでTDD入門して感じたこと

メリット

要件をよく理解できるため、「どんな価値を提供するか」を見失いづらい

デメリット

実装フェーズで、急遽実装方法に変更があると、テストコードも一緒に変更しないといけないため、工数が増える

所感

上記デメリットで書いたことが起きると、「実装→テスト」の順で書くことが多く、結局実装を満たすようにテストを書くようになってしまう。
そうなると、結果論ではあるが、最初から実装した方がよかったのでは？と思ってしまった
数日間しか経験していないので、熟練度が上がればもっと良さが出てきそう

Kenzo Wada

個人的な所感ですが、TDDはテストケースを元に実装進めると言う性質上、安全性をすごく担保する引き換えに実装速度が落ちるなぁとは感じています。
どこまでやるかですが、導入時はそこら辺も見極めたいなあと思いました。

Kenzo Wada

cliからstorybookを生成してくれる、storybook genieと言うものが最近出ていました。
openaiのAPIを使っているようなのでロバスト性が気になる部分ではありつつ、もしも精度が良ければかなり楽になるなあと。

かげやま

[調査] yarn dev遅すぎる問題を調査中

参考

K

クライアント側で直接revalidatePathを使ったrevalidateを実行しようとすると
Error: Invariant: static generation store missing in revalidateTag _N_T_/ja/setting/users
というエラーが表示される

エラーで検索したところ、同じ状況の人の質問を発見。
それに対する回答によると、どうやらrevalidatePathを使ってのサーバー側でのデータ取り直しをするためには、それらの処理を含む関数をサーバー側のコンポーネントでuse serverを使って定義し、Propsとしてクライアント側に渡して使う必要があるらしい

// こんな感じでサーバー側で定義してから、クライアントにPropsで渡す

  async function handleRevalidate(path: string) {
    'use server';

    revalidatePath(path);
  }

実際のやり取り↓

そのやり取りで紹介されていたドキュメント↓

Wata-Naoki

突然PostGraphileからクエリが消えた

特定のID(xxx_unit_id)をUNIQUEにすることで、postgraphile内のlistのクエリ(xxx_unit_id_list)が消えてしまうことがあった。

現状、解決策は以下。
別のクエリ（あれば）or クエリを組み合わせてフロント側で対処するか、バックエンド側でUNIQUE制約を外すか。

今後どう対処したか追記して参考になるようにしたい。

msickpaler

app routerのキャッシュ

キャッシュ設定の上書きを防ぐ方法

絶対にキャッシュを持ちたくないならroute segment configで`export const dynamic = 'force-dynamic'が必要

サーバー側でのキャッシュキー

data cache(サーバー側でのキャッシュ）ではヘッダー情報もキャッシュキーになる。
つまり、session-tokenもキーに含まれるのでユーザー間でのキャッシュの混同は起こらない
ただ、現状ドキュメントに書かれてないので信用できない状態。公式に書かれたら是非使いたい。

advanced

actionを使うことでjsなしでonSubmitやonClickを呼べる。つまり、これを設定するだけでプログレッシブ・エンハンスメントな実装ができる。（js使えない環境でも動くし、jsがあればリッチに動く）

そのうちstorybookもRSCに対応するっぽい

参考

よさ

CloudFrontにKVSできた
エッジでキャッシュサーバ