Ramda - how to pass dynamic argument to function inside pipe - ramda.js

Question

I am trying to add/use a variable inside the pipe to get the name of an object from a different object. Here is what I got so far:
I have an array of IDs allOutgoingNodes which I am using in the pipe.
Then I filter results using tableItemId property and then I am adding additional property externalStartingPoint and after that I would like to add name of tableItem from tableItems object to content -> html using concat.
const startingPointId = 395;
const allNodes = {
"818": {
"id": "818",
"content": {
"html": "<p>1</p>"
},
"outgoingNodes": [
"819"
],
"tableItemId": 395
},
"821": {
"id": "821",
"content": {
"html": "<p>4</p>"
},
"tableItemId": 396
}
}
const tableItems = {
"395": {
"id": "395",
"name": "SP1",
"code": "SP1"
},
"396": {
"id": "396",
"name": "SP2",
"code": "SP2"
}
}
const allOutgoingNodes = R.pipe(
R.values,
R.pluck('outgoingNodes'),
R.flatten
)(tableItemNodes);
const result = R.pipe(
R.pick(allOutgoingNodes),
R.reject(R.propEq('tableItemId', startingPointId)),
R.map(
R.compose(
R.assoc('externalStartingPoint', true),
SomeMagicFunction(node.tableItemId),
R.over(
R.lensPath(['content', 'html']),
R.concat(R.__, '<!-- Table item name should display here -->')
)
)
),
)(allNodes);
Here is a complete working example: ramda editor
Any help and suggestions on how to improve this piece of code will be appreciated.
Thank you.

Answer 1

Update
In the comments, OriDrori noted a problem with my first version. I didn't really understand one of the requirements. This version tries to address that issue.
const {compose, chain, prop, values, lensPath,
pipe, pick, reject, propEq, map, assoc, over} = R
const getOutgoing = compose (chain (prop('outgoingNodes')), values)
const htmlLens = lensPath (['content', 'html'])
const addName = (tableItems) => ({tableItemId}) => (html) =>
html + ` <!-- ${tableItems [tableItemId] ?.name} -->`
const convert = (tableItemNodes, tableItems, startingPointId) => pipe (
pick (getOutgoing (tableItemNodes)),
reject (propEq ('tableItemId', startingPointId)),
map (assoc ('externalStartingPoint', true)),
map (chain (over (htmlLens), addName (tableItems)))
)
const startingPointId = 395;
const tableItemNodes = {818: {id: "818", content: {html: "<p>1</p>"}, outgoingNodes: ["819"], tableItemId: 395}, 819: {id: "819", content: {html: "<p>2</p>"}, outgoingNodes: ["820"], tableItemId: 395}};
const tableItems = {395: {id: "395", name: "SP1", code: "SP1"}, 396: {id: "396", name: "SP2", code: "SP2"}}
const allNodes = {818: {id: "818", content: {html: "<p>1</p>"}, outgoingNodes: ["819"], tableItemId: 395}, 819: {id: "819", content: {html: "<p>2</p>"}, outgoingNodes: ["820"], tableItemId: 395}, 820: {id: "820", content: {html: "<p>3</p>"}, outgoingNodes: ["821"], tableItemId: 396}, 821: {id: "821", content: {html: "<p>4</p>"}, tableItemId: 396}}
console .log (
convert (tableItemNodes, tableItems, startingPointId) (allNodes)
)
.as-console-wrapper {max-height: 100% !important; top: 0}
<script src="//cdnjs.cloudflare.com/ajax/libs/ramda/0.27.1/ramda.min.js"></script>
As well as most of the comments on the version below still applying, we should also note that chain, when applied to functions acts like this:
chain (f, g) (x) //~> f (g (x)) (x)
So chain (over (htmlLens), addName (tableItems))
ends up being something like
(node) => over (htmlLens) (addName (tableItems) (node)) (node)
which in Ramda is equivalent to
(node) => over (htmlLens, addName (tableItems) (node), node)
which we then map over the nodes coming to it. (You can also see this in the Ramda REPL.)
Original Answer
It's not trivial to weave extra arguments through a pipeline because pipelines are designed for the simple purpose of passing a single argument down the line, transforming it at every step. There are of course techniques we could figure out for that, but I would expect them not to be worth the effort. Because the only thing they gain us would be the ability to write our code point-free. And point-free should not be a goal on its own. Use it when it makes your code simpler and more readable; skip it when it doesn't.
Instead, I would break this apart with some helper functions, and then write a main function that took our arguments and passed them as necessary to helper functions inside our main pipeline. Expand this snippet to see one approach:
const {compose, chain, prop, values, lensPath, flip, concat,
pipe, pick, reject, propEq, map, assoc, over} = R
const getOutgoing = compose (chain (prop ('outgoingNodes')), values)
const htmlLens = lensPath (['content', 'html'])
const addName = flip (concat) ('Table item name goes here')
const convert = (tableItemNodes, startingPointId) => pipe (
pick (getOutgoing (tableItemNodes)),
reject (propEq ('tableItemId', startingPointId)),
map (assoc ('externalStartingPoint', true)),
map (over (htmlLens, addName))
)
const startingPointId = 395;
const tableItemNodes = {818: {id: "818", content: {html: "<p>1</p>"}, outgoingNodes: ["819"], tableItemId: 395}, 819: {id: "819", content: {html: "<p>2</p>"}, outgoingNodes: ["820"], tableItemId: 395}};
const allNodes = {818: {id: "818", content: {html: "<p>1</p>"}, outgoingNodes: ["819"], tableItemId: 395}, 819: {id: "819", content: {html: "<p>2</p>"}, outgoingNodes: ["820"], tableItemId: 395}, 820: {id: "820", content: {html: "<p>3</p>"}, outgoingNodes: ["821"], tableItemId: 396}, 821: {id: "821", content: {html: "<p>4</p>"}, tableItemId: 396}}
console .log (
convert (tableItemNodes, startingPointId) (allNodes)
)
.as-console-wrapper {max-height: 100% !important; top: 0}
<script src="//cdnjs.cloudflare.com/ajax/libs/ramda/0.27.1/ramda.min.js"></script>
(You can also see this on the Ramda REPL.)
Things to note
I find compose (chain (prop ('outgoingNodes')), values) to be slightly simpler than pipe (values, pluck('outgoingNodes'), flatten), but they work similarly.
I often separate out the lens definitions even if I'm only going to use them once to make the call site cleaner.
There is probably no good reason to use Ramda in addName. This would work just as well: const addName = (s) => s + 'Table item name goes here' and is cleaner. I just wanted to show flip as an alternative to using the placeholder.
There is an argument to be made for replacing
map (assoc ('externalStartingPoint', true)),
map (over (htmlLens, addName))
with
map (pipe (
assoc ('externalStartingPoint', true),
over (htmlLens, addName)
))
as was done in the original. The Functor composition law states that they have the same result. And that requires one fewer iterations through the data. But it adds some complexity to the code that I wouldn't bother with unless a performance test pointed to this as a problem.

Answer 2

Before I saw your answer I managed to do something like in the example below:
return R.pipe(
R.pick(allOutgoingNodes),
R.reject(R.propEq('tableItemId', startingPointId)),
R.map((node: Node) => {
const startingPointName = allTableItems[node.tableItemId].name;
return R.compose(
R.assoc('externalStartingPoint', true),
R.over(
R.lensPath(['content', 'html']),
R.concat(
R.__,
`<p class='test'>See node in ${startingPointName}</p>`
)
)
)(node);
}),
R.merge(newNodesObject)
)(allNodes);
What do you think?