Here are four functions I am trying to compose into a single endpoint string:
const endpoint = str => `${str}` || 'default'
const protocol = str => `https://${str}`
const params = str => `${str}?sort=desc&part=true&`
const query = str => `${str}query={ some:'value', another:'value'}`
let finalEndpoint = R.compose(query, params, protocol, endpoint)
var result = finalEndpoint('api.content.io')
This composition works and returns the result I want which is:
https://api.content.io?sort=desc&part=true&query={ some:'value', another:'value'}
But notice how I have hard coded the values for params
and query
inside their function body. I see only one value going up the value in this R.compose
chain.
How and where exactly do I pass in parameters to the params and query parameters?
UPDATE:
What I did was curried those functions like this:
var R = require('ramda');
const endpoint = str => `${str}` || 'default'
const protocol = str => `https://${str}`
const setParams = R.curry ( (str, params) => `${str}?${params}` )
const setQuery = R.curry ( (str, query) => `${str}&query=${JSON.stringify(query)}` )
and then
let finalEndpoint = R.compose(protocol, endpoint)
var result = setQuery(setParams(finalEndpoint('api.content.io'), 'sort=desc&part=true'), { some:'value', another:'value'})
console.log(result);
But the final call to get result
still seems pretty hacked and inelegant. Is there any way to improve this?
I wrote a little helper function for situations like this.
It is like compose, but with the rest params also passed in. The first param is the return value of the previous function. The rest params remain unchanged.
With it, you could rewrite your code as follows:
If you have params and query as curried functions then you can:
EDIT: code with all the bells and whistles, needed to change parameter order or use
R.__
and stringify objectHonestly, you don't, not when you're building a
compose
orpipe
pipeline with Ramda or similar libraries.Ramda (disclaimer: I'm one of the authors) allows the first function to receive multiple arguments -- some other libraries do, some don't -- but subsequent ones will only receive the result of the previous calls. There is one function in Sanctuary,
meld
, which might be helpful with this, but it does have a fairly complex API.However, I don't really understand why you are building this function in this manner in the first place. Are those intermediate functions actually reusable, or are you building them on spec? The reason I ask is that this seems a more sensible version of the same idea:
I don't really know your requirements for that last parameter. It looked strange to me without that
encodeUriComponent
, but perhaps you don't need it. And I also took liberties with the second parameter, assuming that you would prefer actual data in the API to a string encapsulating that data. But if you want to pass'sort=desc&part=true'
, then replacepipe(toPairs, map(join('=')), join('&'))
withidentity
.Since the whole thing is far from points-free, I did not use a points-free version of the first function, perhaps
or(__, 'default')
, as I think what's there is more readable.Update
You can see a version of this on the Ramda REPL, one that adds some
console.log
statements withtap
.This does raise an interesting question for Ramda. If those intermediate functions really are desirable, Ramda offers no way to combine them. Obviously Ramda could offer something like
meld
, but is there a middle ground? I'm wondering if there is a useful function (curried, of course) that we should include that works something likeThere are some serious objections: What if the lists are of different lengths? Why is the initial call unary, and should we fix that by adding a separate accumulator parameter to the function? Nonetheless, this is an intriguing function, and I will probably raise it for discussion on the Ramda boards.