Closed18

【Next.js】「季語別俳句帖」開発記録【Figma】

zuzu

デザインできるところからデザインし、実装できるところから実装していく予定。

デザイン

figmaを使用。
アイコン類はfigmaプロジェクトとしてmaterial iconsをおいてある場所があるので、そこから流用。

【Material Icons】
https://www.figma.com/resources/assets/material-icons-outline/

【デザインプレビュー】
https://www.figma.com/proto/dblr2fcxBgSgsNfBfoFepC/画面一覧?node-id=11%3A94&scaling=min-zoom

実装

Next.js+TypeScriptでの開発を試す。テストどうしよう、の気持ち。

一応、Jestも入っている下記プロジェクトをボイラープレートに利用。

https://github.com/vercel/next.js/tree/canary/examples/with-typescript-eslint-jest

認証周りにfirebase使ってみようと思うのだが、firebase authentification用のテンプレもあったので、うーん。

zuzu

ランディングページ

写真を使うことも考えたが、ユーザが俳句愛好家=テキスト大好きな人たちだと思うので、キャッチコピーのみ。

ログインと新規登録の導線に関して、ヘッダ部分はGitHubを参考にした。

zuzu

ちなみに、アイコンはHatchfulというサービスで作りました。めちゃめちゃ中華フォント。これはこれで雰囲気があるが、直すかもしれない。

zuzu

利用規約とプライバシーポリシー

広くユーザーがアカウント登録して利用することを想定したサービスを作るのは初めて。
メールアドレス等のデータをこちら側で持つことになるので、どう考えても規約がいるなと気づき、新規登録画面に同意ボタンを配置した。

規約の内容は、https://kiyaku.jp/index.html を参考にさせていただくことに。
markdown形式に変換、適宜書き換えてレポジトリに含めた。

zuzu

小さなコンポーネントから作っていく。

コンポーネント志向のいいところは、componentsができてなくても、とりあえず適当にモックしておいてpagesを並行して作れるところだと思っている。

とはいえ、すっからかん状態のpagesを作るのもいささか味気ないので、なるべくcomponentsの見た目だけは仕上げてしまってから、ページ作りにとりかかりたい感。

まあ、途中で飽きたらpages組めばいいし。

ファーストリリースまでは気長にやろう。

zuzu

認証機能

実装(というか設計)前に、ちょっと調べておく。
https://firebase.google.com/docs/auth/where-to-start?authuser=1

Firebase Authentificationを使用して新規に認証機能を実装する場合、

  1. ドロップイン UI ライブラリの FirebaseUI Authを使う方法
  2. 独自にUIやフローを制御できるFirebase Authentification SDK(長いな)

を使う方法があるらしい。
今回に関しては、勉強のためにSDKのほうを使う。(爆速で言えば前者なんだろうけど)

デザイン周りにフェデレーションIDでのログインを含めてなかったので、どうしようか悩み中。
今時必須だろうけども、後から追加でいいかな、という気分。

zuzu

ログイン画面実装(見た目)

素材がそろってきたので、ログイン画面の見た目だけとりあえず実装。走り出しの三連休の作業はここまで。
一旦コミットを作成する。

zuzu

デザイン終了

とりあえずいまのところ見えている必要な画面はデザインFIX。(FIXとは言ってない)

zuzu

スマートなNext.js x Firebaseの認証実装サンプル

Implement User Authentication With Next.js and Firebase by Jake Prins in @BttrProgramming https://link.medium.com/1ICDr3KUKbb

ここまでできたら文句ないね〜

zuzu

デザイン資料と実装の乖離が始まる

もうわからん、デザインわからんと思っていろいろ試すノート的な使い方をし始める。

カラーコードも初期は丁寧にまとめていたが、結局よさそうなものを下記からとってくることに。

https://color.adobe.com/ja/

一人開発だからいいもの、ちょっと嫌な予感がしている。

zuzu

ここはある程度割り切ることにした。開発終わった後資料を整理するかどうかは未定。
今後もちょくちょく修正があるたびにデザイン資料とコードの同期を取るのはしんどいので、デザイン資料はあくまでドラフトとして位置づけ。

zuzu

Firebase hostingでデプロイしようといろいろ捏ねたがうまくいかず。素直にVercelにテストデプロイ。うまくいった。

zuzu

アドベントカレンダーネタとして、「そもそもなんで作ろうと思ったのか?」という部分を言語化しておこう。
根っこの部分には
・現職で積めないスキルを積むため
・ポートフォリオに書けるものを増やすため
があるけども、実際に続ける原動力になってるのは
・シンプルにこれが完成してくれないと自分が困る(使いたい)
というのがある

zuzu

propsでスタイル指定を一部受け取れるようなコンポーネント、どうやるのがベストプラクティスなんだろう?
たとえば表示・非表示を切り替えられるコンポーネントがあったとして、

type Props = {
  display: 'block' | 'none'
}

とかして貰ったCSS値をそのまま適用する、みたいなのは隠蔽の仕方として正しいのか?
状態のパターンによるか。CSSプロパティを一部露出させるという考え方ではなく、表示・非表示が「どういう状態」を意味するのか明確なら、それで受け取ったほうがいい気がする。
(というか、親に知らせずにうまくやる方法があるならそれが一番良いのだろうけど)

このスクラップは2021/06/03にクローズされました