1.什么是位置参数?
JavaScript:为什么命名参数比位置参数更好
你一定很熟悉位置参数,即使你第一次听到这个名字。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
function greet(firstName, lastName) { console.log(`Hello ${firstName} ${lastName}`); } // 预期用法 greet( 'Michael' , 'Scott' ); const fName = 'Harry' ; const lName = 'Potter' ; greet(fName, lName); // 错误用法 const firstName = 'Erlich' ; const lastName = 'Bachman' ; greet(lastName, firstName); |
greet函数接受两个参数:firstName和lastName。调用者必须确保firstName是第一个参数,lastName是第二个参数。这里重要的一点是,参数的名称没有任何意义,唯一重要的是参数传递的顺序。
这种熟悉的方法称为位置参数。通常,在你传递一个或两个参数的情况下,这很好,因为它很难弄乱参数的顺序。但是如果你必须调用一个需要6个参数的函数,那就很难记住传递参数的顺序。你不希望传递密码来代替用户名参数。
2. 位置参数问题
位置参数很简单,但是你将面临一些挑战。
(1) 不能跳过中间参数 /
假设你已经更改了greet函数,使其现在需要3个参数:firstName、middleName和lastName。由于许多人没有中间名,因此你希望将MiddleName设为可选参数,仅使用firstName和lastName调用greet函数的唯一方法是此方法。
1
2
3
4
|
greet( 'Aditya' , null , 'Agarwal' ); // Correct greet( 'Aditya' , 'Agarwal' ); // Incorrect |
你不能只提供firstName和lastName。当可选参数的数量增加到5个时,这个问题变得更加明显。现在,你必须提供5个null才能在这些参数之后提供参数。
(2) 将类型添加到位置参数不那么干净
如今,为你的实用程序添加类型变得非常普遍。使用位置参数,你别无选择,只能将类型与函数定义一起内联。这可能会使代码有点模糊,如果我们可以在一个块中声明所有参数的类型定义,那就更好了。
(3) 引起细微的错误
位置参数包装了很多隐性行为,这可能是造成微妙bug的原因。我们来看一个常见的JS技巧问题
const numbers = ['1', '4', '8', '10'];
console.log(numbers.map(parseInt));// 你可能会认为结果将是:
[1, 4, 8, 10]// 这是实际的输出:
[ 1, NaN, NaN, 3 ]
惊讶吗?这种奇怪的输出的原因隐藏在位置参数的隐性背后。你会看到map和parseInt函数在显而易见的情况下隐藏了它们的一些秘密。
让我们再次查看代码 number.map(parseInt)。
这里到底发生了什么?
- 我们在numbers数组上运行map函数。
- map获取数组的第一项并将其传递给parseInt。
- 现在,对于数组中的第一项(即1),它将执行 parseInt(1)。对...?错误!!!
实际上,map将三个参数传递给其回调函数。第一个是数组中的当前项目,第二个是项目的索引,第三个是整个数组。这本身没有问题,但真正的问题在于后一部分。
numbers.map(parseInt) 与 numbers.map((item) => parseInt(item)) 不同。你可以假设,由于回调函数仅接受item参数并将其传递给parseInt,因此我们可以跳过附加步骤。但是两者是不同的:在前者中,我们将所有数据从map传递到parseInt,而在后者中,我们仅传递项。
你可能不知道,但是parseInt的第二个参数称为基数。默认情况下,基数的值为10(以10为底,因为人类遵循十进制进行计数)。该代码出了问题,就是我们将当前项目的索引作为基数值传递给parseInt。这些是发生的实际函数调用:
parseInt('1', 0, [...]);
parseInt('4', 1, [...]);
parseInt('8', 2, [...]);
parseInt('10', 3, [...]);
现在我们知道了问题,我们如何才能做得更好?
3. 位置参数的替代
如果一个函数可以通过名字就知道它期望的参数是什么呢?这样即使你误传了额外的数据给它,它也只会使用它需要的东西。
让我们对parseInt进行包装。下面是一个简单的实现。
1
2
3
4
5
6
7
|
// 实现 function myCustomParseInt(objArgs) { return parseInt(objArgs.item, objArgs.radix); } // 使用 const num = myCustomParseInt({ item: '100' , radix: 10 }); |
myCustomParseInt仅接受一个参数,它是一个对象。这个对象可以有两个键:item 和 radix。让我们使用我们的自定义函数与map。必须有一个中间步骤,将回调收到的args发送到myCustomParseInt。
const numbers = ['1', '4', '8', '10'];
const result = numbers.map((item, index) => myCustomParseInt({ item, index }));
console.log(result); // [ 1, 4, 8, 10 ]
请注意,即使我们将索引传递给myCustomParseInt也不会造成任何问题。那是因为myCustomParseInt只会忽略它。将对象传递给函数的这种模式称为命名参数,它比位置参数更明确。
要更改基数,我们必须显式传递基数键。这意味着如果要解析以2为底的字符串,则必须转到文档并查看参数(基数)的确切名称。如果我们盲目地传递任何其他键,它将无济于事。这对我们来说很棒,因为它避免了意外行为。
(1) 具有解构的命名参数
不久前,JavaScript获得了称为解构的功能,让我们在myCustomParseInt实现中使用它。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
// 位置参数 function myCustomParseInt(item, radix) { return parseInt(item, radix); } // 命名参数旧的实现 function myCustomParseInt(objArgs) { return parseInt(objArgs.item, objArgs.radix); } // 命名参数解构 function myCustomParseInt({ item, radix }) { return parseInt(item, radix); } |
你会注意到,只需添加两个花括号,我们就可以得到命名args的好处,你可以将解构视为执行 const item = objArgs.item;。
如果使用 undefined 调用myCustomParseInt,则JS将引发错误。那是因为不允许 undefined.item。为了避免这种情况,我们可以在解构结束时添加 = {}。这样,当我们传递undefined时,它将执行 {}.item 这是有效的JS。这是最终的实现:
1
2
3
|
function myCustomParseInt({ item, radix } = {}) { return parseInt(item, radix); } |
通过命名参数模式,我们也可以跳过我们不想提供的参数,因为函数不再依赖于传递参数的顺序。
// 对于位置参数,我们必须在之间添加一个null
function greetPos(firstName, middleName, lastName) {}
greetPos('Aditya', null, 'Agarwal');// 使用命名参数,你只需提供firstName和lastName。
function greetNamed({ firstName, middleName, lastName } = {}) {}
greetNamed({ firstName: 'Aditya', lastName 'Agarwal' });
总而言之,我要说的是命名参数是一种强大的模式,如今它已变得非常普遍,但是你不必总是使用它们。有时你甚至可以将两者结合在一起。浏览器中的fetch API的用法如下:
1
2
3
4
5
6
7
8
9
10
|
// 以url作为位置参数的请求,以及以args做命名参数的选项。 fetch( 'https://google.com' , { method: 'POST' , headers: { 'Content-Type' : 'application/json' , }, }); // basic GET requests with just positional args fetch( 'https://google.com' ); |
这里的强制参数(API路径)是一个位置参数,然后通过命名参数接受可选的参数。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持服务器之家。
原文链接:https://blog.51cto.com/14887308/2523152