UIT#6 進化する React.jsに行ってきました
UIT#6 進化する React.jsへ行ってきていろいろと聞くことができたので、自分のメモがてらいろいろと記載します。
Hooks で作る React.FC
資料 : https://speakerdeck.com/takefumiyoshii/hooks-tezuo-ru-react-dot-fc
サービスフロントエンドとアニメーション
アニメーションを控えるべきアプリケーション
- 速度表示が重要なメディア媒体
- 遷移が頻繁なアプリケーション
- 素早い入力応答が重要なアプリケーション
情報伝達・情報編集がコアバリューにあるものはアニメーションを控えるべき。 求めていないアニメーションは帰って悪目立ちする。
アニメーションを推進すべきアプリケーション
- ゲーミフィケーションを含むもの
- インセンティブを含むもの
- 概要認知が困難なもの
- 構成要素が複雑なもの
明確なユーザーストーリーが描かれているものはアニメーションを活用するべき。 機能としてアニメーション設計をすることで、コンバージョン達成戦略をすることができる。
「機能としてのアニメーション設計」5つの言語化
1.通知機能
利用者が提供者に興味がないフェーズ
- 認知が目的であるため、悪目立ちさせない
- 余程重要でない場合、UI操作を奪わない
2. 補佐機能
利用者が提供者に興味があるフェーズ
- アプリケーションのチュートリアルなど
- UIを理解するための、提供者からの説明
- UI操作を奪った方が、りかいに繋がりやすい
3. 認知機能
利用者が提供者を理解するフェーズ
- 現在位置を認知させるためのトランザクション
- 動きが「情報伝達の認知」を促す効果がある
4. 対話機能
利用者が提供者と対話するフェーズ
- ユーザー操作に従順な反応を、快適に感じる
- ユーザー操作と異なる反応を、不快に感じる
- リアル・コニュミケーションと同じ。話の腰を折らない
対価機能
利用者が提供者を評価するフェーズ
- アプリケーションからの要求対価（複数・必須入力項目など）
- 一連の行動対価として演出で応答
- 応答の好感度がPRに直結する可能性がある
アニメーションはコンバージョン達成の鍵
明確なユーザーストーリーがある場合、終点の「対価」がコンバージョンと一致する。 アニメーションは要所要所で重要な構成要素となり得る。
フロントエンドの裁量で決まるアニメーション。アプリケーション価値を最大化させる余地は残っている？
React HooksとAnimation
従来の React × Animetionの課題
- cssアニメーションが非同期そのもの
- Class Componentに変換する手間
- cssに関する知識が必要
- 手軽さはなく、優先順位としては低いもの
機能要件・非機能要件・テスト >>> アニメーション
react Hooksの登場
- Domの短形がFunction Componentでも取得可能になった
- Function Componentでも状態がもてるようになった
状態管理に及ぼす影響は?
- Reduxの責務の一部が見直されるようになった。
- Reduxを代替するものではない
- Statefull componentの状態管理を代替する
Hookをあえて使う必要はない 従来のStatefull Componentと非同期middleWareでもスタックとしては問題なく実現できる
アニメーションのこれから
- React Hooks で容易に実装することができる
- アプリケーションとの対話であることを意識
- アプリケーション特性に基づいた設計を
フロントエンドエンジニアはユーザーにサービスを届ける最後の砦。
聞いた所感
- 弊社の制作側は知らないけど他の企業のサービス側だとちゃんとユーザーのことを考えてアニメーションを入れてる感じがあって楽しそう
フロントエンド = css好きっていう認識だったけど(自分がコーダー上がりなのだからかも。)、CSS描きたくない派閥とかあるの初めて知った。(単にjsとcss分けると見づらい・管理しづらいからいやだみたいなのとかかも・・・)- React Hooksおもしろそう。
PageStack in React again
資料 : https://speakerdeck.com/sunderls/pagestack-in-react-again
webかネイティブか
- webかネイティブか
→ 気にしない - App storeかSafariか
→ App Storeの方が良い
ネイティブの方がwebよりスピードが早い(コンマ秒くらい)がそんなに変わりはない。 ページ遷移などの動きはネイティブの方がストレスフリー
webでもネイティブのような動きをさせる方法
https://engineering.linecorp.com/ja/blog/line-manga-smooth-page-transition-with-page-stack/
聞いた所感
- ネイティブのような動きは気持ち良さそうだけど、個人的にどっちでも良い感。。(やってたらすごいと思うくらいでやっていないからといってそのサイトから離脱は別にしないと思う。)
現場から届けるReactプロジェクトの悩みと改善
資料 : https://speakerdeck.com/mukai21/xian-chang-karajie-kerureactpuroziekutofalsenao-mitogai-shan
Reactプロジェクト改善概要
どんな状況か
- フロントエンドチームは15人
- BtoBの管理画面サービスを実装
- 機能追加・改修は平行でいくつも行われる
- 新たに刷新する
どんな変更をしたか
- React + Typescriptの導入
- SassからEmotionへ変更
- Redux-Formからformikへ
- Reduxの構成を変更
React + Typescriptの導入
TypeScript採用前
- 頑張ってJS Docを書いていた
- しかしコードに影響はないので、更新されずに放置されていることも
- メンテナンスが辛い
TypeScript懸念点
- TypeScriptを使ったことがないメンバーが多い状況でスピードは遅くならないか(15人中14人は触ったことがない状況)
- 使えないライブラリとかあるのではないか
- そもそもほんとに良いものなのか
採用前に行ったこと
- TypeScriptの勉強会
- サンプルを実際に作って使ってみる
採用した感想
- 使えないライブラリはなかった
- 基盤はわかるメンバーで実装し、それを参考に他のメンバーも実装ができるようになった
- 開発がしやすくなった
- propsにどんなデータがやってくるのかわかりやすい
- たまに型理論が切れた実装がある → よりレビュー大事に
SassからEmotionへ変更
詳しい資料 : https://qiita.com/sakito/items/d240840eef7123f62acf
- どの部分にスタイルが当たっているのかわかりやすい
- コンポーネントを削除するときにスタイル一緒に削除できる
- styledとcsspropの2つが混ざっているのでどちらかに統一したいという話が出ている
まとめ
- その他にもいろいろな改善を行った
- 例
- Atomic designの採用
- コーディングルールの議論
- webpack周りのビルド改善
- etc...
聞いた所感
- TypeScriptをほとんど触ったことのない中で導入したのはすごいと思う。
- Atomic designの実装の方法がフロント3人に対してデザイナーが1人体制で実装しているといっていたのでやっぱりAtomic designをプロジェクトに導入するならデザイナーが必要だと思った。(デザイナーに応じて切り分けが違う場合もあるのでデザイナーのレビューもちゃんとやった上で)
- TypeScriptおもしろそう
全体的な所感
- 会場がLINEだったので、すごく広くておしゃれ(あと新宿駅直結だった)
- 単純に実際の業務でどんな感じでReactを使われているのか知りたくていったけどAtomic designやアニメーションについても軽く聞くことができたのでよかった
- カンファレンスみたいな硬い感じでなく、内容もわかりやすかったのでとても楽しかった
- LINEのエンジニアがどんな感じで働いているのかなどの本やUITのシールがもらえたのでよかった。
最後に
UITのメディアが新しく立ち上がったとのこと(週に1回のペースで更新していくらしい) https://uit-inside.linecorp.com/
