random.tagucch.dev

技術とかの雑なToday I Learnedメモ

今日のタブ記事、ページネーション、flatMap、mapの中のswitch-case文
TypeScript
JavaScript
flatMap

今日のタブ記事

フロントエンドエンジニアがスキルアップのために意識する「素振り」の仕方と求められる役割

これをいつ開いたのかは覚えてないけど、日付を見ると 2020-11-11 と書いてあるので比較的最近の部類に入る気もする。

内容を読んでみると、

  • フロントエンドは多様化してるし一昔前アプリ全盛だった時代と比べると需要も増えてるよね
  • スキルについては全体をやっていくか特化してそこに集中するかというのがあるけど、欲を言えば大枠いい感じにやりつつメインのことをやっておけば、すぐに活用できなくても活かすときが来たときに嬉しいよね
  • スキルアップのために素振りしよう
  • 試したい技術がある or 解決したい課題がある
  • Todoist にメモって、空き時間にチュートリアルなどをやるなどして理解を深め、応用ができそうなことを探して実際にそれをやってみる
  • とにかくメモって手を動かす
  • こういう素振りから自分の知識になり、さらにそこから仕事の打席に立つということもあるしそうなるといいよね
  • 副業もアリ
  • パフォチューと WASM がアツいぜ
  • 小さなことからチャレンジして日々それを積み重ねることが大事

という感じだろうか。

全体的に分かるし、今自分が実践できてないことが多いのでちょっとずつやっていくぞという気持ちになる。

Todoist というタスク管理ツールの話が出てきたけど、最近の自分は仕事以外のタスク管理みたいなものを全然していなくてグダグダな生活になっているし、仕事でもマークダウンフォーマットのメモ帳に雑に書いている感じなので、一度タスク管理やメモの管理については見直す必要があるなというのを思い出した。

雑に Boost Note にメモっているだけなので、いい感じのメモツールとタスク管理ツールを探す旅を始めなくてはいけない。タスク管理ツールを探すというタスクは脳内で管理するしかないな。

素振りについても言われたらまあそうだよなという気持ちになり、分かってはいるものの動けていないシリーズの筆頭ということで、もっと時間作って気になるもの試すような土壌を形成していきたい。

ページネーション

このブログはまだ初めて数日なので投稿数はかなり少ないけど、どんどん数が増えていったときに記事一覧をページネーションしたいなというのを思い出した。

SSG のページネーションってどういう感じになるんだろう……と思っているけど、まあ基本的にはシンプルに使える React のページネーションのライブラリを利用してクエリパラメータ渡していい感じにやる、みたいなことができれば充分かなと思っている。メモ置き場なので。

忘れないうちに Issue に書いておきます。

flatMap

JavaScript 書いてると配列の値を filter してその結果を map するみたいなことがちょいちょいあって、まあ愚直に filter して map したりしてたんだけど、なんか Iterator を 2 回回すのってパフォーマンス的にもっといい方法ありそう……とか思ってしまう。まあデータ数が莫大にならなければ大丈夫だと思うし、そこよりも気にするところは他にあるというのも分かるんだけれども。できるもんならベストを尽くしたいじゃないですか。

で調べたら以下の記事があった。

【JS】map と filter を両方同時に使いたい時の書き方 4 通り

知りたかったことがドンピシャで書いてある記事を見つけて喜んで読んだ。

この記事では filter してから map / map してから filter / flatMap / reduce の 4 通りのやり方がそれぞれ書いてあって、愚直に filter して map するのもまあ普通に分かりやすいしそれはそれでアリだなという気持ちにはなった。分かりやすいというのは大事。

ただ Iterator を複数回利用するのはやっぱり気が引けると思って、自分がもともと知っている reduce を使うのもいいかなと思った。が、この記事は reduce 酷評していて、理由もまあ分かるという感じだったのでおすすめしている flatMap を使ってみることにした。reduce は理解するまで時間かかったし、理解しても見にくいことに変わりはないのでまあ使いたくない気持ちは分かる(でも型定義ちゃんとしておけばある程度わかりやすくなるし実際便利だと思う)

flatMap を使ってみたところ、「めちゃ便利」という気持ちになり最高だった。

reduce みたいに accumulator に何が入っているかを考える必要がないのもそうだけど、「元の配列の要素すべてに対して同じ数の処理をして同じ数の結果を返す」という制約がなく、ひとつの要素に対して二つ以上の値を返したり、もしくは返さない(正確には返さないのではなくから配列を返す)こともできるので、元の配列の要素数という縛りがないのがいいと思った。

空配列を返すのがいわゆる「map の処理で return しない要素」を作ることができるのが良くて、つまりこれが filter と同等の機能ということ。で、あとは返すものを作り出せばいい(これが map の機能)

結果としてできる配列の中にある空配列は flatMap の内部でflatが呼び出されるので、深さ 1 の配列になり、空配列という要素は消滅するので結果として filter みたいなことができる、という感じの理解をした。

map の中で if 文書いて条件に当てはまらないものは空配列を返せばいいのでは？と思ったけどそれだとflatされないからダメだし、何も返さないとそもそも map が成立しなくなるので、めちゃ便利だと思った。

map の中で switch-case したら怒られた

flatMap の話したあとに map の話かいという感じだけど……

map は全ての要素に対して処理を施したあとそれを新しい配列の要素として必要とするので必ず return しなければいけないんだけど、switch-case 文でちょっと怒られたという話。

まず普通に switch-case 文を書いてそれぞれの case で return をしてハイおしまい、とした。

arr.map((hoge) => {
  switch (hoge) {
    case 'a':
    case 'b':
    case 'c': {
      return 'abc'
    }
    case 'd':
    case 'e':
    case 'f': {
      return 'def'
    }
  }
})

こんな感じ。

これだと「map は全部 return 必須だぞ」と怒られた。全部 return しとるやろがいと思ったけど、ちょっと考えて思いついたのは「もしかして全部というのはdefaultも含めてですか……？」という考えに至った。

結果としては正解で、

arr.map((hoge) => {
  switch (hoge) {
    case 'a':
    case 'b':
    case 'c': {
      return 'abc'
    }
    case 'd':
    case 'e':
    case 'f':
    default: {
      return 'def'
    }
  }
})

以下のように書いたら通った。

TypeScript を書いていて、case にある条件以外の値が入ってこないことが保証されているので、default要らんな……と思っていたが必要らしい。

余談だけど、return する場合は break 書かなくてもいいんだね(return の下の行に break 書いたら「到達不可能だよ」って言われた)

← Back To Home