大家好！前段时间，在浏览最新的 TC39 提案时，我偶然发现了一个让我兴奋但又有点怀疑的提案。这是关于 JavaScript 的部分应用程序语法。乍一看，这似乎是解决许多常见编码问题的完美方法，但当我仔细考虑时，我意识到它既有很多值得喜欢的地方，也有一些改进的空间。
更好的是，这些担忧引发了一个全新的想法，可以使 JavaScript 变得更加强大。让我带您踏上这段旅程，并通过现实的例子来说明这些功能如何改变我们每天的编码方式。
TLDR：这篇文章来自我对提案的旧问题：https://github.com/tc39/proposal-partial-application/issues/53
部分应用程序允许您“预设”函数的一些参数，返回一个新函数以供以后使用。我们当前的代码如下所示：
const fetchWithAuth = (path: string) => fetch(
{ headers: { Authorization: "Bearer token" } },
path,
);
fetchWithAuth("/users");
fetchWithAuth("/posts");
该提案为此引入了 ~() 语法：
const fetchWithAuth = fetch~({ headers: { Authorization: "Bearer token" } }, ?);
fetchWithAuth("/users");
fetchWithAuth("/posts");
看看发生了什么？ fetchWithAuth 函数预先填充 headers 参数，因此您只需提供 URL。它类似于 .bind() 但更灵活且更易于阅读。
该提案还允许您使用 ?作为未填充参数的占位符和...作为剩余参数。例如：
const sendEmail = send~(user.email, ?, ...);
sendEmail("Welcome!", "Hello and thanks for signing up!");
sendEmail("Reminder", "Don't forget to confirm your email.");
我最喜欢的部分是我不需要重复类型注释！
听起来很有用，对吧？但还有很多东西需要解开。
让我们从一个实际的痛点开始：函数闭包和过时的变量引用。
假设您正在安排一些通知。你可能会写这样的内容：
function notify(state: { data?: Data }) {
if (state.data) {
setTimeout(() => alert(state.data), 1000)
}
}
你已经看到问题了吗？ “数据”属性可能会在超时期间发生变化，并且警报将不显示任何内容！修复此问题需要显式传递值引用，希望“setTimeout”接受其他参数以将其传递到回调中：
function notify(state: { data?: Data }) {
if (state.data) {
setTimeout((data) => alert(data), 1000, state.data)
}
}
还不错，但 API 并未广泛支持。部分应用可以使这种模式更加普遍：
function notify(state: { data?: Data }) {
if (state.data) {
setTimeout(alert~(state.data), 1000)
}
}
通过在函数创建时锁定 state.data，我们可以避免由于过时的引用而出现意外错误。
部分应用程序的另一个实际好处是消除处理大型数据集时的冗余工作。
例如，你有一个映射逻辑，它需要为每个迭代步骤计算额外的数据：
const fetchWithAuth = (path: string) => fetch(
{ headers: { Authorization: "Bearer token" } },
path,
);
fetchWithAuth("/users");
fetchWithAuth("/posts");
问题在于代理访问 this.some.another，调用每个迭代步骤非常繁重。最好像这样重构这段代码：
const fetchWithAuth = fetch~({ headers: { Authorization: "Bearer token" } }, ?);
fetchWithAuth("/users");
fetchWithAuth("/posts");
通过部分应用，我们可以做得更简洁：
const sendEmail = send~(user.email, ?, ...);
sendEmail("Welcome!", "Hello and thanks for signing up!");
sendEmail("Reminder", "Don't forget to confirm your email.");
通过烘焙共享计算，您可以使代码更加简洁且更易于遵循，而不会牺牲性能。
现在，这就是我开始挠头的地方。虽然提议的语法很优雅，但 JavaScript 已经有很多运算符。特别是问号运算符？。添加 ~() 可能会使语言更难学习和解析。
如果我们可以在不引入新语法的情况下实现相同的功能怎么办？
想象一下使用 tie 方法扩展 Function.prototype：
function notify(state: { data?: Data }) {
if (state.data) {
setTimeout(() => alert(state.data), 1000)
}
}
它有点冗长，但避免引入全新的运算符。使用额外的特殊符号作为占位符，我们可以替换问号。
function notify(state: { data?: Data }) {
if (state.data) {
setTimeout((data) => alert(data), 1000, state.data)
}
}
它是完美的多重堆积，没有额外的构建时间复杂性！
function notify(state: { data?: Data }) {
if (state.data) {
setTimeout(alert~(state.data), 1000)
}
}
但这只是冰山一角。它使得占位符概念可以在不同的 API 之间重用。
这就是事情变得非常有趣的地方。如果我们扩展符号概念以启用惰性操作会怎么样？
假设您正在处理电子商务网站的产品列表。您只想显示打折商品，并对其价格进行四舍五入。通常，你会这样写：
class Store {
data: { list: [], some: { another: 42 } }
get computedList() {
return this.list.map((el) => computeElement(el, this.some.another))
}
contructor() {
makeAutoObservable(this)
}
}
但这需要迭代数组两次。通过惰性操作，我们可以将这两个步骤合并为一次：
class Store {
data: { list: [], some: { another: 42 } }
get computedList() {
const { another } = this.some
return this.list.map((el) => computeElement(el, another))
}
contructor() {
makeAutoObservable(this)
}
}
Symbol.skip 告诉引擎从最终数组中排除项目，使操作既高效又富有表现力！
想象一下计算前五次销售的总收入。通常，您会在 .reduce() 中使用条件：
class Store {
data: { list: [], some: { another: 42 } }
get computedList() {
return this.list.map(computeElement~(?, this.some.another))
}
contructor() {
makeAutoObservable(this)
}
}
这可行，但它仍然处理数组中的每个项目。通过惰性减少，我们可以发出提前终止的信号：
function notify(state: { data?: Data }) {
if (state.data) {
setTimeout(alert.tie(state.data), 1000)
}
}
Symbol.skip 的存在可以告诉引擎一旦满足条件就停止迭代，从而节省宝贵的周期。
这些想法——部分应用、引用透明和惰性操作——不仅仅是学术概念。他们解决现实世界的问题：
无论我们坚持使用 ~() 还是探索像 tie 和 Symbol.skip 这样的替代方案，基本原理都具有巨大的潜力来提高我们编写 JavaScript 的水平。
我投票支持符号方法，因为它很容易填充并且有多种用途。
我很好奇——你觉得怎么样？ ~() 是正确的方向吗，还是我们应该探索基于方法的方法？ 惰性操作将如何影响您的工作流程？评论里一起讨论吧！
JavaScript 的美妙之处在于它由社区驱动的演变。通过分享和辩论想法，我们可以塑造一种更适合每个人的语言。让我们继续对话吧！
以上是重新思考 JavaScript。部分应用、引用透明和惰性操作的详细内容。更多信息请关注PHP中文网其他相关文章！
