Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Hooks で作る React.FC<Animation>
Search
Takepepe
March 20, 2019
Technology
5.2k
4
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Hooks で作る React.FC<Animation>
UIT#6 進化する React.js
発表資料
https://uit.connpass.com/event/119594/participation/#participants
Takepepe
March 20, 2019
More Decks by Takepepe
See All by Takepepe
聞き手の目線で考えるプロポーザル
takefumiyoshii
0
900
どの様にAIエージェントと 協業すべきだったのか?
takefumiyoshii
2
1.2k
ServerAction で Progressive Enhancement はどこまで頑張れるか? / progressive-enhancement-with-server-action
takefumiyoshii
7
1.4k
App Router への移行は「改善」となり得るのか?/ Can migration to App Router be an improvement
takefumiyoshii
8
3.9k
フロントエンドの書くべきだったテスト、書かなくてよかったテスト
takefumiyoshii
40
18k
Webフロントエンドのための実践「テスト」手法 CodeZine Night #1
takefumiyoshii
24
11k
Next.js でリアーキテクトした話 / story-of-re-architect-with-nextjs
takefumiyoshii
12
9.3k
より速い WEB を目指す Next.js / nextjs-make-the-web-faster
takefumiyoshii
54
22k
フロントエンドの複雑さに耐えるため実践したこと / readyfor-nextjs-first
takefumiyoshii
25
11k
Other Decks in Technology
See All in Technology
10Xに技術的負債をもたらした「2つの境界の歪み」その構造と解消への営み
10xinc
0
380
AI時代、データエンジニアが一番おもろい
genshun9
0
280
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
12k
DEFCON34-Write-up_HYCu-MYCu
daikiokazaki
0
150
[2026-09-11]SREは誰のもの?運用エンジニアが始める 「SRE領域への越境」とチームの進化の軌跡 〜Road to NEXT CRE
tosite
0
170
Claude Code本って、 読む必要あるの?
oikon48
2
430
薬剤師(ドメインエキスパート)と一緒に育てる薬局向けAIアシスタント
kakehashi
PRO
2
160
事業課題から技術的負債に向き合う
sansantech
PRO
1
220
越境するなら専門用語を使うな高校校歌 / If you wanna cross border, you shouldn't use jargon
vtryo
0
120
HRC_Frontend_Conference_Fukuoka_2026.pdf
ts020
0
600
AI時代だからこそ、スケールしないことをやろう
yutashigemura
1
160
SQL文一行も書けない人事がCortexもろもろを使って人事業務を楽にしてみる
ponponmikankan
1
220
Featured
See All Featured
The Language of Interfaces
destraynor
162
27k
AI: The stuff that nobody shows you
jnunemaker
PRO
9
990
Learning to Love Humans: Emotional Interface Design
aarron
275
41k
Docker and Python
trallard
47
4.2k
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
1
380
How to Grow Your eCommerce with AI & Automation
katarinadahlin
PRO
1
270
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.6k
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.4k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
HU Berlin: Industrial-Strength Natural Language Processing with spaCy and Prodigy
inesmontani
PRO
0
700
30 Presentation Tips
portentint
PRO
1
390
Technical Leadership for Architectural Decision Making
baasie
3
560
Transcript
Hooks で作る React.FC<Animation> @ Takepepe / UIT#6 進化する React.js
@Takepepe 吉井 健文 DeNA デザイン本部 デザインエンジニアリングG
▪ サービスフロントエンド・アニメーション ▪ React Hooks と Animation
サービスフロントエンド・アニメーション
アニメーション「ネガティブ要因」 ▪ 冗長な画面遷移 ▪ 機能と連動していない動き(ただ派手でカッコ良い) ▪ ブラウザ本来とは違う動き(予測不能なインターフェイス) ▪ テストが辛い、アニメーションの為にテストコードが冗長に
アニメーション と UX ブラウザ閲覧が主戦場となるフロントエンドでは、 いかに表示速度を向上するかが課題。 メディア媒体など、表示速度が定量指標となる場合 「速度 === UX」と言っても過言ではない。
アニメーション と UX GUI アプリケーション としての特性が強い場合、 「速度 === UX」と一辺倒に言い切れない。 アプリケーション特性を理解したうえで、
アニメーションを考察する必要がある。
アプリケーション特性とアニメーション
アニメーションを控えるべき・アプリケーション ▪ 表示速度が重要なメディア媒体(Read 要件) ▪ 遷移が頻繁なアプリケーション(Read 要件) ▪ 素早い入力応答が重要なアプリケーション(Write 要件)
アニメーションを控えるべき・アプリケーション 「情報伝達、情報編集」がコアバリューであるものは アニメーションを控えるべき。 求めていないアニメーションは返って悪目立ちし、 不快で使い辛いと感じる。
アニメーションを推進するべき・アプリケーション ▪ ゲーミフィケーションを含むもの(Play 要件) ▪ インセンティブを含むもの(Play 要件) ▪ 概要認知が困難なもの(Help 要件)
▪ 構成要素が複雑なもの(UI 要件)
アニメーションを推進するべき・アプリケーション 明確なユーザーストーリーが描かれているものは アニメーションを活用するべき。 機能としてアニメーション設計をすることで、 コンバージョン達成戦略とすることが出来る。
「機能としてのアニメーション設計」5つの言語化
1. 通知機能 ▪ 提供者の主張に起因するもの ▪ 認知が目的であるため、悪目立ちをさせない ▪ 余程重要でない場合、UI 操作を奪わない 利用者が提供者に「興味がない」フェーズ
2. 補佐機能 ▪ アプリケーション開始時のチュートリアルなど ▪ UI を理解するための、提供者からの説明 ▪ UI 操作を奪った方が、理解に繋がり易い
利用者が提供者に「興味がある」フェーズ
3. 認知機能 ▪ 現在位置を認知させるためのトランジション ▪ どの様な遷移が発生したのかを「数百ms」で視覚伝達する ▪ 動きが「情報構造の認知」を促す効果がある 利用者が提供者を「理解する」フェーズ
4. 対話機能 ▪ ユーザー操作に従順な反応を、快適に感じる ▪ ユーザー操作と異なる反応を、不快に感じる ▪ リアル・コミュニケーションと同じ。話の腰を折らない 利用者が提供者と「対話する」フェーズ
5. 対価機能 ▪ アプリケーションからの要求対価(複数・必須項目入力など) ▪ 一連の行動対価として演出で応答 ▪ 応答の好感度が「RRに直結する」可能性がある 利用者が提供者を「評価する」フェーズ
アニメーションはコンバージョン達成の鍵 明確なユーザーストーリーがある場合、 終点の「対価」がコンバージョンと一致する。 利用者にコアバリューを届けるまで、 アニメーションは要所要所で重要な構成要素となり得る。 通知 > 補佐 > 認知
> 対話 > 対価 CV
フロントエンドの裁量で決まるアニメーション。 アプリケーション価値を最大化させる 余地が眠っているかも?
React Hooks と Animation
従来の React x Animation の課題
従来の React x Animation の課題 ▪ アニメーションが、非同期処理そのもの ▪ 関数型指向による Class
Component の肩身の狭さ ▪ Class Component に変換する手間 ▪ CSS に関する知識が必要(CSS書きたくない派閥)
従来の React x Animation の課題 アニメーションのためだけに、 Class Component への変換は大儀。 手軽さは無く、優先順位としては低いものだった。
機能要件・非機能要件・テスト >>> アニメーション
React Hooks の登場
React Hooks で Class Component が不要に ▪ DOM の矩形が Function
Component でも取得可能になった ▪ Function Component でも状態が持てる様になった ▪ Life cycle hook と同等の事が可能になった ▪ メモ化が随所で簡単になった
React Hooks が状態管理に及ぼす影響は? ▪ Redux の責務の一部が見直される様になった ▪ Redux を代替するものではない ▪
Statefull Component ( Class Component ) の状態管理を代替する
Statefull Component といえばアニメーション。 アニメーション・コンポーネント作り放題!
たくさん作ってみた
React Hooks 大喜利 昨年末 React Hooks 発表直後、 「React Hooks で作る
GUI」と称し、 アドベントカレンダーとして 24作例 を github に公開 https://github.com/takefumi-yoshii/react-hooks-ogiri
React Hooks 大喜利 実装 TIPS も Qiita に24記事。 ▪ Cusotom
Hooks に責務分割する ▪ Presentational 層 と Hooks 層 は別居する ▪ Memoize をさぼらない あたりがポイント https://qiita.com/Takepepe/items/8bf3a1a519cb293d220b
Animation 処理だけ Custom Hooks に切り出し const ref = useRef<HTMLButtonElement |
null>(null) const { handleMouseDown, handleMouseUp } = useRippleEffect({ ref, effectDuration: props.effectDuration })
const ref = useRef<HTMLDivElement | null>(null) const { itemWidth, itemHeight,
nodeStyle, containerStyle } = usePhotoCarousel({ ref, imagesCount: props.images.length, imageRatio: props.imageRatio, transitionInterval: props.transitionInterval, transitionDuration: props.transitionDuration, onChangeCurrent: props.onChangeCurrent }) jQuery Plugin を彷彿とさせる optional injection
<Container> <Presentational /> </Container> <Container> <CustomHooks> <Presentational /> </CustomHooks> </Container>
従来の Presentational Component の 上位レイヤーとして ※ DOM 構造概念図であり実コードではありません
const PieChartContext = createContext( {} as ReturnType<typeof usePieChart> ) const
Provider: React.FC = props => { const ref = useRef<HTMLDivElement | null>(null) const value = usePieChart({ ref, padding: 0.05, centerCircleRadius: 0.3 }) return ( <PieChartContext.Provider value={value}> <div ref={ref}>{props.children}</div> </PieChartContext.Provider> ) } Custom Hooks を Provider に Embed
export default () => { const { rectSize, centerCircleRadius }
= useContext(PieChartContext) return useMemo( () => ( <View rectSize={rectSize} centerCircleRadius={centerCircleRadius} center={rectSize * 0.5} /> ), [rectSize, centerCircleRadius] ) } useContext による子の Orchestration
Hooks で 0 〜 1 の Animation 係数を更新 <Provider customHooks={customHooks}>
<SVG> <Hooks useContext={providerContext}> <Element /> <Element /> </Hooks> <Hooks useContext={providerContext}> <Element /> </Hooks> <Element /> </SVG> <Hooks useContext={providerContext}> <Presentational /> </Hooks> </Provider> useContext で係数を利用し、 各々のユースケースを算出。 style などに適用 ※ DOM 構造概念図であり実コードではありません Animation 進捗に応じた変化
const ref = useRef<HTMLDivElement | null>(null) const [rect, setRect] =
useState({ width: 0, height: 0 }) useEffect(() => { const handleResize = () => { if (ref.current === null) return const { width, height } = ref.current.getBoundingClientRect() setRect({ width, height }) } handleResize() window.addEventListener('resize', handleResize) return () => window.removeEventListener('resize', handleResize) }, []) DOM 矩形取得だけ Custom Hooks に切り出し
const ref = useRef<HTMLDivElement | null>(null) const [rect, setRect] =
useState({ width: 0, height: 0 }) useEffect(() => { const handleResize = () => { if (ref.current === null) return const { width, height } = ref.current.getBoundingClientRect() setRect({ width, height }) } handleResize() window.addEventListener('resize', handleResize) return () => window.removeEventListener('resize', handleResize) }, []) 分割 した Custom Hooks を 1つの Custom Hooks に集約
複数の Cusom Hooks を集約。 状態・更新ハンドラーの分配 <Provider customHooks={customHooks}> <SVG> <Hooks useContext={providerContext}>
<Element /> <Element /> </Hooks> <Hooks useContext={providerContext}> <Element /> </Hooks> <Element /> </SVG> <Hooks useContext={providerContext}> <Presentational /> </Hooks> </Provider> ※ DOM 構造概念図であり実コードではありません 複数の Custom Hooks を集約・分配 useSomething useSomething useSomething
Hooks を利用しなくても作れる(え)
React.FC<Animation> のアイデンティティ
React.FC<Animation> のアイデンティティ これらの実装は、あえて Hooks である必要はない。 従来の Statefull Component と 非同期
middleWare でも スタックとしては問題なく実現出来る。
React.FC<Animation> のアイデンティティ Hooks があるからといって Class Component が 廃止されるものではない、と明言されている。 現在、Dependencies に
Class Component を利用した ライブラリが含まれていても憂慮する必要はない。 (ただしこれからは Class Component を書く必要はない)
React.FC<Animation> のアイデンティティ 既存の Function Component に対し、 アニメーションを「ちょい足し」できる。 Redux を中心に量産した Function
Component に、 息を吹き込むことが出来る。
まとめ
▪ React Hooks で容易に実装ができる ▪ アプリケーションとの対話であることを意識 ▪ アプリケーション特性に基づいた設計を アニメーションのこれから
フロントエンドエンジニアは ユーザーにサービスを届ける最後の砦です。 自分たちにしかリーチ出来ない領域で アプリケーション価値を最大化させましょう!
ご静聴ありがとうございました