ゆとり日記

心にゆとりを持って生きたいプログラマーの雑記です。気が向いたら書きます。

【React】Goodpatch×TeamSpirit Meetupに参加してきた

teamspirit.connpass.com

↑のイベントに参加してきました。
(通常枠で申し込んだつもりでいたが、直前になって「ブログ執筆枠」で申し込んでいた事に気づくという阿呆ぶりを発揮。)

  • フロントエンドエンジニア3年目。
  • Redux + React + Node.jsのSPA開発を1年くらいやってる。
  • Reactに若干飽きてる

こんな人間から見た感想を書いていきます。

各LTの感想

※発表者の方の資料は、展開され次第追記していきます。

LT1 Reactのパフォーマンスを改善する必要が無かった話

チームスピリットさんが開発してるプロダクトがReactで開発されていて、それのパフォーマンス改善の話を聞いた。

結論はLTのタイトルにもある通りでそこまでパフォーマンスを改善する必要が無かった、とのこと。普段から設計やコードレビューに気をつけていた甲斐もあって、現状のパフォーマンスは悪くないし、改善を試しにやってみても0.01秒くらいしか変わらなかったらしい。

「Reactは最初から、ある程度のパフォーマンスを保てるようにできてる。」と言いつつも、何も考えずに開発を進めていると徐々にパフォーマンスが悪くなるので、以下のような事を開発の際に意識していたそう。

  • stateを浅く保って、再レンダリングの効率を良くする。
  • スプレッドオペレータでpropsを全部渡すのを避ける。(ついついやってしまいがち)
  • 更新の前後でstateが同一でも再レンダリングが走るので、shouldComponentUpdateやpureComponentの使用を検討する。
  • Perfでコンポーネントの描画速度を計測する。

パフォーマンスが悪くなってマジで困ったら、Perfで何とかするそうです。

感想

以前は自分も「スプレッドオペレータでpropsを全部渡す」をやってしまっていたので、同じ道を通った人がいて親近感を感じた。
やはり、必要なものだけを渡した方が無駄なprops比較も無くなるし、コードの見通しも良くなって良いですね。

自分が関わっているプロダクトではrecomposeのpure、shouldComponentUpdate、onlyUpdateForPropTypes辺りを使って、再レンダリングの負荷を出来るだけ軽減してたりします。

github.com

あと、スライドにちょいちょい挟まれる「いらすとや」の画像がジワジワ来て面白かった。

LT2 いまSPAを作るなら〜Prott2の技術選定のウラガワ〜

Goodpatchのよしこさんのお話。
Prottをリニューアルする動きがあるらしく、リニューアル時に使用する技術選定の話を聞いた。

  • React
  • Redux
  • AVA
  • Flow
  • styled-component
  • yarn

この辺りの技術を使用する予定らしい。「Goodpatch = Angular」みたいなイメージを持っていたので、Reactに舵を切るのは正直意外だった。

  • Web標準に即していて、剥離しすぎていない。
  • ある程度枯れていて、情報が多い。
  • エコシステムが多い。
  • ある程度枯れている。
  • Angularの使い勝手は好きだが、情報が少なく枯れていない。
  • Angularをちゃんと書ける人よりも、Reactを書ける人の方が多いので採用も楽。

といった感じの選定基準(+Angularを選定しなかった理由)らしい。

Reduxを入れた理由は「オレオレFWへの恐怖」だそう。Reduxのstate管理は良いと思いつつも、middlewareを使ったりせずに薄く使っていくつもりらしい。
middleware不要論についての参考リンク

Flowを入れた理由は、やはり型が欲しいから。TypeScriptは候補に上がったものの、言語そのものをスイッチするよりもJSに型チェックを入れる方がライトに感じて、Flowに決めたそう。(ただし、Flowはハマりどころが多いそう)

とはいえ、まだ始めたばかり。Reduxを脱却するかもしれないし、TypeScriptに移行するかもしれないとのこと。

感想

複雑な物を作ろうとすれば、何を使おうが大変になるだろうなーと思う。自分も1年間Reduxをやってきて、多くのメリットを感じつつもかなり苦労したので・・。

Flowは導入時に結構辛い思いをしたが、入れた方がコードの品質は高まっている感覚がある。

LT3 React沼 CSS Architecture

React沼CSSArchitect // Speaker Deck

試用期間中にReact、webpack、1つの巨大なSassファイルと戦った話を聞いた(個人的主観)。

「Reactでの画面のコンポーネント化は進んでいたが、CSSは1つのSassファイルに集約されていた。」 webpackによる長いコンパイル時間、CSSの見通しの悪さをどうにか解決したかったので、技術的にCSSを解決するアプローチを始めたらしい。

とはいえ、ツールは設計の解決までやってくれるわけではない。その辺りは別で考える必要があるので、BEMを使って設計アプローチを試みたそう。最終的には「単純で誰でも理解できる設計」に落ち着いたとのこと。

コンポーネントの粒度は、JSとCSSで1:1」の原則で運用。CSSのimportルールとかも資料に詳しく書いてあるので、読むと良いかもしれない。

React-Storybookを使って、コンポーネント単位でのサンドボックス環境を作っているらしい。作った理由は、webpackのビルドが遅かったから。今後はstorybookを使って、styleguideにしていく計画もあるそう。

感想

自分も昔はBEMでCSS設計をやっていたので、苦労は凄く理解できた。特に「クラス名考えるのが大変」って辺りの件は非常に共感。 (正直、もうBEMを使いたいとは思っていない)

今のプロジェクトではCSS in JSを使っているので、今後別の仕事をする際もそれで行きたいなーって気分でいる。

スタイルガイド作るのメンドイ。

パネルディスカッション

LT後はビールを飲みつつ、スピーカーの方々のパネルディスカッションを聞いてました。

色々議題は合ったんですが、その中で印象に残ったものを少しだけ触れます。

デザイナーとの協業について

会場で話を聞いた限り、コーディングまでやるデザイナーさんは稀らしい。
Goodpatchさんでも、フロントエンドとデザイナーの業務は明確に分かれていて、デザイナーさんがコーディングまでやることは基本的にないそう。

「コーディングまで綺麗にやってしまうデザイナーさんは、もはやデザイナーという枠を超えた存在なのでは・・」という気がしてる。

ReactとjQueryの共存

結論から言えば、共存は可能。とはいえ、「jQueryが必要になる場面は殆ど無いのでは?」という意見も出ていた。

自分もReactやり始めの頃は「jQueryの世界に帰りたいよぉ・・」とか言ってたので気持ちはすげー分かる。
今ではReactにすっかり慣れたので、「アニメーションさせるなら、jQueryの方が楽だな・・」というくらいの心境。

react-sketchappでスタイルガイドを作る

github.com

Airbnb凄い。

スタイルガイドを運用する上で起こりがちなのが、「実装とスタイルガイド間のズレ」。スタイルガイド側への反映が漏れていて、気づいたらスタイルガイドが役立たずになってるアレです。

これを技術で解決しましょう、ってことでreact-sketchappの出番が来ます。 要するに「作った画面をSketch上に描画する」という仕組み。こうすることで、実装とガイド間のズレを無くそうって話です。

今まで使ってなかったけど、ちょっと興味を惹かれたので試してみようと思っています。

まとめ

翌日早起きしないといけなかったので、懇親会に出れなかったのが心残り。
スピーカーの人が作ったという、ローストビーフが食べたかった・・(ヽ´ω`)。

あと、話に上がっていたAtomicDesignの本が面白そう。

bradfrost.com

第二回があれば、是非参加したいなと思います!