↑のイベントに参加してきました。
(通常枠で申し込んだつもりでいたが、直前になって「ブログ執筆枠」で申し込んでいた事に気づくという阿呆ぶりを発揮。)
- フロントエンドエンジニア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辺りを使って、再レンダリングの負荷を出来るだけ軽減してたりします。
あと、スライドにちょいちょい挟まれる「いらすとや」の画像がジワジワ来て面白かった。
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でスタイルガイドを作る
Airbnb凄い。
スタイルガイドを運用する上で起こりがちなのが、「実装とスタイルガイド間のズレ」。スタイルガイド側への反映が漏れていて、気づいたらスタイルガイドが役立たずになってるアレです。
これを技術で解決しましょう、ってことでreact-sketchappの出番が来ます。 要するに「作った画面をSketch上に描画する」という仕組み。こうすることで、実装とガイド間のズレを無くそうって話です。
今まで使ってなかったけど、ちょっと興味を惹かれたので試してみようと思っています。
まとめ
翌日早起きしないといけなかったので、懇親会に出れなかったのが心残り。
スピーカーの人が作ったという、ローストビーフが食べたかった・・(ヽ´ω`)。
あと、話に上がっていたAtomicDesignの本が面白そう。
第二回があれば、是非参加したいなと思います!