One place where I will break from FP is with UI components... And that's mainly because the syntax is easier, and with React you can use PureComponent, where as render components aren't considered pure by the framework and re-evaluated on every pass.
That's more of an issue with React, not FP... but context binding is easier with OO, where control flows, and state mgt are easier (imho) with FP.
I like this... A lot of other control flows make things more complicated to use, while this is just a building block that can be used on top of redux-thunk.
Very interesting... and pretty nice to see the work in supporting multiple storage engines... In particular the levelup/down implementations are interesting as there are interfaces supporting multiple backends.
It makes me curious what it would take to support a REALLY thin server-side solution for only what is needed by leveldown's API over a TLS connection, optionally with replication/consistency.
Not sure if this would just wind up being another etcd.
Interesting... I hadn't thought of running an application in dev via a mount point. With a base image that doesn't change much, this could be very useful.
No mention of reduce...
Object.keys(obj)
.map(k => foo(k, obj[k]))
.reduce((a, b) => Object.assign(a, b), {});
that's one of my favorites... break up an object/hash map, do something to each, and reconstruct hash map... assuming `foo(k, v)` returns `{ [k]: bar(v) }`;
map is cool and powerful, but so is reduce.
No mention of reduce... Object.keys(obj) .map(k => foo(k, obj[k])) .reduce((a, b) => Object.assign(a, b), {}); that's one of my favorites... break up an object/hash map, do something to each, and reconstruct hash map... assuming `foo(k, v)` returns `{ [k]: bar(v) }`; map is cool and powerful, but so is reduce.