koichi-omae / fwywd-task-lv1 Goto Github PK

primary-xl などはばらした方が良いでしょう。
理由としては Tailwind CSS の標準ではなく、他の人がプロジェクトに入ったときに可読性を下げてしまうためです（チームを前提に理解のコストも考慮していきましょう）

逆に btn-sm のようにボタンは共通項を設けて、btn-green などをオプションでつけると良いでしょう。

img というディレクトリに格納していて素晴らしいですね！
意外とここに手を抜いてしまうことがあるので public/img/** とできているのは良いことです！

ファイル名が Camel や kebase-case の混在がありましたので、ここを統一しましょう！
基本的には kebab-case で良いのでは無いかと思います。

• PageHeaderの作成
• PageFooterの作成
• Hero1の作成
• Main(夢を叶える仲間が欲しい、あなたへ)
• Main(あなたが本気で変わるために必要な
  2つの条件)
• Main(料金)
• Hero2の作成
• Pagesに完成したcomponentの配置

SWR は Client Side Rendering (CSR) でデータを毎度フェッチしてきます。
そのため、クライアント側でどこの API を取ってきているかがわかってしまいます。
Stein では URL からある程度使い方が想像できてしまうため、SSR や ISR で API のフェッチ先を隠すか、pages/api に入れて URL を隠すなどの工夫が必要でしょう。
今回の要件であれば ISR がベストでしょう。

• Atom Textのテキスト文の修正
• Atom UnderLineのテキスト文の修正とglobals.cssにテンプレート追加
• Template SympathyとBenefitにUnderLineのテンプレートに変更
• Template Pricingのカードの箇所のtailwindcssをcursor-pointerを追加

ここは少し惜しいですね！

Atomic Design では atom, molecule, organism, template, page となっていますが、現実のプロジェクトではもう少しうまく分けたほうが良いでしょう。
例えば、私が最近組んでいる中でたどり着いた結論は以下のとおりです。

• atom で CSS レベルの実装
• molecule で必要最低限必要な要素の組み合わせ（多くのプロジェクトで共通して利用するもの）
• project で Presentational/Container Component の実装（プロジェクト名は適宜合わせる）
• common は今回使用しませんが、必要に応じて共通プロジェクトで利用するコンポーネントを格納すると良いでしょう。

• Textの作成
• ボタンの作成
• TailwindCSSのColorの設定
• UnderLineの作成
• Iconの作成
• Logoの作成
• Tagの作成
• global.cssにてTextのテンプレートを作成

• 資料ダウンロード のLink先設定
• useSWRを使って資料をダウンロードした人数を取得する実装
• Template PageFooterのtailwindcssの変更
• React Scrollの実装完了

Next.js の公式サイトを確認して、設定の変更がないかを確認しておきましょう！
Jest や Babel など、これまで結構変更が加わってきました。
リリース後にあとから変更することは時間経過とともに難しくなってくるため、リリース前に必ずチェックしておきましょう！

template として利用するものは特にこの傾向があります。
pages の実装に不必要な引数が含まれていたため、この点の複雑性を解決できるでしょう。

バッチリでした！

こちらもバッチリですね！
切り分けが意識できていて素晴らしいです！

こちらもバッチリでした！

知っているか知らないかの差ですが、こちらを読んでみましょう！

https://www.conventionalcommits.org/ja/v1.0.0/

各コンポーネントの記載漏れなどを考慮して、簡単で良いのでテストを書いておきましょう。

バッチリですね！流石です！

バッチリでした！
※ 確認後に Close していただいて大丈夫です。