我在 Angular 示例中遇到了这个构造,我想知道为什么选择它:
_ => console.log('Not using any parameters');
我知道变量
_
意味着不关心/不使用,但由于它是唯一的变量,是否有任何理由更喜欢使用_
而不是:
() => console.log('Not using any parameters');
这肯定不能少输入一个字符。在我看来,
()
语法更好地传达了意图,并且也更特定于类型,因为否则我认为第一个示例应该如下所示:
(_: any) => console.log('Not using any parameters');
如果重要的话,这是使用它的上下文:
submit(query: string): void {
this.router.navigate(['search'], { queryParams: { query: query } })
.then(_ => this.search());
}
可以使用这种样式的原因(也可能是这里使用它的原因)是
_
比()
短一个字符。
可选括号与可选大括号属于相同的样式问题。这在很大程度上是品味和代码风格的问题,但由于一致性,这里更倾向于冗长。
虽然箭头函数允许单个参数不带括号,但它与零、单个解构、单个休息和多个参数不一致:
let zeroParamFn = () => { ... };
let oneParamFn = param1 => { ... };
let oneParamDestructuredArrFn = ([param1]) => { ... };
let oneParamDestructuredObjFn = ({ param1 }) => { ... };
let twoParamsFn = (param1, param2) => { ... };
let restParamsFn = (...params) => { ... };
尽管 TypeScript 2.0
中修复了下划线参数的
is declared but never used
错误 ,但 _
也可以从 linter 或 IDE 触发 unused variable/parameter
警告。这是反对这样做的一个相当大的论据。
_
通常可用于忽略的参数(正如其他答案已经解释的那样)。虽然这可能被认为是可以接受的,但这种习惯可能会导致与 _
Underscore/Lodash 命名空间发生冲突,当存在多个被忽略的参数时也会看起来令人困惑。因此,正确命名带下划线的参数(在 TS 2.0 中受支持)是有益的,还可以节省弄清楚函数签名以及为什么参数被标记为忽略的时间(这违背了 _
参数作为快捷方式的目的):
let fn = (param1, _unusedParam2, param3) => { ... };
出于上面列出的原因,我个人认为
_ => { ... }
代码风格是一种应该避免的坏语气。
恕我直言,
语法更好地传达了意图,并且也更特定于类型()
不完全是。
()
表示该函数不需要任何参数,它不声明任何参数。该函数的 .length
为 0。
如果您使用
_
,它会明确指出该函数将传递一个参数,但您不关心它。该函数的 .length
将为 1,这在某些框架中可能很重要。
因此,从类型的角度来看,这可能是更准确的事情(特别是当您不使用
any
而是使用 _: Event
来键入时)。正如您所说,输入少了一个字符,在某些键盘上也更容易输入。
我猜
_ =>
只是用在() =>
之上,因为_
在其他语言中很常见,不允许像JS那样省略参数。
_
在 Go 中很流行,在 Dart 中也使用它来指示参数被忽略,可能还有其他我不知道的参数。
可以区分这两种用法,一些框架使用它来表示不同类型的回调。例如,我认为节点表达框架使用它来区分中间件的类型,例如错误处理程序使用三个参数,而路由使用两个参数。
这种区分可以如下例所示:
const f1 = () => { } // A function taking no arguments
const f2 = _ => { } // A function with one argument that doesn't use it
function h(ff) {
if (ff.length === 0) {
console.log("No argument function - calling directly");
ff();
} else if (ff.length === 1) {
console.log("Single argument function - calling with 1");
ff(1);
}
}
h(f1);
h(f2);
这是基于 Bergi 的答案,但我认为添加示例比我乐意对其他人的帖子进行的编辑要多一些。