vqvu
commented
8 years ago Sorry for the late reply. This is a tricky question to answer.
I think there are two questions here:
- Why is the Highland solution so much more complicated than the vanilla JS solution?
- Can we show that there is an advantage to modeling this problem in FRP?
I'll address (1) first. You should be careful about writing code that is too functional. Javascript isn't a functional language, and it's perfectly fine to combine some imperative code when working with Highland if it helps readability. Trying to force imperative code into a functional style, which is what happened here, can very easily hurt readability. Such code tend to have the property of being perfectly understandable to the writer when he or she is writing it, but extremely obtuse to everyone else.
FRP is more about transforming an asynchronous dataflow (i.e., streams of events or data objects) via functional programming constructs. calcGradient is neither asynchronous nor does it operate on a stream of data, so Highland is not a good fit for it. It's probably best implemented imperatively like in your coworker's solution.
Which brings us to (2). How can Highland help with the overall problem of outputing a gradient given a timestamp? For that we need to think about the entire dataflow end-to-end rather than just a simple time to gradient mapper.
In my opinion, the main benefit of Highland and similar libraries is the decoupling between a dataflow transform and the actual dataflow. In Highland, a transform does not have to worry about where its input data is coming from or what to do with the resulting data. That fact makes it easy to write and compose independent transforms together. To achieve the same thing in vanilla JS, you typically have to resort to callbacks everywhere.
To illustrate this, let's say you want to print a message every X milliseconds. You may end up doing something like this.
// Vanilla JS
function computeMessage(eventTime, now) {
const hours = toHours(now - eventTime);
const color = getRGBColor(hours);
return `${color} ${hours} hours until event`;
}
function execute(eventTime, ms) {
setInterval(() => {
console.log(computeMessage(eventTime, Date.now()));
}, ms);
}
execute(new Date('2017-01-01').getTime(), 1000 * 60);
// Highland
function timer(ms) {
_((push, next) => {
push(null, Date.now());
setTimeout(next, ms);
});
}
function computeMessage(eventTime) {
return now => {
const hours = toHours(now - eventTime);
const color = getRGBColor(hours);
return `${color} ${hours} hours until event`;
};
}
timer(1000 * 60)
.map(computeMessage(new Date('2017-01-01').getTime()))
.pipe(process.stdout);So far not much different. But now you want to write the message to both stdout and a database. In vanilla JS, you might add a call to write to the db in the setInterval handler. In Highland, a simple fork will do.
// Vanilla JS
function execute2(eventTime, ms) {
setInterval(() => {
const message = computeMessage(eventTime, Date.now());
console.log(message);
db.insert(message);
}, ms);
}
execute2(new Date('2017-01-01').getTime(), 1000 * 60);
// Highland
const s = timer(1000 * 60)
.map(computeMessage(new Date('2017-01-01').getTime()))
const fork1 = s.fork();
const fork2 = s.fork();
fork1.pipe(process.stdout);
fork2.each(message => db.insert(message));Now you really want to batch inserts to the database for performance, so you put in some simple batching logic. In Highland, it's just a call to batch.
// Vanilla JS
function execute3(eventTime, ms, n) {
const batch = [];
setInterval(() => {
const message = computeMessage(eventTime, Date.now());
console.log(message);
batch.push(message);
if (batch.length > n) {
db.insertAll(batch);
batch = [];
}
}, ms);
}
execute3(new Date('2017-01-01').getTime(), 1000 * 60, 100);
// Highland
...
fork2
.batch(100)
.each(messages => db.insertAll(message));Now it's getting more complicated. You have batching logic intertwined with scheduling logic intertwined with (hard-coded) output logic. That's not great. What if you want to be able to choose where to write to? In vanilla JS, you have to resort to using adhoc callbacks everywhere. In Highland, the transforms are already split up so you only have to change where you pipe.
// Vanilla JS
function execute4(eventTime, ms, callbacks) {
setInterval(() => {
const message = computeMessage(eventTime, Date.now());
callbacks.forEach(cb => cb(message));
}, ms);
}
function batch(n, cb) {
const batch = [];
return message => {
batch.push(message);
if (batch.length > n) {
cb(batch);
batch = [];
}
}
}
// Let's write to a file instead.
const fileStream = fs.createWriteStream('a file');
execute4(
new Date('2017-01-01').getTime(),
1000 * 60,
[
message => fileStream.write(message),
batch(100, messages => db.insertAll(messages))
]);
// Highland
...
fork1.pipe(fs.createWriteStream('a file'));
...Notice how the vanilla JS version is slowly evolving to look like the Highland version but more nested. Eventually you'll either reinvent a Highland-like framework or you'll end up with callback hell.
And this is just from your example. Here's another example that better illustrates the benefit of Highland. What if you want to scrape a bunch of webpages and write them to a database, but you don't want to DOS the server with too many requests at once.
In Highland, that's just
function getPage(url) {
// returns a promise with the body.
}
_(urls)
.map(url => _(getPage(url)))
.mergeWithLimit(5) // 5 requests in-flight at a time.
.each(body => db.insert(body));In vanilla JS, it's far more complicated since you need to reimplement the equivalent of mergeWithLimit. I won't write it out fully here, but I'm sure it's more than 4 lines.
jaidetree
o0x2a
So at work I've been trying to sell the rest of the tech team on FRP & libraries like Highland to make it easier to accomplish harder tasks.
I found the perfect problem: If an event date is set in the future, how can we gradate the color between set intervals until then? For example we may want a teal-ish color when there are 48 hours or more until the event. Or a mix between teal & yellow when between 48 hours and 6 hours, and a mix between red & yellow when the time is less than 6 hours from the event date which is red.
Fortunately I was able to get it done in highland but looking at a comparison against one a coworker wrote in vanilla ES6 js, it feels like mine is a lot more verbose & makes less sense. Would anyone here have modeled it differently or is it that my grasp of FRP concepts is severely lacking?
Coworker's solution:
My highland\FRP solution: