拉姆达或不拉姆达

Question

在我们的团队中，我们试图决定是否应该在我们的项目中使用ramda。这个项目是在Typesctipt上，反应在前面，Nestjs在后面。

目前，正反两方面的清单如下

Pros:

1. 代码容易读懂。
2. 纯函数易于测试和重构。

Cons:

1. 如果你是兰达的新手，很难读懂。
2. Ramda在类型上有问题。

interface Obj {p1: {p2: number}}

const obj: Obj = {
    p1: {
        p2: 1,
    }
}

const value = pathOr(null, ['p1', 'p2'], obj); //type of "value" will be "any"

1. 在类中使用ramda看起来很尴尬。

class Cl {
  method1() {...}

  method2() {...}

  method3() {
    return compose(
      this.method1.bind(this),
      this.method2.bind(this),
    )()
  }
}

会很高兴看到对这些方面的任何考虑，或更多的利弊补充。谢谢。

更新：

考虑到geoffrey的评论，当不可能不使用类(如NestJS中的类)时，最好将fp风格的函数从类方法中分离出来，因为它们是纯函数：

const method1Fn = () => {...};
const method2Fn = () => {...};
const method3Fn = () => compose(
  method1Fn,
  method2Fn,
)

class Cl {
  method3() {
    return method3Fn()
  }
}

甚至是

class Cl {
  method3 = method3Fn
}

但在本例中，将为每个method3实例创建Cl。

Answer 1

在这种情况下，可读性是一个使用问题。只要你把Ramda的用法保持在易于阅读的地方，就不会有问题。

来自此回答的示例

这是非常可读的：

const siblings = me => reject(equals(me), family(me));

虽然这会过度使用Ramda，但它的可读性较低(可能需要手动类型)：

const siblings = converge(reject, [unary(equals), family])

Ramda在类型上有问题。

尽管您可以安装@types/ramda，但推断是部分的。您可能会发现自己手动添加类型：

interface Obj {
  p1: { p2: number };
}

const obj: Obj = {
  p1: {
    p2: 1
  }
};

const fn: (obj: Obj) => null | number = pathOr(null, ['p1', 'p2']);

const value = fn(obj);

console.log(value);

在类中使用ramda看起来很尴尬。

您可以使用类属性与箭头函数绑定方法，因此这实际上不是一个问题：

class Cl {
  method1 = () => {...}

  method2 = () => {...}

  method3() {
    return compose(
      this.method1,
      this.method2,
    )()
  }
}

Answer 2

当代码库增长时，将有大量的Ramda，当新开发人员来到这个项目时，他会感到害怕，需要花更多的时间来学习Ramda，这是不可能的。