random.tagucch.dev

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

コンポーネントにマージンを持たせないほうがいい理由、メモ帳どうする問題、Reactのチュートリアルを読む会、Redux Toolkitの話
JavaScript
React
Redux
Immer
okimochi

コンポーネントにマージンを持たせないほうがいい理由

ちょっと前にコンポーネントにマージンを持つのをやめてもらいたいひろゆきのコラ画像がバズってた。

あと@mizchiさんもスクリーンネームでコンポーネントにマージンを持つのをやめてほしい旨をアピールしている。

コンポーネントにマージンを持たせないほうがいいというのは、感覚的にはなんとなく分かるんだけど、もうちょっと詳細に言語化できたらいいな〜と思ったので記事を読んだりしてみる。

そもそもコンポーネントというのが再利用できる部品で、いわゆる pages みたいなページコンポーネントとかの話ではないという前提は文脈でなんとなく分かる。Atomic Design でいうところの Atoms とか Molecules あたりくらいのイメージをしている。

たぶん、マージンを持たせることで、複数の場所でそのコンポーネントを使うときに、使う側でコンポーネントの配置を調整したいのに、使われる側自身がマージンを持っているせいで使いにくかったりマージンを上書きしなきゃいけなくなったりするのがよくないんだろうな〜というのを自分はなんとなく考えていたが、他にデメリットはあるのだろうか。

UI コンポーネントにはマージンをつけるな！絶対にだ！！

なんとなく考えていたことが具体例とともに紹介されていて分かりやすかった。

簡潔に言うと、独自のマージンを持たせることでコンポーネントの汎用性が下がり、複数箇所で利用する頻度が上がるにつれ、マージンだけが違うが他は同じようなコンポーネントを作らなきゃいけなくなってしまう、ということ。コンポーネントの数が増えることでメンテナンスもしにくくなるし、いいことがないっぽい。

React で余白をどうスタイリングするか

これは冒頭に書いたツイートをした@seyaさんの記事。

「子コンポーネントが親コンポーネントの"レイアウトのスタイル"を知ってはならない」というのは、なんとなく考えていたことを端的にまとめるとこうなるなという分かりやすい一文だと思う。

マージンを持つ持たないで始めた話だけど、padding についても触れてくれていて、padding に関しては適切にであれば持たせても良いと書いてある。なるほど、たしかにそのとおりだと思う。記事内にもあるけど、当たり判定が見た目より大きいボタンとかのコンポーネントを作る場合は適切に padding をもたせればいい。

margin が誰の持ち物かというのは考えたことがなかった。基本的に子コンポーネントを利用する親コンポーネントのもの？というざっくりとした認識。

記事によると、親もしくは「誰の持ち物でもない」ということらしい。

Grid や Flexbox、ul などの子要素間のマージンが同一の場合は親の持ち物で、それ以外は誰の持ち物でもないということかな？

Flexbox の子要素と子要素の間のマージンはたしかに親の持ち物だけど、Flexbox と Flexbox のコンポーネントが隣り合っているときのマージンは誰の持ち物でもない、と言えそう。

そしてこの記事では「誰の持ち物でもない」マージンを Spacer というコンポーネントを利用するという提案をしていて、マージンを持つだけのコンポーネントを作るという発想が全然なかったのですごいと思った。

どのマージンが誰の持ち物かを適切に把握できるなら Spacer という概念はとてもよさそう。

メモ帳どうする問題

これ前にも書いたような気がする。

仕事や趣味において、タスクなどのまとまった作業を進めたり、そもそも何がタスクとして存在するのか確認したり、色々な場合においてメモという行為がかなり重要になってくると思っているんだけど、そのメモをどんなメモ帳に書いてどういうふうに保存してどういうふうに表示すれば最も自分にとって効果的なのかがよく分かっていない。

そもそも今のメモの管理は結構雑で、Boost Note というメモアプリの無料の機能だけ使ってローカルに保存している(一応 GitHub を利用してリモートにも保存できているとは思うけど、たしか 10MB くらいまでという制限があった気がする)

まずもってメモのとり方みたいなものが分かってなくて、どうやったら効率的なメモのとり方ができるのか分かってない。メモのとり方とかそういう本を読むべきか……？結局ロジカルシンキング的な話になる気もするけど。

メモアプリとかメモの管理とかどうしようと悩みはするものの悩むだけで実際になにかをしているわけではないので、ちょっとずつ調べたりしてメモアプリを探す旅に出ようと思います。おすすめあったら教えてください。

React のチュートリアルを読む会が会社で実施されている

平日の朝 10 時から React のチュートリアルを読む会をやっているらしい。

僕は朝が弱くて、だいたい 10:30 前くらいにようやく出勤ボタンを押すので今まで参加したことはないんだけど、React のチュートリアルを読むということ自体はとてもいいなと思うので、毎日ちょっとずつ読もうかな。

チュートリアルはありがたいことに公式で日本語訳もされているので、読むハードルはかなり下がりそう。明日から毎日ちょっとずつ読んでいきたい。

Redux Toolkit の話

React + Typescript プロジェクトに Redux Toolkit を導入したので使い方をざっくりとまとめてみる

Redux は導入のハードルが高いよね〜、でも Toolkit 使うことで余分な記述が減ったりよく使われているライブラリや記述方法があるのでベストプラクティスが定まった状態で開発できたり、というものらしい。これだけ聞くとかなりよさそう。特にチーム開発では書き方が定まっていたほうが迷わなくていいのでいいと思う。

Slicer という概念があり、これは Redux Toolkit 独自の考え方で、Reducer 関数と initialState を渡すと対応する Action Type と reducer を作成してくれるらしい。すご。

Slice のところで Immer というものを知った。

以下記事から引用

Immer を使わない書き方

builder.addCase(getLINEProfile.fulfilled, (state, action) => {
  return {
    ...state,
    userId: action.payload.userId,
    displayName: action.payload.displayName,
    pictureUrl: action.payload.pictureUrl,
    statusMessage: action.payload.statusMessage,
  }
})

Immer を使う書き方

builder.addCase(getLINEProfile.fulfilled, (state, action) => {
  state.userId = action.payload.userId
  state.displayName = action.payload.displayName
  state.pictureUrl = action.payload.pictureUrl
  state.statusMessage = action.payload.statusMessage
})

参考: Immer で Redux 周りをスッキリさせたい

たしかに分かりやすいけど、return がないとちょっと不安でゾワゾワする……。

Redux Toolkit はこの記事を読んだだけだと曖昧なところもあるので、なんかしら自分で触って作ってみたい。

← Back To Home