2023年7月学んだことまとめ

Published
2023-08-08
Author
びきニキ
Tags

びきニキです 今月ハックツで個人的に学んだことを放出します🦊

💻 エンジニア勉強会

ハックツの技術顧問である@apple_yagi に色々聞く会です。毎週木曜日開催です。

今回は自社開発でCSS-in-JSの技術選定をする必要があり、調べた上で分からなかった部分を質問しました。それを踏まえてそれぞれの特徴をここに書き起こしておきます!

CSS-in-JS

JavaScriptを用いてCSSを記述するアプローチのこと。スタイルをコンポーネント単位で定義するのが特徴で、メリットは以下の通り。

  • コンポーネントごとにスコープが分離されるため、スタイリングの隔離が容易になる。
  • JavaScriptを使用するので、条件に応じてスタイルを動的に変更できる
  • 変数や関数を使ってスタイルを再利用できる→コードの重複を減らすことができる


ランタイムCSSとゼロランタイムCSS

CSSには、「ランタイムCSS」と「ゼロランタイムCSS」という2つの種類があります。

ランタイムCSS

  • ページロード時にCSSが生成され、そのスタイルがページに適用されるもの。
  • ユーザーの操作や状態に応じてスタイルを変更したり、動的に生成されるコンポーネントにスタイルを適用したりできる。
  • Styled ComponentsやEmotionなど


CSSというのは静的に決まっているはずなのに、CSS-in-JSはページを表示するときに毎回再計算するからそれがデメリットだと言う人もいるみたい👀

だけど今まで表示速度が気になったことはない人が大半だと思うから、気にしなくていいのでは?という意見の人も一定数いるぞ!


ゼロランタイムCSS

  • JavaScriptがページのロード後に実行されず、ランタイムでのスタイルの生成や適用が一切行われないCSS-in-JSのアプローチのこと。
  • スタイルの生成や適用がコンパイル時に行われる。JavaScriptの実行は不要で、通常の静的なCSSと同様にページのロード時にスタイルが適用される。
  • styled-componentsのServer-Side Rendering(SSR)モードやGatsby、Vanilla-Extracなど。ビルド時にスタイルが生成され、HTMLにインラインスタイルとして挿入される。


npm trendsは鵜呑みにしない方がいい

今回調べていく中で、npm trendsを確認することもありました。「Compare package download counts over time」と記載されている通り、ダウンロード数を比較するサイトになるのですが、ここで1つの疑問が浮かびました。


Emotionの方がStyled-Componentsよりも後発なのに、ダウンロード数が圧倒的に負けている…。」



…自分の周りや技術記事投稿サイトを見ていても、近年はEmotionの方が人気がある印象を受けていたんですが「ここまで差が開くほど、後発のEmotionには無くて、Styled-Componentsしかない良さがあるのか?」と思い、気になって質問しました💡


結果として、なんでここまで差が開いていたのかというと「人気のあるライブラリの中に使われている」ということが原因としてありました。今回の場合だと、Emotionを作るためにはStyled-Componentsが使われていました。

つまり、Emotionをインストールするとそれを使うためにStyled-Componentsもインストールすることになるので、EmotionがStyled-Componentsのダウンロード数を抜かすことはないのです!知らなかったな… というわけで、npm trendsは鵜呑みにしない方がいいということも学びました!多分これはGitHubのスター数とかに対しても言える話で「利用者の数が多いからといって、脳死で使うのは危険」という話でもありますよね…。

また、テストコードについてもいろいろ意見を頂いたので、備忘録として内容を書いておきます。

全て一から作る必要はない

一般ユーザーと管理者ユーザーでログイン時の表示が異なり、それぞれの表示を確認するテストを書いているとします。このような場合に私は毎回新規のアカウントを作成していました。

そうするとその分コード量も増えますし、手順が複雑な場合などはその分可読性も下がっていきます…。(今回の例は単純なものですが、実際はもっと複雑なものをテストを実行する都度作成→削除していました)


しかもしかも!戒めとしてここまで書いちゃいますが、そういう「実際にやりたいテストのための事前準備用テストコード」を全てutilファイルに突っ込んでいました😅 反省しています…

バラエティに富んだ事前準備のコードをutilに突っ込んでいたおかげで、事前準備のコードが他の事前準備コードに依存していたりという恐ろしい状態に。

依存性が高く、可読性も低いため、唯一の実装者である私が「もう見たくもない(=保守できない)コード」が完成しました!めでたくないな!


コードを通して1からすべて作るのではなく、用意できるものはデータとして作成しておく重要性を教えてもらいました。さっきの例の話だと「一般ユーザー」と「管理者ユーザー」はこちらで使い回せるものを用意しておくとか!そうすると、実際のE2Eテストではログインするだけで表示を確認できますよね。


手作業でQAするときは毎回アカウントを新規作成するなんてことは絶対しないのですが、こちらに関しては人に指摘されるまで気づきませんでした…。 依存は敵!分離できるものはしっかりと分離して、共倒れしないように作っていくことが大事だと痛感しました。


🎨 デザイン勉強会

私の都合に合わせて不定期開催される、デザインについての質問会です。

@PINEyuto3 がアレコレ答えてくれます!

しかし、今月はあまり時間を取ることが出来ませんでした…。反省、来月に期待です👀


🐶 最近のびきニキ月報

  • インターンとして勤務した株式会社PR TIMSを退社しました
  • インターンとして株式会社メルペイに入社しました
  • そろそろ就活終わりて~~~~~(ずっと言ってる)