【Next.js】「季語別俳句帖」開発記録【Figma】
zuデザインできるところからデザインし、実装できるところから実装していく予定。
デザイン
figmaを使用。
アイコン類はfigmaプロジェクトとしてmaterial iconsをおいてある場所があるので、そこから流用。
【Material Icons】
【デザインプレビュー】
実装
Next.js+TypeScriptでの開発を試す。テストどうしよう、の気持ち。
一応、Jestも入っている下記プロジェクトをボイラープレートに利用。
認証周りにfirebase使ってみようと思うのだが、firebase authentification用のテンプレもあったので、うーん。
zuランディングページ
写真を使うことも考えたが、ユーザが俳句愛好家＝テキスト大好きな人たちだと思うので、キャッチコピーのみ。
ログインと新規登録の導線に関して、ヘッダ部分はGitHubを参考にした。
zuちなみに、アイコンはHatchfulというサービスで作りました。めちゃめちゃ中華フォント。これはこれで雰囲気があるが、直すかもしれない。
zu利用規約とプライバシーポリシー
広くユーザーがアカウント登録して利用することを想定したサービスを作るのは初めて。
メールアドレス等のデータをこちら側で持つことになるので、どう考えても規約がいるなと気づき、新規登録画面に同意ボタンを配置した。
規約の内容は、https://kiyaku.jp/index.html を参考にさせていただくことに。
markdown形式に変換、適宜書き換えてレポジトリに含めた。
zu小さなコンポーネントから作っていく。
コンポーネント志向のいいところは、componentsができてなくても、とりあえず適当にモックしておいてpagesを並行して作れるところだと思っている。
とはいえ、すっからかん状態のpagesを作るのもいささか味気ないので、なるべくcomponentsの見た目だけは仕上げてしまってから、ページ作りにとりかかりたい感。
まあ、途中で飽きたらpages組めばいいし。
ファーストリリースまでは気長にやろう。
zu認証機能
実装（というか設計）前に、ちょっと調べておく。
Firebase Authentificationを使用して新規に認証機能を実装する場合、
- ドロップイン UI ライブラリの FirebaseUI Authを使う方法
- 独自にUIやフローを制御できるFirebase Authentification SDK（長いな）
を使う方法があるらしい。
今回に関しては、勉強のためにSDKのほうを使う。（爆速で言えば前者なんだろうけど）
デザイン周りにフェデレーションIDでのログインを含めてなかったので、どうしようか悩み中。
今時必須だろうけども、後から追加でいいかな、という気分。
zuデプロイ先はぶっちゃけどこでもいいんだけど、firebaseで統一してみるかな、など考え中
zuログイン画面実装（見た目）
素材がそろってきたので、ログイン画面の見た目だけとりあえず実装。走り出しの三連休の作業はここまで。
一旦コミットを作成する。
zuデザイン終了
とりあえずいまのところ見えている必要な画面はデザインFIX。（FIXとは言ってない）
zuCloud Firestore VS Realtime Database
pros/consはありつつも、ここのアンケートに回答することで、どっちがいいか大体決まるっぽいです。
zuスマートなNext.js x Firebaseの認証実装サンプル
Implement User Authentication With Next.js and Firebase by Jake Prins in @BttrProgramming https://link.medium.com/1ICDr3KUKbb
ここまでできたら文句ないね〜
zuデザイン資料と実装の乖離が始まる
もうわからん、デザインわからんと思っていろいろ試すノート的な使い方をし始める。
カラーコードも初期は丁寧にまとめていたが、結局よさそうなものを下記からとってくることに。
一人開発だからいいもの、ちょっと嫌な予感がしている。
zuここはある程度割り切ることにした。開発終わった後資料を整理するかどうかは未定。
今後もちょくちょく修正があるたびにデザイン資料とコードの同期を取るのはしんどいので、デザイン資料はあくまでドラフトとして位置づけ。
zuFirebase hostingでデプロイしようといろいろ捏ねたがうまくいかず。素直にVercelにテストデプロイ。うまくいった。
zuアドベントカレンダーネタとして、「そもそもなんで作ろうと思ったのか？」という部分を言語化しておこう。
根っこの部分には
・現職で積めないスキルを積むため
・ポートフォリオに書けるものを増やすため
があるけども、実際に続ける原動力になってるのは
・シンプルにこれが完成してくれないと自分が困る（使いたい）
というのがある
zupropsでスタイル指定を一部受け取れるようなコンポーネント、どうやるのがベストプラクティスなんだろう？
たとえば表示・非表示を切り替えられるコンポーネントがあったとして、
type Props = {
display: 'block' | 'none'
}
とかして貰ったCSS値をそのまま適用する、みたいなのは隠蔽の仕方として正しいのか？
状態のパターンによるか。CSSプロパティを一部露出させるという考え方ではなく、表示・非表示が「どういう状態」を意味するのか明確なら、それで受け取ったほうがいい気がする。
（というか、親に知らせずにうまくやる方法があるならそれが一番良いのだろうけど）
zuほうちなう