Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
カリー化はナンの役に立つのか
Search
fsubal
February 08, 2019
Programming
27
8.6k
カリー化はナンの役に立つのか
昔ニコナレにアップロードしていたピクシブ社内勉強会資料です。
fsubal
February 08, 2019
Tweet
Share
More Decks by fsubal
See All by fsubal
負債になりにくいCSSをデザイナとつくるには?
fsubal
10
2.9k
Webデザインと フロントエンド技術🔰勉強会
fsubal
2
260
Tailwind CSSを本気でカスタマイズする方法
fsubal
17
7.2k
デザインシステムで Tailwind CSSとCSS in JSに分散投資をしたら良かった話
fsubal
20
6.7k
『Tailwind CSS実践入門』 出版記念基調講演
fsubal
8
5.2k
Sprockets CSSもやめる なぜ / Why stop using Sprockets for CSS too
fsubal
3
1.6k
The Majestic MPA
fsubal
8
3.2k
Backbone.Model に 型をつけて剥がす - Typing to destroy Backbone.Model
fsubal
1
1k
SVG + React でつくる レイヤーの自由変形 / Layer Transformation with React + SVG
fsubal
1
9.2k
Other Decks in Programming
See All in Programming
Cursor/Devin全社導入の理想と現実
saitoryc
25
18k
MCP調べてみました! / Exploring MCP
uhzz
2
2.3k
Memory API : Patterns, Performance et Cas d'Utilisation
josepaumard
1
150
サービスクラスのありがたみを発見したときの思い出 #phpcon_odawara
77web
4
690
設計の本質:コード、システム、そして組織へ / The Essence of Design: To Code, Systems, and Organizations
nrslib
9
3.2k
Empowering Developers with HTML-Aware ERB Tooling @ RubyKaigi 2025, Matsuyama, Ehime
marcoroth
2
810
Golangci-lint v2爆誕: 君たちはどうすべきか
logica0419
1
180
Fiber Scheduler vs. General-Purpose Parallel Client
hayaokimura
1
170
Bedrock×MCPで社内ブログ執筆文化を育てたい!
har1101
6
1.2k
Exit 8 for SwiftUI
ojun9
0
140
note の Elasticsearch 更新系を支える技術
tchov
0
160
Jakarta EE Meets AI
ivargrimstad
0
340
Featured
See All Featured
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
23
2.7k
Visualization
eitanlees
146
16k
Optimizing for Happiness
mojombo
377
70k
Rebuilding a faster, lazier Slack
samanthasiow
81
8.9k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
227
22k
Build The Right Thing And Hit Your Dates
maggiecrowley
35
2.7k
Automating Front-end Workflow
addyosmani
1370
200k
[RailsConf 2023] Rails as a piece of cake
palkan
54
5.4k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Building Applications with DynamoDB
mza
94
6.3k
How STYLIGHT went responsive
nonsquared
100
5.5k
Transcript
カリー化は ナンの役に立つのか Web フロントエンド 編 pixiv Inc. f_subal 2018/12/07
2 誰 • pixivFACTORY フロントエンド • React と Redux と
SVG • 将来の夢は Single SVG Application です @f_subal
みなさん カリー化してますか 3
私は React + TS で 息をするように使ってます 4
「りろんはしってる」けど 5
「どう嬉しいのかわからない」 と言われがち 6
• カリー化を用いるとこんなことができる ◦ 読みやすい高階関数の building block をつくる ◦ 関数で DI
する ◦ 時間とともに変化する関数をつくる 7 話すこと
カリー化 (currying) 8
• n 引数関数を、n 回適用可能な 1 引数の連なりに変形すること • 例 ◦ (a:
number, b: number) => Math.max(a, b) が ◦ (a: number) => (b: number) => Math.max(a, b) になる ◦ a を渡すと、「b を渡すと number が返る関数」が返る 9 カリー化とは
// before function getMax(a: number, b: number) { return Math.max(a,
b) } // after (curried) function getMax(a: number) { return function (b: number) { return Math.max(a, b) } } 11
へー (何が嬉しいのかわからん) 11
たとえば .filter と合わせる 12
例題) number[] から 3 より 大きい要素だけを抽出せよ 13
// before function isLarger(a: number, b: number) { return a
> b } // with before const largerThanThrees = inputs.filter(function (n) { return isLarger(n, 3) }) 11
これでも悪くないが 15
// after (curried) function isLarger(a: number) { return function (b:
number) { return a < b } } // with after const largerThanThrees = inputs.filter(isLarger(3)) 11
// after (curried) function isLargerThan(a: number) { return function (b:
number) { return a < b } } // with after const largerThanThrees = inputs.filter(isLargerThan(3)) 11
// after (curried) function isLargerThan(a: number) { return function (b:
number) { return a < b } } // with after const largerThanThrees = inputs.filter(isLargerThan(3)) 11
いいじゃん 19
• .map .filter など、JS は高階関数 API を多用する • すると、高階関数にビジネスロジックとして意味のあるパターンが現れる ◦
.filter(isPremiumUser) とか ◦ .filter(isOwnedBy(user)) とか • こういう関数を切り出す際、カリー化しておくと便利 ◦ .map や .filter にドメインロジックが表現される ◦ 厳密に 1 引数ずつにしなくても「関数をかえす関数」にするだけでも便利 20 高階関数 の building block
• 多言語出身の人は .filter(isPremiumUser) より .selectPremiumUser() と書きたがる • A. 諦めろ ◦
経験上、クラスインスタンスにマッピングするメリットが、デメリットを上回ることはほぼ ない ◦ フロントエンドの殆どは「ユーザー入力を JSON に相互変換する処理」に過ぎない( 燃える発言 ) ◦ プレーンな関数に表現力を与える方向で議論したほうが有益( TypeScript はそれが 得意 ) 21 Q. オブジェクト指向すれば?
22
23
部分適用 (partial application) 24
• 関数の引数の一部だけ、予めある値を束縛しておくこと ◦ 例: (a, b) => a + b
があるとき、b=1 を部分適用すると increment 関数になる • カリー化された関数に対し、予め 1回(あるいは数回)呼んでおくことでも実現できる ◦ f が a => b => a + b のとき、f(1) すると b => b + 1 になる ◦ isOwnedBy(user) に currentUser を適用すると isMine(item) が作れる • カリー化と部分適用はよく混同される( 別の概念です ) 25 部分適用とは
部分適用したものを使いまわす 26
たとえば単位換算 27
例題 1) 100mm の直線が 1181px で表示されてる (≒ 300dpi) この時カーソルを 30px
動かすと、 何 mm 動いたことになる? 28
29
とりあえず カリー化無しで 書いてみる 30
// without currying // 1 inch === 25.4 mm function
px2mm(px: number, dpi: number) { return px / dpi * 25.4 } const dpi = 1181 / 100 * 25.4 const mm = px2mm(30, dpi) 11
これでもいい、が… 32
例題 2) 実はいま 1181 px で 表示されてるのはたまたまで、 100mm の原稿が window
の resize のたびに いろんな大きさ (px) になると仮定してください 33
例題 2) 実はいま 1181 px で 表示されてるのはたまたまで、 100mm の原稿が window
の resize のたびに いろんな大きさ (px) になると仮定してください 34
11
• (px, dpi) => mm という関数のうち、dpi が変わる場合がある ◦ dpi は「この
mm がこの px で表示されている」という事実から決定される • dpi は window をリサイズしない限り変わらない • 普通に扱う場合は、dpi を固定した状態で、px → mm 換算が行えると嬉しい 36 つまり…
• (px, dpi) => mm という関数を dpi => px =>
mm という形式で表すとどうなるか ◦ makePx2Mm に dpi を部分適用すると px2mm ができる • window.resize のたびに makePx2Mm(dpi) を実行すると… ◦ 「dpi をある値で固定したときの px → mm 換算関数」ができる!! 37 そこで部分適用ですよ
カリー化して解いてみる 38
// curried! // 1 inch === 25.4 mm function makePx2mm(dpi:
number) { return function (px: number) { return px / dpi * 25.4 } } 11
// in React Component class public componentDidMount() { document.addEventListener('resize', ()
=> { this.setState({ currentDpi: ... }) }) } get px2mm() { return makePx2mm(this.state.currentDpi) } 11
// with Hooks (>= v16.8.0) const [width, height] = useWindowSize()
const currentDpi = calcDpi(...) const px2mm = makePx2mm(currentDpi) 11
お分かりいただけただろうか 42
• ある時点において px ➔ mm はこういう式だが、別の時点では違う式になる • 外部要因( ここでは dpi
)を注入して関数を組み立てるような設計にしたい ◦ dpi は更に window size に依存する 43 時間経過によって変動する式
• 時間経過によって変化する対象( UI )をクラス / 関数で表す • そこに内部状態( React の
state )を閉じ込める • カリー化された関数に、内部状態を適用して式を組み立てる • あとはそれを子に引き回す( React なら Context API と合わせても良い ) ◦ 子は単に this.props.px2mm() すればよい(親の dpi は知らなくて良い) • 時間経過によって変わる関数式を使い回せて便利 44 Stateful な対象と合わせる
ところで 45
• その通り ◦ メソッドが1個しかないクラスに対する DI みたいなものだと思って • むしろ自分は DI をクラスで部分適用するものと見ている
◦ new Service(arg).call(hoge) はカリー化の OOP 的解釈 ◦ 関数だと呼出が 2 段以上続くケースも作りやすい ( service(arg)(hoge)(...) ) 46 これって DI みたいなもの?
• Q. 高階関数はともかくさ〜、if 文が ↓ みたいになるのイケてなくない? ◦ if ( isOwnedBy(user)(item)
) { • A. まぁそうですね ( uncurry しなければ ) • いま ECMAScript に提案中の pipeline 演算子がきたら ↓ みたいに書けるので辛抱してく ださい ◦ if ( item |> isOwnedBy(user) ) { 47 余談: Pipeline Operator
• カリー化を用いるとこんなことができる ◦ 読みやすい高階関数の building block をつくる ◦ 関数で DI
する ◦ 時間とともに変化する関数をつくる 48 まとめ