TL;DR: If you want to see me perform a spoken word poem about JavaScript in front of 1000 people (and on video), please ⭐ star this gist. If you're on mobile, you'll need to request desktop site.
# one or the other, NOT both | |
[url "https://github"] | |
insteadOf = git://github | |
# or | |
[url "git@github.com:"] | |
insteadOf = git://github |
Redux has brought the notion of reducer back into the awareness of many developers for whom they are a novel concept. In fact they are quite simple, and used all the time in such things as SUM
aggregations in databases, where they compute a single value from many.
It's great that Redux has made reducers known to a broader audience, though they are relatively ancient concepts in programming, in fact. But the particular way Redux illustrates a reducer in its documentaion is, in my opinion, with a coding style that is harder to extend and read than it should be. Let's distill reducers down to their essensce, and build up Redux reducers in a way that lowers complexity, and helps separate Redux idioms from your business logic.
A reducer is a pure function that accepts more arguments than it returns. That is to say - one whose "arity" is greater than 1. It 'reduces' the two things you pass it down to a single value. Here are two reducers, in a map
const I = x => x | |
const K = x => y => x | |
const A = f => x => f (x) | |
const T = x => f => f (x) | |
const W = f => x => f (x) (x) | |
const C = f => y => x => f (x) (y) | |
const B = f => g => x => f (g (x)) | |
const S = f => g => x => f (x) (g (x)) | |
const S_ = f => g => x => f (g (x)) (x) | |
const S2 = f => g => h => x => f (g (x)) (h (x)) |