こんにちは、フロントエンドチームの @syo_igarashi です。
今週のフロントエンド定例の内容を記載します。
フロントエンド定例について、以前の記事（ランサーズのフロントエンドチームが取り組んでいること）でお伝えしたのですが、毎週金曜日に開催しており、実際の業務で取り組んでいることや気になった技術情報等をシェアしあう会になっています。
以下、今週の内容です。
API検証メタ
Chrome デベロッパーツール上で検証することが多いです。
理由としてはAPIのリクエストの条件としてCookieの値を使用することが多いので、対象の画面のドメインのURL適当に開いて デベロッパーツール上のコンソールに Fetch API を入力してリクエスト / レスポンスの内容を検証するようにしています。
await (await fetch('https://api', {
method: 'POST',
headers: {
'content-type': 'application/json',
},
body: JSON.stringify({
// なにかテストしたいリクエストパラメータ記載
})
})).json()デベロッパーツール上だとTop level awaitがサポートされているからできるawaitの書き方だったりします。
注意としてfetchにさらにjsonもしくはtextなど本文の内容を解釈する処理をさらに記載しないとデベロッパーツール上のResponseやPreviewで見ても確認できない場合があるようです。
文字折り返しパターン
文字列の長い場合の検証は
半角文字のみで文字列多いパターンと全角文字列も入れた文字列多いパターン
を考慮していた方が良いというやつです。
word-break: break-all; を入れていれば問題ないかもですがたまに入れ忘れててレイアウトの崩れを発生させるということがあるかもしれません。
ショートハンド記述
だいぶ宗教的な話ですがどのくらいみんな書き方知ってたり、許容してるのか気になっているやつです。
ゲーム系とかだと計算済みの数値が細かい小数点込みのデータがあってただし表示上では小数点切り捨て表示にするからそのときの値を
const value = 33.333333333333333....
const displayValue = ~~valueでチルダ（ビット演算）を使った小数点切り捨てとかみたことあったなぁという記憶があります。
（~~が多いからあの人のコードは泳いでるというネタ化されました）
個人的にやってる記述を列挙します。
短絡演算子（||や&&）
デフォルトや値がないときのメッセージとかのときに || を使うことが多いかなという気がします。
// valueが存在しないときは'値が存在しません'
const message = value || '値が存在しません'一方で && は値が存在するときに適応させたい場合にに多用してます。
// messageが存在するときのみdivの表示を行う
{message && (<div>{message}</div>)}あと && はオブジェクト・連想配列が深いデータのときとか
const object = {
hoge?: {
fuga?: {
value: string
}
}
}
{object.hoge && object.hoge.fuga && (<div>{object.hoge.fuga.value}</div>)}みたいなのを一時期書いてましたがoptional chainingが書けるようになったことで
const value = object.hoge?.fuga?.value
{value && (<div>{value}</div>)}でよくなったというのもありますね
変数の値がundefined、null、0、”もfalse扱いとする
「これははたして型安全なのか？」、「ちゃんとキャストすべき」という派閥の方もいると思うのでだいぶ揉めそうな変数の条件の見方になるのかなぁと思ってたりしつつ、コードとして書きがちな物だったりします。
const message = ''
// messageが空文字なので表示しない
{message && (<div>{message}</div>)}キャストすべき派はなんとなく、
{!!message && (<div>{message}</div>)}! を2回入れてbooleanにしてから表示を行うようなコード書きそうですよね。
型安全なのか？疑問に思う方だとComponentでハンドラ内にさらに実行可能な関数をOptionalに扱っている実装上とかで
if (typeof onChange === 'function') {
onChange(event)
}と書いて型条件もみて堅く作ってそうですよね。
その点自分はTypeScriptで
type Props = {
onChange?: React.ChangeEventHandler<HTMLSelectElement>;
}
onChange && onChange(event)みたいなonChangeが値として存在するときはEventHandlerの関数なんだろう（確定）というのを書きがちだったりします。
次回の更新予定は、7/8（金）になります！
前回の定例内容はこちらから確認可能ですのでご興味いただければ下記のリンクから閲覧いただければと思います。