- Remix App Server以外の選択肢？
- cssファイルのモジュール化
- ルートベースでcssをつけ外しできるとは言っても、クラス名の衝突の回避が保証されているわけではない
- https://github.com/remix-run/remix/issues/571
- cssファイルの置き場
- ファイルシステムベースのルーティングだから勝手にディレクトリ掘れないし、同じ構造のstylesディレクトリを横に並べるしかないのかな？
- all active routesからexportされているlinksを束ねて表示するための
<Links />コンポーネント- 吸い上げられるかどうかのルールがよくわからない
- /prisma下にdev.dbが作られない
- そういうものだっけ？
- ts-nodeの代わりに `node --require "esbuild-register" なるほど
- prismaのクエリで取る情報を絞ることでクライアントに送る情報を減らす
- actionとコンポーネントで相互に情報を送り合うところはぐちゃぐちゃにならないか不安
- ユーザーからのアクションはhtmlのformとactionで処理する仕組みになっているが、これで十分柔軟なアプリケーションを作れるのか
- サーバー側/クライアント側の区別がファイル名の規則しかないのは不安
- 壊れるようなファイル名をつけてみるとどうなるのか
- そもそもroutes下のファイルはサーバ/クライアント共用なので思わぬ情報漏えい等を防げるか
- remixの挙動をある程度理解していないと怖い
- createCookieSessionStorageはpurely cookie-based sessionsを作る
- https://stackoverflow.com/questions/18239816/django-difference-between-database-backed-sessions-and-cookie-based-session
- getSession, commitSession, destorySessionはいずれもcookieを目的語とする
- getSession: クライアントから受け取ったcookieをparseしてSessionを得る
- commitSession: Sessionをserializeしてcookieに書き込む（Set-Cookieヘッダに書き込める状態にする）
- destroySession: 空のSessionを作成する（これをSet-Cookieすることでクライアント側のcookieを消す）。引数としてsessionを取っているが要らない
- Sessionはクロージャを利用したオブジェクトであり、Mapのデータと各種アクセサを持つ
- cookieはクライアント側に保存されているので積極的に消すことはできないが、サーバー側でparse/serializeに使うsecretを変更することで無効化はできる
- headerのCookieを読み書きする処理を手書きしなきゃいけないのは割とローレベル
- utils/session/server.tsにredirect処理まで置くのは責務が分散していると思う
- action肥大化するなぁ〜
- actionがformと紐付いているのでPOSTを使うためにformを設置するなどということが起きる
- LoaderFunctionの返り値型をジェネリクスで指定できない