Open18
仕様書とはちょっと違うかもだけどフロント開発にあたっていろいろ決まっとかなきゃいけないこと（開発ルールとかも）
kzk4043SLA
##どうやって決める？
シェア率ベースでお客様次第
kzk4043URL設計
パスパラメータとクエリ
画面内でタブで切り替えるみたいなやつは中身次第？←このUI自体微妙なのか？
kzk4043- パスパラメータ
- kebab-case
- クエリパラメータは
- camelCase：これが多い印象
- under_snake_case：これも次くらいに多そう
- kebab-case：あんまり見ないけど、パスと揃えればよくない…？
kzk4043日付
RFC3339が良さそうか
スラッシュはエンコードされる
kzk4043エリアとか階層性のある動的変数
- クエリなのかパスなのか
- エリア情報は必須かどうか（省略したときどうなるのか）→これはエリアに限らんが
- 例えば銀座をどう表現するのか
- パス
-
/kanto/tokyo/ginza- パスならこちらがいいかも
/ginza
-
- クエリ
-
/?lRegion=kanto&mRegion=tokyo&sRegion=ginza- これは冗長になりそう。パスじゃないなら省略したい
- 包含関係をどう取得するか
-
/?sRegion=ginza- 基本はこちらがよさそう
-
- パス
- 例えばmRegion配下のsRegionが全て選ばれた場合
- sRegion全て並べるのか
- mRegionに格上げするのか→こっちの方がよさそう
- 値は数値などのIDなのか、ginzaなどのwordなのか
kzk4043画面一覧
- 画面IDは振る？振っても使うのか問題。振らない場合の表記揺れ
- 連番の場合、間に差し込んだら修正範囲がでかい
- IDだけでは中身が想像できないので、ワンクッション必要
- 振らなかった場合に画面名修正が大変
kzk4043エラー遷移どうする？
表示系APIが死んだ場合の対応
- 画面ごとに必須、非必須APIを分ける？
- 非必須APIが死んだらトルツメ
- 画面を気にせず必須、非必須APIを分ける？
特定APIだけが死ぬケースというのは結構あるのか？基板ごと死ぬパターンがほとんどでは？
post時のエラー
エラー内容をレスポンスして表示？
kzk4043ログレベル
kzk4043コンポーネントの挙動
- プルダウン、チップなどの選択挙動
- 複数選択
- 複数選択がANDなのかORなのか
- 単一選択
- その他注意
- 例えば検索一覧などで、対象項目の選択肢がない場合、選択肢をdisableにするのか、選択は可能にするか
- 複数選択
kzk4043アニメーション
- easing
- ease in
- あんまり使う印象がない。
- アニメーションの始まりが分かりづらい
- 徐々に加速するのは自然ではあるが、それが最高速になった時に終わってしまうので、ちょっと不自然な印象になってしまう気がする
- フェードアウトで使う？
- ease out
- ユーザアクションに対するリアクションとしては優秀
- なにかユーザによるアクションで動いた印象になるので、ユーザの帰属感は上がる
- ただ、個人的には唐突な印象
- フェードイン？
- ease in out
- 徐々に加速し、徐々に減速して止まるので、自発的に運動する物体の動きに近い。
- 個人的には一番自然で使いやすい
- デフォルトの3次ベジェ曲線だと野暮ったい感じになりやすいので、もっと急激にすることが多い
- ease in
kzk4043API設計
- 命名認識の統一
- XXXFlagじゃなくて、isOpen的なtrue/falseが何を意味するのか明確な命名
- 単語の統一＞単語リスト作成
- 値は素の値をいれる
- 表示はフロントでコントロールする
-
10時とかで送ると取り回しがしづらい