Transform array of records to summary or pivot using ramdajs - ramda.js

Question

[
{
"door_id": 324,
"action": "door open",
"timestamp": "2018-03-30 10:34:44",
"date": "2018-03-30"
},
{
"door_id": 324,
"action": "door close",
"timestamp": "2018-03-30 10:39:44",
"date": "2018-03-30"
},
{
"door_id": 324,
"action": "door open",
"timestamp": "2018-03-30 10:59:44",
"date": "2018-03-30"
},
{
"door_id": 325,
"action": "door open",
"timestamp": "2018-03-31 14:59:44",
"date": "2018-03-31"
},
{
"door_id": 325,
"action": "door close",
"timestamp": "2018-03-31 15:00:44",
"date": "2018-03-31"
}
]
I'm trying to transform this array of objects into the expected format using ramda.js.
The open and close actions will always comes in sequence but not necessarily make a complete set (e.g. there's a log for door opening, but no log for door closing because the door is open)
I prefer more like step-by-step using mapper approach/partial function.
const expected = [
{
"door_id": 324,
"date": "2018-03-30",
"status" : "Open",
"actions_set_count": 2,
"actions": [
{
"open": "2018-03-30 10:34:44",
"close": "2018-03-30 10:39:44",
"duration": 300
},
{
"open": "2018-03-30 10:59:44",
"close": null,
"duration": null
}
]
},
{
"door_id": 325,
"date": "2018-03-31",
"status" : "Closed",
"actions_set_count": 1,
"actions": [
{
"open": "2018-03-30 14:59:44",
"close": "2018-03-30 15:00:44",
"duration": 60
}
]
}
]
What have i done so far but it far from complete
const isOpen = R.propEq('action','door open')
const isClosed = R.propEq('action','door close')
R.pipe(
R.groupBy(R.prop('date')),
R.map(R.applySpec({
"date": R.pipe(R.head(), R.prop('date')),
"door_id": R.pipe(R.head(), R.prop('door_id')),
"open" : R.filter(isOpen),
"close" : R.filter(isClosed),
"sets": R.zip(R.filter(isOpen),R.filter(isClosed))
})),
)(logs)

Answer 1

In a transformation like this, when I can't think of something elegant, I fall back on reduce. Using groupBy (and if necessary, sortBy) and values we can put the data together in an order that allows us to do then do a straightforward -- if a bit tedious -- reduction on it.
const duration = (earlier, later) =>
(new Date(later) - new Date(earlier)) / 1000
const transform = pipe(
groupBy(prop('door_id')),
map(sortBy(prop('timestamp'))), // Perhaps unnecessary, if data is already sorted
values,
map(reduce((
{actions, actions_set_count},
{door_id, action, timestamp, date}
) => ({
door_id,
date,
...(action == "door open"
? {
status: 'Open',
actions_set_count: actions_set_count + 1,
actions: actions.concat({
open: timestamp,
close: null,
duration: null
})
}
: {
status: 'Closed',
actions_set_count,
actions: [
...init(actions),
{
...last(actions),
close: timestamp,
duration: duration(last(actions).open, timestamp)
}
]
}
)
}), {actions: [], actions_set_count: 0}))
)
const doors = [
{door_id: 324, action: "door open", timestamp: "2018-03-30 10:34:44", date: "2018-03-30"},
{door_id: 324, action: "door close", timestamp: "2018-03-30 10:39:44", date: "2018-03-30"},
{door_id: 324, action: "door open", timestamp: "2018-03-30 10:59:44", date: "2018-03-30"},
{door_id: 325, action: "door open", timestamp: "2018-03-31 14:59:44", date: "2018-03-31"},
{door_id: 325, action: "door close", timestamp: "2018-03-31 15:00:44", date: "2018-03-31"}
]
console.log(transform(doors))
<script src="https://bundle.run/ramda#0.26.1"></script><script>
const {pipe, groupBy, prop, map, sortBy, values, reduce, init, last} = ramda </script>
There are other ways we could approach this. My first thought was to use splitEvery(2) to get these in open-close pairs, and then generate the actions. The trouble is that we would still need the actual original data to fill in the rest (door_id, date, etc.) So I ended up with reduce.
Obviously this is far from elegant. Part of that is that the underlying transformation is not particularly elegant (why the actions_set_count field, which is just the length of actions?), nor is the data (why have the date and timestamp fields?) But I suspect that I've also missed things which would make for a nicer implementation. I'd love to hear what those are.
Note that I chose to use the final date field rather than the initial one. Sometimes that's easier to do in a reduce call, and it sounds as though that's not important yet.