非常に個人的なメモ
atsuo MURATA多分一番便利な正規表現 試行錯誤サイト
これはやってないけど、正規表現学ぶならいいかもれんとは思う
atsuo MURATA課金先、codepen か codesandbox 考えてたけど codesandbox にしよかな
yarn workspace と併用できっかな
atsuo MURATAこりゃいいね。テキストベースのコミュニケーション、
特にコードレビューなんかはキツイ印象を与えがちだから
... これはやりようによったら要修正レベルの明示とか色々使いみちがあるかもしれないなー
「Nit: 」（あら探しや細かい指摘という意味） それか！
atsuo MURATAとにかく高速化・軽量化
高速化に関してはこのコメントにまとめようかな っていうかテーマごとにまとめるか
ちょい古いがまあ基礎的なことなので読む価値ある
画像表示の高速化
てか仮でぼやけた超軽量画像を表示しといて、あとからまともな画像に差し替えるやりかた（探してた
blurhash の typescript 実装もある。
個人的にも試してみたい
atsuo MURATA【デザイン】
いいねぇこれ はー
「コンポーネント単位で探しつつサイト上からコピーして、そのままFigmaに貼って編集できる」
atsuo MURATAgraphql のディレクトリ構成に関して考える
要件だけれども、このあたりでどれを優先順位の上位に置くか
- 検索性の高さ
a. 置き場所が即座にわかる - 実装速度
a. 脳死で query とかディレクトリ分けして置ける - generated なカスタムフックが重複しない
てまあ当座は 1と2だな。
パフォーマンス・チューニング的に問題が出始めたら 3 を気にすべきって話になってくるはず。
ちょっとこの辺ごく個人的にわだかまりがあるんだが、一旦置こう。
あ、パフォーマンス・・チューニングは別軸の話になるが、回線速度わかりゃ画像の質落とすとかで対応いけねぇものかな？ジャストアイデア。違う。今直面してるアレだとデバイスで・・ゴニョゴニョ
1 おまとめパターン
こちらではこのような構成
├── graphql
│ ├── generated
│ │ ├── hooks.ts
│ │ ├── operations.ts
│ │ └── types.ts
│ ├── mutations
│ └── queries
ただし以下も半ば納得。
Apollo GraphQL Blogのこちらの記事によると、GraphQLクエリはViewに含めた方がいいと述べられています。
基本的にデータの取得と表示はセットで、どちらかに変更がある場合はもう片方も修正する必要があるためこれらは近くに置いておいた方がいいとの理由からです。
Apollo GraphQL Blogの当該記事はこちら
2 所謂 organisms に相当するレイヤー各所に置くパターン
上記の最後の引用から、、というわけではないが、最初に考えたのがこれ。
ちょうど論拠が見つかった感じ。
graphql ファイルが散らばっていても query.graphql, mutation.graphql 所謂 organisms に相当するレイヤー あたりに置いておけばほぼ脳死で置き場所わかるし、探すのもヨユーってことで一案と考えた。
このケースでは frangment の置き場所が問題となる。
さーどこへ置くのか。。そしてそれを探す手間は？？既存のドキュメントがあったりするケースでは、一度決めちまえば全体検索で一発なはずと思ってる。
3 Fragment Collocation
以下のような課題が解決したとのこと。だが、、、
・課題1. BFFとの通信回数が多い
→ 各ページのレンダリングに必要な項目をFragmentとしてまとめ、単一のクエリを投げるようになったので、1回の通信で済むようになった
・課題2. クエリを書く際に必要な項目が漏れていたり、不要な項目が残ったままになる
→ コンポーネントに必要な項目をコンポーネントファイルと隣接したFragment定義ファイルで管理しているため、ページとコンポーネントの依存関係が弱まり、型安全に項目の漏れや不備を防げるようになった
・課題3. ドメイン知識をもったコンポーネントの振り分けルールが曖昧
→ domain/下のディレクトリ分けをGraphQLスキーマベースにしたことで、メンバー間で解釈が異ならないルールになった
page単位で取得する情報が決定されていれば有効そうでエレガント。
でもそうでない場合は？ pageで表示されるべき値が変更されるたび全体更新が走る？
構成次第だし、そんな雑なことにはならないとは思うんだが、もしそうなるとまずい
となると memo ればよいのではということになるわけだが、あまりそのあたりの知見がない。
あ、 Apollo なんで Reactive Variables でよしなに更新ってことも検討できるかな
いや、、、違うかな。この辺読んどけ自分
ディレクトリ構成関係ないけど、 query の命名規則も検索性と脳死実装性高められる部分やな
atsuo MURATAmarkdown 表変換ツール
atsuo MURATATypeScript の型めんどい時結構ありますね〜
atsuo MURATA細かいJavascriptとかフロントエンド全般のチューニング