GitHub upinetree
Comment1
Like
Created atMarch 23, 2019 12:22
Updated atMarch 23, 2019 12:22

Questions and feedbacks (1)

upinetree
upinetree commented 4 months

@euglena1215

CSSの変更を行なったPRをレビューをする上で気をつけていることがあれば教えていただきたいです。

思いつくままにあげてみますね。

  • 実際の画面を見て意図通りに反映されていそうか
  • デザインカンプがあれば、それとの差異がないか、あっても意図的か
  • 他に影響していそうなところはないか、修正漏れはないか
  • CSSがチームのルールに沿っているか
  • クラスの命名は妥当か、BEMならコンポーネントの単位が納得できるか
  • CSSの定義の場所は妥当か
  • 既存クラスの再利用(HTMLからの参照とかextend)や mixin は妥当か
  • マジックナンバーはないか、変数化されているか、適切なコメントがあるか
  • いろんなデータを当てたときに崩れないか(データがないとき、多いときなどなど)
  • 他のデバイスでちゃんと動くか

あんまりCSSの個々の属性については見ずに、実際にあたっているスタイルを見て、その上で設計の妥当性とか、崩れるケースがないかとか、そういう観点でチェックしていることが多い気がしました。

@muryoimpl

使わなくなったviewを削除したときに影響するCSSの定義を削除するのは正直怖さがあるのですが、この恐怖に立ち向かうために何か気をつけている点、利用しているツール、手法はありますか?

個人的には、まずはセレクタの内容を手がかりに、特定できる可能性の高い単語で grep することから始めています。 BEMなどの命名規則を利用していれば簡単に判定できますが、多分そうではない環境でどう立ち向かうかということですよね。

その場合はビジュアルリグレッションテストが書いてあれば安心して削除できるかなと思います。それ以外の方法ではスタイルの変更を機械的に検知するのが難しそうだなあと思っています(結局CSSのシミュレータを作ることになりそう…)。

テストは、セレクタの内容を手がかりに影響範囲を絞れそうならその部分にだけテストを書くとかといった手抜きもできるかと思います。 削除の影響が全く読めないといった場合はページ全域のテストを書くことになってコスト大かもしれません。そういった環境ほどテストが書いてあると後々安心なのですが、まずは広範囲にピックアップしたテストを書くと、意図せぬ変更を検出できる可能性が上がってよいかと思います。

@minakawa-daiki

今後のCSSはどのように進んでいくのか、思っていること感じていること

CSS in JS の世界はとても動きやすくて個人的には大好きなのですが、SPAがそのプロダクトにマッチするかは別の基準があって、そうでない環境でどう立ち回るべきかというのはしばらくは考えていかないといけないかなと思っています。 また、CSS in JS ならではの複雑性の制御はきっと必要になってくるんじゃないかなあとも。

あとは WebComponents とか ShadowDOM 周りには期待しているのですが、まだ触ったことがないのでこれからやってみたいなあという感じです。

CSSフレームワーク(Bootstrapなど)を使用した場合、それに変更や上書きを施す場合、どのようにして設計、付き合っていけば良いのか

カスタマイズは結構難しいですよね…フレームワークが公開している変数とかを上書きする程度なら良いと思うのですが、振る舞い自体を変更し始めると、その部分は自分で別途定義しちゃったほうが面倒がないと思います。 その際はフレームワークのコードを読むと結構参考になりますね。

一部だけ読み込むことができるフレームワークであれば(Bootstrapはそうなっているはず)、使えそうなところだけ利用して、そうでないところは自分で定義するという手もとれるかなあと思います。 立ち上げを早くするという意味では便利に使えるので、役割を追えたときにスッと抜けるように小さく使っていくのがうまい付き合い方なのかもしれません。

Like(0)

This software is available as open source under the terms of the MIT License.
Copyright © 2018 Yoshiyuki Hirano