Modify Key of the object by appending a field from Value into Key using Ramda

Question

I am trying to apply Ramda on the following problem:-

{
   "alpha": {
      "reg": "alpha1",
      "reg2": "alpha2"
   },
   "beta": {
      "reg": "beta1",
      "reg2": "beta2"  
   }
}

Output

{
   "v:alpha|reg:alpha1": {
      "reg": "alpha1",
      "reg2": "alpha2"
   },
   "v:beta|reg:beta1": {
      "reg": "beta1",
      "reg2": "beta2"  
   }
}

Basically, the output will be the object modifying the key by combining the key and a field from the value into the key and forming the new key.

For eg if the key="alpha", value is an object with key reg="alpha1". so the key should be modified to v:alpha|reg:alpha1 . v being unique string appending at the start of every key, and then appending reg:alpha1 to the key.

Thanks

Answer 1

I think what people are saying in the comments is mostly right. (Disclaimer: I'm one of the authors of Ramda.)

Let's imagine Ramda has a renameBy function:

const renameBy = curry((fn, obj) => pipe(
  toPairs,
  map(pair => [apply(fn, pair), pair[1]]),
  fromPairs
)(obj))

Ramda doesn't include this now, but there is a slightly less powerful version in Ramda's Cookbook . It's certainly conceivable that it will one day be included. But failing that, you could include such a function in your own codebase. (If we really tried, we could probably make that points-free, but as I'm trying to explain, that is probably unnecessary.)

How much does this gain you?

You could then write a transformation function like

const transform = renameBy((k, v) => `v:${k}|reg:${v.reg}`);

Granted, that is now simpler than the one in zerkms's comment

But the fundamentally complex bit of that version is retained here: the function that performs string interpolation on your key and value to yield a new key. Any attempt to make that points-free is likely to be substantially uglier than this version.

Perhaps this is worth it to you. It does separate concerns between the action of renaming keys and your particular key-generation scheme. And it reduces visual complexity... but only if you move that renameBy out of sight into some utilities library. If you're going to have multiple uses of renameBy , or if you simply prefer building up a more complete utility library in order to keep your other code more focused, then this might be a reasonable approach.

But it doesn't reduce the essential complexity of the code.

I do look to points-free solutions when it's reasonable. But they are just another tool in my toolbox. They are only worth it if they make the code more readable and maintainable. If they add complexity, I would suggest you don't bother.

You can see this version in the Ramda REPL .