大家好，這里是大家的林語(yǔ)冰。

JS 的 with() 語(yǔ)句已被腰斬，且強(qiáng)烈建議直接禁用。雖然但是，這合理嗎喵？

with 語(yǔ)句實(shí)際已被棄用，且在嚴(yán)格模式下無(wú)法奏效，但即使綜合考慮其“18 禁”的原因，它仍然令人雞凍。讓我們花一些時(shí)間回首往昔，with() 的超能力是什么、其飽受爭(zhēng)議又是為何，以及本人對(duì)這些差評(píng)的反對(duì)意見(jiàn)。

訴諸 with() 讀寫屬性

當(dāng)我們讀寫 JS 對(duì)象的屬性時(shí)，我們幾乎總是需要訴諸標(biāo)識(shí)符來(lái)限定這些屬性，這樣引擎才知道哪里可以找到對(duì)應(yīng)的值。唯一的例外是全局變量。如果該名稱對(duì)應(yīng)的變量在作用域鏈中不存在，那么會(huì)將其作為 window 或 globalThis 的屬性進(jìn)行檢查。如下所示：

const name = '林語(yǔ)冰'
const cat = {
  name: '薛定諤',
  isSingle: true
}

// 搜索 cat 對(duì)象：
console.log(cat.name) // '薛定諤'

// 搜索作用域鏈，然后繼續(xù)上溯搜索 window/globalThis：
console.log(name) // '林語(yǔ)冰'

在沒(méi)有限定標(biāo)識(shí)符的情況下，with 語(yǔ)句也能讀寫對(duì)象的屬性。我們只需將它們作為獨(dú)立的變量引用即可。

const cat = {
  name: '薛定諤',
  isSingle: true
}

with (cat) {
  console.log(name) // '薛定諤'
  console.log(isSingle) // `true`
}

這能奏效，因?yàn)?nbsp;with() 把 cat 插入作用域鏈的開(kāi)頭，這意味著，在繼續(xù)上溯搜索之前，這首先會(huì)搜索目標(biāo)對(duì)象的值。順便一提，您仍然可以從更寬泛的作用域讀寫變量 —— 您只需要依賴該顯式標(biāo)識(shí)符：

window.name = '林語(yǔ)冰'

with (cat) {
  console.log(window.name) // "林語(yǔ)冰"
}

在某些方面，它提供了類似于解構(gòu)賦值的人體工程學(xué)福利。這不需要重復(fù)標(biāo)識(shí)符，語(yǔ)法脂肪會(huì)稍減。但另一個(gè)福利是，with() 內(nèi)執(zhí)行的代碼包含在不同的區(qū)塊作用域中。

為什么要棄用 with？

如果我們偷瞄 TC39 文檔，我們會(huì)發(fā)現(xiàn)，with() 語(yǔ)句被標(biāo)記為“歷史包袱”，且不鼓勵(lì)使用，但它并沒(méi)有深入說(shuō)明原因。雖然但是，如果我們偷瞄其他資料，就會(huì)發(fā)現(xiàn)若干主要原因。（順便一提，我很可能遺漏了其他某些關(guān)于 with 的關(guān)鍵差評(píng)。如果您了解這些差評(píng)，請(qǐng)不吝賜教。）

1. 可讀性感人

如果沒(méi)有顯式標(biāo)識(shí)符，那么可能會(huì)寫下某些難以閱讀的“代媽屎山”。請(qǐng)瞄一下這個(gè)函數(shù)：

function doSomething(name, obj) {
  with (obj) {
    console.log(name)
  }

  console.log(name)
}

doSomething('林語(yǔ)冰', { name: '薛定諤' })
// '薛定諤'
// '林語(yǔ)冰'

乍一看，并不清楚 name 是什么鬼物 —— 是 obj 上的屬性，還是傳遞給函數(shù)的參數(shù)。并且相同的變量名在整個(gè)函數(shù)體中引用了截然不同的值。這很令人懵逼，并且可能會(huì)讓您搬起石頭砸到自己的貓。畢竟，根據(jù)該變量的使用位置，解析其作用域的執(zhí)行方式一龍一豬。

這是一個(gè)有意義的差評(píng)，但在我看來(lái)，這并非致命的批評(píng)。寫下這樣的代碼是開(kāi)發(fā)者（糟糕的）選擇，并且很大程度上似乎可以通過(guò)教育來(lái)解決。

2. 作用域泄漏/意外屬性讀寫

除此之外，由于其設(shè)計(jì)，我們可能會(huì)因?yàn)樽x寫不打算處理的不同作用域內(nèi)的屬性，而無(wú)意中遭遇 bug。假設(shè)我們有一個(gè)處理包含了戀愛(ài)史的 cat 對(duì)象的函數(shù)。

const cat = {
  history: ['girl1', 'lady2']
}

function processHistory(cat) {
  with (cat) {
    // 使用 history 屬性搞事情
  }
}

processHistory(cat)

直到您傳遞一個(gè)沒(méi)有 history 屬性的 cat 變量之前，這都能奏效。否則，history 將回退到 window.history（或作用域鏈上存在的其他某些 history 變量），導(dǎo)致意外 bug。

在這個(gè)簡(jiǎn)單的示例中，如果 history 是必需屬性，那就問(wèn)題不大（如果對(duì)象是通過(guò)對(duì)象字面量創(chuàng)建的，那么 TS 可以提供輔助），但我們可以看到在更復(fù)雜的場(chǎng)景中出現(xiàn)其他意外。我們正在修改作用域鏈。在某些時(shí)候，奇奇怪怪的事情肯定會(huì)發(fā)生。

3. 性能挑戰(zhàn)

當(dāng)與性能相關(guān)時(shí)，事情會(huì)變得更有趣。在我看來(lái)，這是我見(jiàn)過(guò)的最義憤填膺的差評(píng)。

當(dāng)在 with 語(yǔ)句中讀寫屬性時(shí)，不僅會(huì)在給定對(duì)象的頂層屬性中搜索它的值，還會(huì)在其整個(gè)原型鏈中搜索。如果在原型鏈中搜索不到，它就會(huì)從一個(gè)作用域上溯另一個(gè)作用域繼續(xù)搜索。每次屬性讀寫都必然會(huì)遵循這種搜索順序。根據(jù)具體需求的不同，這可能會(huì)導(dǎo)致某些緩慢的搜索和高性能雷區(qū)。

此處簡(jiǎn)述一下下，我們使用 with 讀寫 me 的屬性，該屬性位于原型鏈的底部：

const creature = { name: '碳基生物', planet: '地球' }
const mammal = Object.create(creature, { name: { value: '哺乳動(dòng)物' } })
const human = Object.create(mammal, { name: { value: '人族' } })
const me = Object.create(human, { name: { value: '林語(yǔ)冰' } })

function outerFunction() {
  const outer = 'outer'

  function innerFunction() {
    const inner = 'inner'

    with (me) {
      console.log(name, planet, inner, outer)
      // '林語(yǔ)冰' '地球' 'inner' 'outer'
    }
  }

  innerFunction()
}

outerFunction()

由于 name 直接存儲(chǔ)在 me 對(duì)象上，因此搜索它沒(méi)有太多開(kāi)銷。粉絲請(qǐng)記住 —— 目標(biāo)對(duì)象的頂層屬性優(yōu)先被搜索。但 planet 不并非如此，它不在 me 對(duì)象上，因此原型鏈中的每個(gè)對(duì)象都會(huì)搜索一個(gè)值，直到找到為止。

普遍推薦的備胎方案

為了獲得相同的“干凈”變量規(guī)避此風(fēng)險(xiǎn)，通常建議使用解構(gòu)賦值。我們重構(gòu)之前的繼承示例：

const creature = { name: '碳基生物', planet: '地球' }
const mammal = Object.create(creature, { name: { value: '哺乳動(dòng)物' } })
const human = Object.create(mammal, { name: { value: '人族' } })
const me = Object.create(human, { name: { value: '林語(yǔ)冰' } })

const { name, planet } = me

console.log(name, planet)
// `林語(yǔ)冰` `地球`

我理解這為什么這會(huì)成為建議的替代方案：

• 關(guān)于變量的來(lái)源相對(duì)清晰。
• 編譯器可以對(duì)讀寫屬性的位置做出更好的假設(shè)（和優(yōu)化），這有利于性能（由于仍需要搜索原型鏈，因此成本同樣存在）。
• 您仍然可以使用沒(méi)有標(biāo)識(shí)符的變量。

但從可讀性的角度來(lái)看，我并不完全相信它是一個(gè)有價(jià)值的選擇。

為何 with() 有時(shí)優(yōu)于解構(gòu)賦值

使用 with() 的吸引力不僅僅在于“干凈”的變量。它就在控制結(jié)構(gòu)中。由于其周圍的語(yǔ)法，很容易在 with() 語(yǔ)句中有意識(shí)地“存儲(chǔ)”特定任務(wù)。該代碼在詞法作用域和動(dòng)機(jī)上都與其余代碼分開(kāi)，更易于推理。

請(qǐng)想象一下，您正在處理一個(gè) HTTP 請(qǐng)求，該請(qǐng)求在請(qǐng)求中傳遞某些信息，并且您以某種方式在 data 變量中讀寫它。您的目標(biāo)是使用特定屬性將記錄保存到數(shù)據(jù)庫(kù)中。以下是使用解構(gòu)屬性的方案：

const { imageUrl, width, height } = data

await saveToDb({
  imageUrl,
  width,
  height
})

這很好，但是需要多一行代碼來(lái)處理這些變量。另外，它們現(xiàn)在都是區(qū)塊作用域，并且可能與方法中涉及的任何其他事情發(fā)生沖突。此時(shí)可能會(huì)有若干意見(jiàn)：

“只需將代碼移動(dòng)到它自己的方法中即可?！蔽也挥憛挻艘庖?jiàn)。從 OOP（面向?qū)ο缶幊蹋┰O(shè)計(jì)的角度來(lái)看，這甚至可能是一件好事 —— 父方法會(huì)更精簡(jiǎn)和集中。但此建議感覺(jué)也像是針對(duì)使用解構(gòu)賦值而引入的問(wèn)題的解決方案，并且可以使用 with() 的語(yǔ)義來(lái)緩解。根據(jù)發(fā)生的其他情況，我可能不想創(chuàng)建一個(gè)不同的方法，但仍然希望有一個(gè)不同的作用域。

“將其全部包裹在一個(gè)臨時(shí)區(qū)塊中?！眂onst 是區(qū)塊作用域，這意味著，可以通過(guò)使用大括號(hào)創(chuàng)建新的塊作用域來(lái)包含它：

const imageUrl = 'different-image.jpg'

{
  const { imageUrl, width, height } = data

  await saveToDb({
    imageUrl,
    width,
    height
  })
}

這里有某些值得褒獎(jiǎng)的奇技淫巧，但您無(wú)法讓我相信它更具可讀性。這不是黑客攻擊，但目測(cè)有點(diǎn)像黑客攻擊。

訴諸 with() 重構(gòu)

現(xiàn)在，針對(duì)同樣的需求，這一次我們?cè)V諸 with 語(yǔ)句來(lái)重構(gòu)：

with (data) {
  await saveToDb({
    imageUrl,
    width,
    height
  })
}

• 與 with 配對(duì)的控制結(jié)構(gòu)一目了然，與 data 相關(guān)的特定事情會(huì)發(fā)生，并將某些內(nèi)容保存到數(shù)據(jù)庫(kù)中。
• 由于屬性名稱簡(jiǎn)寫，我不需要先解構(gòu) data 的值，然后再將它們傳遞給我的方法。為我節(jié)省了一行代碼。
• 任何變量都不能污染此方法的其他部分。

我依然認(rèn)為，解構(gòu)賦值是一個(gè)給力的功能（我經(jīng)常使用它），但至少在可讀性和語(yǔ)義方面，它并不能完全作為 with() 的替代方案。

性能考量

根據(jù) with() 設(shè)計(jì)操作的本質(zhì)，它絕對(duì)不是處理對(duì)象屬性的最嚴(yán)格的最佳實(shí)踐。但我有所質(zhì)疑，鑒于代碼中實(shí)際發(fā)生的情況，以及與人體工程學(xué)和易讀性收益的權(quán)衡，這種擔(dān)憂到底有多嚴(yán)重。

請(qǐng)考慮此栗子。在我見(jiàn)過(guò)的大多數(shù) with() 案例中，大家使用的對(duì)象并不復(fù)雜。它們通常只是簡(jiǎn)單的鍵值對(duì)。因此，與大多數(shù)此類案例相比，我制作了一個(gè)相當(dāng)大的案例。這是美國(guó)每個(gè)州的列表：

const states = {
  alabama: 'AL',
  alaska: 'AK',
  arizona: 'AZ',
  arkansas: 'AR',
  california: 'CA'
  //... 其余的州府
}

然后，我運(yùn)行了一個(gè)快速基準(zhǔn)測(cè)試來(lái)打印每個(gè)值。一項(xiàng)測(cè)試使用了 with()：

with (states) {
  console.log(alabama, alaska /* ...其余的屬性 */)
}

另一項(xiàng)測(cè)試使用解構(gòu)賦值：

const { alabama, alaska /* ...其余屬性 */ } = states

console.log(alabama, alaska /* ...其余屬性 */)

預(yù)料之內(nèi)，with() 速度較慢，總體慢了約 23%：

圖片

但如果您仔細(xì)觀察這些數(shù)字，并將其置于現(xiàn)實(shí)世界中，就會(huì)發(fā)現(xiàn)此差異幾乎是“沒(méi)事找事”。畢竟，您在一秒鐘內(nèi)要處理數(shù)萬(wàn)個(gè)操作。

別誤會(huì)我的意思。在對(duì)執(zhí)行性能高度敏感的環(huán)境中，這可能會(huì)產(chǎn)生十分有意義的變化。但這些場(chǎng)景可能很少，而且它們可能不應(yīng)該使用 JS。顯然，它們是用 PHP 編寫的。

最重要的是，值得指出的是，with() 遠(yuǎn)不是唯一一個(gè)在使用不當(dāng)時(shí)，可能會(huì)導(dǎo)致性能適得其反的 JS 功能。僅舉一個(gè)栗子：擴(kuò)展運(yùn)算符寫起來(lái)確實(shí)很好，但如果在我們代碼的其余部分中沒(méi)有小心使用它，事情就會(huì)變得十分敏感。

with 可以更快嗎？

我很樂(lè)意看到一個(gè)“更好”版本的 with() 卷土從來(lái)，并進(jìn)行某些調(diào)整提高性能。

我不介意看到的一個(gè)十分具體的變化是不再搜索原型鏈。新版改進(jìn)的 with() 只會(huì)考慮從 Object.getOwnPropertyNames() 返回的對(duì)象的頂層屬性。此更改將減少解析變量所需的時(shí)間，尤其是當(dāng)您完全訪問(wèn) with() 上下文之外的變量時(shí)。

一個(gè)與此相關(guān)的有前途的基準(zhǔn)測(cè)試。我制作了一個(gè)具有 100 個(gè)鍵/值對(duì)的對(duì)象，其原型鏈有 100 層深。每個(gè)層級(jí)都有相同的一組鍵/值對(duì)。這是用來(lái)制作它的零碎代碼：

function makeComplicatedObject() {
  const obj = Object.fromEntries(
    Array.from({ length: 100 }).map((_, index) => [
      `key_${index}`,
      `value_${index}`
    ])
  )

  return obj
}

// 結(jié)果：100 個(gè)鍵值對(duì)，原型鏈 100 層深度
const deeplyNestedObject = Array.from({ length: 100 }).reduce(
  (prevObj, _current, index) => {
    let newObject = makeComplicatedObject()
    Object.setPrototypeOf(newObject, prevObj)
    return newObject
  },
  makeComplicatedObject()
)

然后，我在該深層嵌套對(duì)象和具有相同鍵/值對(duì)但沒(méi)有巨大原型鏈的另一個(gè)對(duì)象之間運(yùn)行了基準(zhǔn)測(cè)試。每個(gè)代碼片段都會(huì)簡(jiǎn)單地記錄另一個(gè)局部變量。雖然但是，由于它位于 with() 內(nèi)部，因此它必須首先等待這些對(duì)象被爬取。

結(jié)果應(yīng)該不足為奇。該對(duì)象的“扁平”版本的搜索速度大約快 36%。

圖片

這就說(shuō)得通了。它并沒(méi)有讓 with() 遍歷那個(gè)令人討厭的原型鏈。我敢打賭，99.99% 的使用 with() 的現(xiàn)實(shí)代碼也不需要這樣做。

個(gè)人專屬限量版 with

順便一提，我在構(gòu)建自己的更“限量版”的 with() 時(shí)度過(guò)了一段有趣的時(shí)光。它使用一個(gè)簡(jiǎn)單的 Proxy 來(lái)使 with() 認(rèn)為該對(duì)象僅在它是頂級(jí)鍵之一時(shí)“具有”屬性：

function limitedWith(obj, cb) {
  const keys = Object.getOwnPropertyNames(obj)
  const scopedObj = new Proxy(obj, {
    has(_target, key) {
      return keys.includes(key)
    }
  })

  return eval(`
    with(scopedObj) {
      (${cb}.bind(this))();
    }
  `)
}

盡管使用 JS 來(lái)解決驅(qū)動(dòng)引擎的原生代碼無(wú)疑可以青出于藍(lán)勝于藍(lán)，但基準(zhǔn)測(cè)試結(jié)果也不算太糟糕：

圖片

當(dāng)然，這只是桌面上的一項(xiàng)優(yōu)化。我也不討厭能夠?qū)⒛繕?biāo)作用域傳遞到 with() 的想法。默認(rèn)情況下，它將在作用域鏈中一直搜索變量。但如果傳遞特定值，它將被限制在該作用域內(nèi)：

with ((someObject, { scope: 'module' })) {
  // 在 someObject 的外部，
  // 當(dāng)且僅當(dāng)此模塊作用域會(huì)被搜索
}

您并不了解所有用例

拋開(kāi)這些問(wèn)題不談，當(dāng)大家不鼓勵(lì)使用某功能時(shí)，它們很可能會(huì)在有限范圍的情況下思考，并在此過(guò)程中做出若干假設(shè)。它們可能包括但不限于：

• 執(zhí)行速度茲事體大。
• 這是完成任務(wù)的低效方法。
• 該代碼將始終在主線程上運(yùn)行。
• 還有更多......

順便一提，這樣的假設(shè)通常是準(zhǔn)確的，值得牢記在心。但它們并不總是準(zhǔn)確的。它們經(jīng)常忽視工程師被迫做出的特定權(quán)衡、它們正在構(gòu)建的工具的目的或其他因素。

最好的證據(jù)是這樣一個(gè)事實(shí)：由真正聰明、有洞察力的工程師編寫的真正優(yōu)秀、信譽(yù)良好的庫(kù)，今天在它們的代碼庫(kù)中仍然有 with()。

有的庫(kù)的大部分內(nèi)容都不會(huì)在主線程中執(zhí)行，因此它與大多數(shù)其他庫(kù)相比，在一組根本不同的性能約束上運(yùn)行。這可以說(shuō)是一個(gè)特例，但至少與 with() 應(yīng)該被撤銷的主張相悖。畢竟，您必須有一個(gè)非常非常好的案例，才能移除某個(gè)功能，尤其是當(dāng)它已經(jīng)成為該語(yǔ)言的一部分這么久的情況下。

長(zhǎng)話短說(shuō)

• 使用 with() 存在某些獨(dú)特的挑戰(zhàn)和風(fēng)險(xiǎn)（盡管它們并不像 ES2015 之前那么糟糕）。
• 推薦的備胎方案還不夠好。
• 無(wú)論如何，這些挑戰(zhàn)和風(fēng)險(xiǎn)往往被夸大了。
• 盡管如此，我們或許可以構(gòu)建更負(fù)責(zé)任的版本來(lái)取代它。
• 您可能沒(méi)有理由普遍阻止一項(xiàng)已經(jīng)存在很長(zhǎng)時(shí)間的功能。