紅魔電競平板評測：大屏幕硬實力
前言：三年的疫情因為要上網(wǎng)課的原因激活了平板市場，如今網(wǎng)課的時代已經(jīng)過去，大家的生活都恢復(fù)到了正軌，這也就意味著，真正考驗平板電腦生存的環(huán)境來了。也就是面對著這種殘酷的
大家好，這里是大家的林語冰。
JS 的 with() 語句已被腰斬，且強(qiáng)烈建議直接禁用。雖然但是，這合理嗎喵？
with 語句實際已被棄用，且在嚴(yán)格模式下無法奏效，但即使綜合考慮其“18 禁”的原因，它仍然令人雞凍。讓我們花一些時間回首往昔，with() 的超能力是什么、其飽受爭議又是為何，以及本人對這些差評的反對意見。
當(dāng)我們讀寫 JS 對象的屬性時，我們幾乎總是需要訴諸標(biāo)識符來限定這些屬性，這樣引擎才知道哪里可以找到對應(yīng)的值。唯一的例外是全局變量。如果該名稱對應(yīng)的變量在作用域鏈中不存在，那么會將其作為 window 或 globalThis 的屬性進(jìn)行檢查。如下所示：
const name = '林語冰'const cat = { name: '薛定諤', isSingle: true}// 搜索 cat 對象：console.log(cat.name) // '薛定諤'// 搜索作用域鏈，然后繼續(xù)上溯搜索 window/globalThis：console.log(name) // '林語冰'在沒有限定標(biāo)識符的情況下，with 語句也能讀寫對象的屬性。我們只需將它們作為獨立的變量引用即可。
const cat = { name: '薛定諤', isSingle: true}with (cat) { console.log(name) // '薛定諤' console.log(isSingle) // `true`}這能奏效，因為 with() 把 cat 插入作用域鏈的開頭，這意味著，在繼續(xù)上溯搜索之前，這首先會搜索目標(biāo)對象的值。順便一提，您仍然可以從更寬泛的作用域讀寫變量 —— 您只需要依賴該顯式標(biāo)識符：
window.name = '林語冰'with (cat) { console.log(window.name) // "林語冰"}在某些方面，它提供了類似于解構(gòu)賦值的人體工程學(xué)福利。這不需要重復(fù)標(biāo)識符，語法脂肪會稍減。但另一個福利是，with() 內(nèi)執(zhí)行的代碼包含在不同的區(qū)塊作用域中。
如果我們偷瞄 TC39 文檔，我們會發(fā)現(xiàn)，with() 語句被標(biāo)記為“歷史包袱”，且不鼓勵使用，但它并沒有深入說明原因。雖然但是，如果我們偷瞄其他資料，就會發(fā)現(xiàn)若干主要原因。（順便一提，我很可能遺漏了其他某些關(guān)于 with 的關(guān)鍵差評。如果您了解這些差評，請不吝賜教。）
如果沒有顯式標(biāo)識符，那么可能會寫下某些難以閱讀的“代媽屎山”。請瞄一下這個函數(shù)：
function doSomething(name, obj) { with (obj) { console.log(name) } console.log(name)}doSomething('林語冰', { name: '薛定諤' })// '薛定諤'// '林語冰'乍一看，并不清楚 name 是什么鬼物 —— 是 obj 上的屬性，還是傳遞給函數(shù)的參數(shù)。并且相同的變量名在整個函數(shù)體中引用了截然不同的值。這很令人懵逼，并且可能會讓您搬起石頭砸到自己的貓。畢竟，根據(jù)該變量的使用位置，解析其作用域的執(zhí)行方式一龍一豬。
這是一個有意義的差評，但在我看來，這并非致命的批評。寫下這樣的代碼是開發(fā)者（糟糕的）選擇，并且很大程度上似乎可以通過教育來解決。
除此之外，由于其設(shè)計，我們可能會因為讀寫不打算處理的不同作用域內(nèi)的屬性，而無意中遭遇 bug。假設(shè)我們有一個處理包含了戀愛史的 cat 對象的函數(shù)。
const cat = { history: ['girl1', 'lady2']}function processHistory(cat) { with (cat) { // 使用 history 屬性搞事情 }}processHistory(cat)直到您傳遞一個沒有 history 屬性的 cat 變量之前，這都能奏效。否則，history 將回退到 window.history（或作用域鏈上存在的其他某些 history 變量），導(dǎo)致意外 bug。
在這個簡單的示例中，如果 history 是必需屬性，那就問題不大（如果對象是通過對象字面量創(chuàng)建的，那么 TS 可以提供輔助），但我們可以看到在更復(fù)雜的場景中出現(xiàn)其他意外。我們正在修改作用域鏈。在某些時候，奇奇怪怪的事情肯定會發(fā)生。
當(dāng)與性能相關(guān)時，事情會變得更有趣。在我看來，這是我見過的最義憤填膺的差評。
當(dāng)在 with 語句中讀寫屬性時，不僅會在給定對象的頂層屬性中搜索它的值，還會在其整個原型鏈中搜索。如果在原型鏈中搜索不到，它就會從一個作用域上溯另一個作用域繼續(xù)搜索。每次屬性讀寫都必然會遵循這種搜索順序。根據(jù)具體需求的不同，這可能會導(dǎo)致某些緩慢的搜索和高性能雷區(qū)。
此處簡述一下下，我們使用 with 讀寫 me 的屬性，該屬性位于原型鏈的底部：
const creature = { name: '碳基生物', planet: '地球' }const mammal = Object.create(creature, { name: { value: '哺乳動物' } })const human = Object.create(mammal, { name: { value: '人族' } })const me = Object.create(human, { name: { value: '林語冰' } })function outerFunction() { const outer = 'outer' function innerFunction() { const inner = 'inner' with (me) { console.log(name, planet, inner, outer) // '林語冰' '地球' 'inner' 'outer' } } innerFunction()}outerFunction()由于 name 直接存儲在 me 對象上，因此搜索它沒有太多開銷。粉絲請記住 —— 目標(biāo)對象的頂層屬性優(yōu)先被搜索。但 planet 不并非如此，它不在 me 對象上，因此原型鏈中的每個對象都會搜索一個值，直到找到為止。
為了獲得相同的“干凈”變量規(guī)避此風(fēng)險，通常建議使用解構(gòu)賦值。我們重構(gòu)之前的繼承示例：
const creature = { name: '碳基生物', planet: '地球' }const mammal = Object.create(creature, { name: { value: '哺乳動物' } })const human = Object.create(mammal, { name: { value: '人族' } })const me = Object.create(human, { name: { value: '林語冰' } })const { name, planet } = meconsole.log(name, planet)// `林語冰` `地球`我理解這為什么這會成為建議的替代方案：
但從可讀性的角度來看，我并不完全相信它是一個有價值的選擇。
使用 with() 的吸引力不僅僅在于“干凈”的變量。它就在控制結(jié)構(gòu)中。由于其周圍的語法，很容易在 with() 語句中有意識地“存儲”特定任務(wù)。該代碼在詞法作用域和動機(jī)上都與其余代碼分開，更易于推理。
請想象一下，您正在處理一個 HTTP 請求，該請求在請求中傳遞某些信息，并且您以某種方式在 data 變量中讀寫它。您的目標(biāo)是使用特定屬性將記錄保存到數(shù)據(jù)庫中。以下是使用解構(gòu)屬性的方案：
const { imageUrl, width, height } = dataawait saveToDb({ imageUrl, width, height})這很好，但是需要多一行代碼來處理這些變量。另外，它們現(xiàn)在都是區(qū)塊作用域，并且可能與方法中涉及的任何其他事情發(fā)生沖突。此時可能會有若干意見：
“只需將代碼移動到它自己的方法中即可。”我不討厭此意見。從 OOP（面向?qū)ο缶幊蹋┰O(shè)計的角度來看，這甚至可能是一件好事 —— 父方法會更精簡和集中。但此建議感覺也像是針對使用解構(gòu)賦值而引入的問題的解決方案，并且可以使用 with() 的語義來緩解。根據(jù)發(fā)生的其他情況，我可能不想創(chuàng)建一個不同的方法，但仍然希望有一個不同的作用域。
“將其全部包裹在一個臨時區(qū)塊中。”const 是區(qū)塊作用域，這意味著，可以通過使用大括號創(chuàng)建新的塊作用域來包含它：
const imageUrl = 'different-image.jpg'{ const { imageUrl, width, height } = data await saveToDb({ imageUrl, width, height })}這里有某些值得褒獎的奇技淫巧，但您無法讓我相信它更具可讀性。這不是黑客攻擊，但目測有點像黑客攻擊。
現(xiàn)在，針對同樣的需求，這一次我們訴諸 with 語句來重構(gòu)：
with (data) { await saveToDb({ imageUrl, width, height })}我依然認(rèn)為，解構(gòu)賦值是一個給力的功能（我經(jīng)常使用它），但至少在可讀性和語義方面，它并不能完全作為 with() 的替代方案。
根據(jù) with() 設(shè)計操作的本質(zhì)，它絕對不是處理對象屬性的最嚴(yán)格的最佳實踐。但我有所質(zhì)疑，鑒于代碼中實際發(fā)生的情況，以及與人體工程學(xué)和易讀性收益的權(quán)衡，這種擔(dān)憂到底有多嚴(yán)重。
請考慮此栗子。在我見過的大多數(shù) with() 案例中，大家使用的對象并不復(fù)雜。它們通常只是簡單的鍵值對。因此，與大多數(shù)此類案例相比，我制作了一個相當(dāng)大的案例。這是美國每個州的列表：
const states = { alabama: 'AL', alaska: 'AK', arizona: 'AZ', arkansas: 'AR', california: 'CA' //... 其余的州府}然后，我運行了一個快速基準(zhǔn)測試來打印每個值。一項測試使用了 with()：
with (states) { console.log(alabama, alaska /* ...其余的屬性 */)}另一項測試使用解構(gòu)賦值：
const { alabama, alaska /* ...其余屬性 */ } = statesconsole.log(alabama, alaska /* ...其余屬性 */)預(yù)料之內(nèi)，with() 速度較慢，總體慢了約 23%：
圖片
但如果您仔細(xì)觀察這些數(shù)字，并將其置于現(xiàn)實世界中，就會發(fā)現(xiàn)此差異幾乎是“沒事找事”。畢竟，您在一秒鐘內(nèi)要處理數(shù)萬個操作。
別誤會我的意思。在對執(zhí)行性能高度敏感的環(huán)境中，這可能會產(chǎn)生十分有意義的變化。但這些場景可能很少，而且它們可能不應(yīng)該使用 JS。顯然，它們是用 PHP 編寫的。
最重要的是，值得指出的是，with() 遠(yuǎn)不是唯一一個在使用不當(dāng)時，可能會導(dǎo)致性能適得其反的 JS 功能。僅舉一個栗子：擴(kuò)展運算符寫起來確實很好，但如果在我們代碼的其余部分中沒有小心使用它，事情就會變得十分敏感。
我很樂意看到一個“更好”版本的 with() 卷土從來，并進(jìn)行某些調(diào)整提高性能。
我不介意看到的一個十分具體的變化是不再搜索原型鏈。新版改進(jìn)的 with() 只會考慮從 Object.getOwnPropertyNames() 返回的對象的頂層屬性。此更改將減少解析變量所需的時間，尤其是當(dāng)您完全訪問 with() 上下文之外的變量時。
一個與此相關(guān)的有前途的基準(zhǔn)測試。我制作了一個具有 100 個鍵/值對的對象，其原型鏈有 100 層深。每個層級都有相同的一組鍵/值對。這是用來制作它的零碎代碼：
function makeComplicatedObject() { const obj = Object.fromEntries( Array.from({ length: 100 }).map((_, index) => [ `key_${index}`, `value_${index}` ]) ) return obj}// 結(jié)果：100 個鍵值對，原型鏈 100 層深度const deeplyNestedObject = Array.from({ length: 100 }).reduce( (prevObj, _current, index) => { let newObject = makeComplicatedObject() Object.setPrototypeOf(newObject, prevObj) return newObject }, makeComplicatedObject())然后，我在該深層嵌套對象和具有相同鍵/值對但沒有巨大原型鏈的另一個對象之間運行了基準(zhǔn)測試。每個代碼片段都會簡單地記錄另一個局部變量。雖然但是，由于它位于 with() 內(nèi)部，因此它必須首先等待這些對象被爬取。
結(jié)果應(yīng)該不足為奇。該對象的“扁平”版本的搜索速度大約快 36%。
圖片
這就說得通了。它并沒有讓 with() 遍歷那個令人討厭的原型鏈。我敢打賭，99.99% 的使用 with() 的現(xiàn)實代碼也不需要這樣做。
順便一提，我在構(gòu)建自己的更“限量版”的 with() 時度過了一段有趣的時光。它使用一個簡單的 Proxy 來使 with() 認(rèn)為該對象僅在它是頂級鍵之一時“具有”屬性：
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 來解決驅(qū)動引擎的原生代碼無疑可以青出于藍(lán)勝于藍(lán)，但基準(zhǔn)測試結(jié)果也不算太糟糕：
圖片
當(dāng)然，這只是桌面上的一項優(yōu)化。我也不討厭能夠?qū)⒛繕?biāo)作用域傳遞到 with() 的想法。默認(rèn)情況下，它將在作用域鏈中一直搜索變量。但如果傳遞特定值，它將被限制在該作用域內(nèi)：
with ((someObject, { scope: 'module' })) { // 在 someObject 的外部， // 當(dāng)且僅當(dāng)此模塊作用域會被搜索}拋開這些問題不談，當(dāng)大家不鼓勵使用某功能時，它們很可能會在有限范圍的情況下思考，并在此過程中做出若干假設(shè)。它們可能包括但不限于：
順便一提，這樣的假設(shè)通常是準(zhǔn)確的，值得牢記在心。但它們并不總是準(zhǔn)確的。它們經(jīng)常忽視工程師被迫做出的特定權(quán)衡、它們正在構(gòu)建的工具的目的或其他因素。
最好的證據(jù)是這樣一個事實：由真正聰明、有洞察力的工程師編寫的真正優(yōu)秀、信譽良好的庫，今天在它們的代碼庫中仍然有 with()。
有的庫的大部分內(nèi)容都不會在主線程中執(zhí)行，因此它與大多數(shù)其他庫相比，在一組根本不同的性能約束上運行。這可以說是一個特例，但至少與 with() 應(yīng)該被撤銷的主張相悖。畢竟，您必須有一個非常非常好的案例，才能移除某個功能，尤其是當(dāng)它已經(jīng)成為該語言的一部分這么久的情況下。
本文鏈接：http://www.www897cc.com/showinfo-26-58932-0.html您不知道的 JS with 語句，讓我來告訴您！
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： Apollo，真香！
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號