# 2022/01/26 メンター相談

###### tags: `メンター相談`,`1月`

## アトミックデザインについて、Atomsで色やフォントサイズ、パディングだけ違うコンポーネントをどのように定義すればよいでしょうか

> 色やフォントサイズごと組み合わせる場合、CSSのクラスをどれを使うかみたいな分岐を発生させるのでしょうか？それともStyledComponentなどでPropsから色などを受け入れるようにしているのでしょうか

- propsを使うほうが好き
- 親でクラスを子に渡す -> any型を使っているような状態
- 何を渡されても受け入れなければいけない
- スタイルが上書きされてしまう可能性がある
- コンポーネントの責務が曖昧になってしまう
- クラスの組み合わせで組み合わせてはいけ無いクラスを組み合わせてしまう可能性
- お互いを打ち消してしまう
- 制御できない
- 親が詳細を知らなくて済む
- mode: "red" | "green" | "blue" など
- 詳細なcssなどを知らずに見た目を変えることができる
- styled-componentじゃないときどうやってやる？(質問)
- props経由で渡す
- 何をこのコンポーネントが許すのか
- 設計の原則が適用される
- tailwindを使っている場合、どうやってやる？(質問)
- tailwindの色を渡したいときどうする？(質問)
- tailwindの辞書を用意するかも
- colors.red = "tailwindの赤色"
- 仕様が変わったときに対応できるようにしたい
- 汎用コンポーネント内で定義しないほうがいいものの例
- コンポーネントの外側のことについて知っているような例
- margin
- flex-shrink

## ユースケース層とドメイン知識の違いについて

> アプリケーションのルールをいくつか書き並べた時、現実世界にあるルールはドメイン知識、アプリケーション上のルール（バリデーション等）はユースケースに分類できるという認識で良いか。(参考: https://little-hands.hatenablog.com/entry/2019/07/26/domain-knowledge）

- バリデーションには種類がある
- ドメイン知識上のバリデーション(現実世界の知識)
- ユーザー名は3文字以上
- ソフトウェアだからこそのバリデーション
- リクエストの大きさ (1Gb以上なら弾く)
- サニタイズ
- ドメイン知識が含まれる場合がある
- どこに書くのか
- presenterなど一番外側でやる場合も多い
- 認証をどこでやる？
- ドメイン知識ではないのでドメインではない
- ユースケースは詳細を知らないようにしたい
- firebase? / oauthどれをつかっているのか
- presenterで認証し、認証完了したよというオブジェクトをユースケースに渡して処理をする
- プレゼンテーション層で認証するメリット
- 認証のミドルウェアの差し替えがやりすい
- ユースケース層のテストがやりやすい
- リクエストのサイズに基づくバリデーションもpresenterでやる場合が多い
- ユースケース層の責務は「何をどの順番で呼び出すか」にとどまる場合が多い
- 2つのドメインエンティティにまたがる認証(？)をどうやるか(質問)
- 存在するかの確認はドメインサービスに寄せられることが多い

## 実際にcontainer/presenterのコンポーネント分割を行うことはありますか？(フロントエンド)

> 現在はあまり使用することが無いのではないかと思いました。

- 分けるメリット
- storybookでいろんな状態を表現しやすい
- →リグレッションテストを書きやすい
- 状態が複雑なコンポーネントの操作は大変
- presenterなら再現しやすい
- 逆にstorybookをあまりつかわないのであれば、メリットはあまりないかも
- hooksによってあまり使われなくなった みたいな話はたまにみる
- 提唱者もブログに書いていた
- ページのトップレベルで使う事が多い
- page
- データ取得
- 固有の値の埋め込み
- template
- 受け取ったものを表示するだけ
- ロジックが多いページは大変そう (質問)
- 関数の実行はバケツリレーしている？(質問)
- バケツリレーしている
- つらくない？ (質問)
- 何を渡しているかが明示されている
- 記述量は増えるが、辛くはない
- モダンなやり方かはわからない

## 「State hooks を理解して ToDo アプリを実装しよう」の「課題3」について

> アトミックデザインの概念に沿って実装したこちらの課題を振り返り、任意のコンポーネントを「Container」と「Presentational」に分割してみてください

について、

アトミックデザインにおける 「template層」 が 「Presentational」、 「page層」 が 「Container」 に対応している認識で、
「template層」以下のコンポーネントを[受け取ったものを表示するだけ]のシンプルな作りにしていたため、リファクタリングする部分が見つかりませんでした。

この認識(対応関係)は正しいでしょうか？
また、この課題ではどのようなリファクタリングを想定していましたか？

(回答)

- もしはじめからきれいに分けられているなら、リファクタリングの余地はなさそう

## SSR/SSG/CSRの選択について、あえてCSRを選択する場合はどのような場合があるでしょうか？

> 「SSR/SSGは必要ないからCSRを選択する」のように、消極的な理由で選択される事が多いのかな、と思いました。

- あまりないかも
- googleによると
- CSR: ページをjsでレンダリングすること
- zennのCSRの使い方について
- 恐らく
- ダッシュボードはSSRする必要がない
- インデクシングしないため
- 頻繁に変わるのでキャッシュも使えないため
- サーバーに負荷がかかるのを防ぐため

## その他

- Next.jsのapi機能の使い所
- バックエンドとの間に噛ませるくらいの使い方しかしたことがない
- BFFのような立ち位置になるかも
- メリット
- apiのエンドポイントがバレない (大本のエンドポイントがバレない)
- キャッシュとして使えなくもないかも、、？
- モック用途として使うかも
- 続きは来週