反對將服務器端腳本包含在JavaScript代碼塊中的論點是什么？

Question

我已經爭論了一段時間反對將服務器端標簽嵌入JavaScript代碼中，但是今天卻被一個似乎不服從的開發人員當場。

所討論的代碼是舊版ASP應用程序，盡管這在很大程度上並不重要，因為它同樣適用於ASP.NET或PHP（例如）。

有問題的示例圍繞使用他們在ServerSide代碼中定義的常量進行。

'VB
Const MY_CONST: MY_CONST = 1
If sMyVbVar = MY_CONST Then
    'Do Something
End If

//JavaScript
if (sMyJsVar === "<%= MY_CONST%>"){
    //DoSomething
}

我對此的標准論點是：

1. 腳本注入：服務器端標記可能包含會破壞JavaScript代碼的代碼
2. 單元測試。 難以隔離要測試的代碼單元
3. 代碼分離：我們應該盡可能使網頁技術與眾不同。

這樣做的原因是，開發人員不必在兩個地方定義常量。 他們認為，由於這是他們控制的價值，因此不受腳本注入的限制。 這將我對（1）的論證減少為“我們試圖使標准保​​持簡單，並且定義例外情況會使人們感到困惑”

單元測試和代碼分離的論據也沒有成立，因為頁面本身是HTML，JavaScript，ASP.NET，CSS，XML的可怕混合物。 此頁面上所有可能包含的代碼都無法進行單元測試。

因此，我發現自己感覺就像是一個學徒，在特定情況下堅持更改代碼。

是否還有其他論據可能支持我的推理，或者我實際上在這種堅持下有點腐？

Answer 1

• 腳本注入：服務器端標記可能包含會破壞JavaScript代碼的代碼

因此，請正確編寫代碼，並確保在將值引入JavaScript上下文時正確地轉義了值。 如果您的框架不包括JavaScript“引號”工具（提示：可能只需要JSON支持），請編寫一個。

• 單元測試。 難以隔離要測試的代碼單元

這是一個好點，但是如果服務器有必要將內容放到頁面中以供代碼使用，那么這是必要的。 我的意思是，有時候這只是必須要做的。 做到這一點的一種好方法是頁面包含某種最小的數據塊。 因此，頁面上基於服務器的JavaScript實際上並不是要測試的“代碼”，而只是數據。 .js文件中包含的真實客戶端代碼可以找到並使用數據。

因此，該頁面可能包含：

<script>
  (function(window) {
    window['pageData'] = {
      companyName: '<%= company.name %>',
      // etc
    };
  })(this);
</script>

現在，您可以很好地將封裝在“ .js”文件中的純JavaScript代碼檢查window.pageData ，這很好。

• 代碼分離：我們應該盡可能使網頁技術與眾不同。

同意，但這只是事實，有時服務器端數據需要驅動客戶端行為。 僅出於存儲數據和滿足規則的目的而創建隱藏的DOM節點本身是一個非常丑陋的做法。

編碼規則和美觀是好東西。 但是，一個人應該務實，並從一切角度考慮。 重要的是要記住，此類規則的上下文並不總是完美的神創造，對於HTML，CSS和JavaScript，我認為這一事實非常明顯。 在這種不完美的環境中，強硬的規則可能會迫使您進行不必要的工作和實際上難以維護的代碼。

編輯 -哦，這是我剛才想到的； 某種妥協。 由jQuery幫派使用“微型模板”工具（部分是針對網絡天才首先對此表示歉意）（在一定程度上對他們首先道歉的網絡天才表示歉意）而流行的（部分）技巧是使用<script>標簽，這些標簽已被“中和”：

<script id='pageData' type='text/plain'>
  {
    'companyName': '<%= company.name %>',
    'accountType': '<%= user.primaryAccount.type %>',
    // etc
  }
</script>

現在，瀏覽器本身甚至不會執行該腳本-“ type”屬性不是它可以理解為代碼的東西，因此它會忽略它。 但是，瀏覽器確實使此類腳本的內容可用，因此您的代碼可以按“ id”值找到腳本，然后通過一些安全的JSON庫或本機瀏覽器API（如果可用）來解析該符號並提取所需的內容。 這些值仍必須正確地加上引號等，但是您可以避免XSS漏洞，因為它被解析為JSON，而不是“實時”成熟的JavaScript。

Answer 2

The reason for doing this was so that the developer did not have to define the constant in two places.

對我來說，這是一個比您可以反對的論點更好的論據。 這是DRY原則。 並且它大大增強了代碼的可維護性。

每一個極端的樣式指南/規則都會導致反樣式。 在這種情況下，您堅持技術分離會破壞DRY原理，並可能使代碼難以維護。 如果將DRY本身放到極限，甚至會導致產生反模式： softcoding 。

代碼可維護性是一個很好的平衡。 樣式指南可以幫助您保持這種平衡。 但是您必須知道這些指南何時會提供幫助，以及何時它們本身會成為問題。

---

請注意，在示例中，您給出的代碼不會破壞語法注釋或語法解析（即使stackoverflow也會正確注釋語法），因此IDE參數將不起作用，因為IDE仍可以正確解析該代碼。

Answer 3

1. 它根本變得不可讀。 您必須仔細看一下才能划分不同的語言。 如果JavaScript和混合語言使用相同的變量名，情況將變得更加糟糕。 對於那些不得不看別人的代碼的人來說，這尤其困難。

2. 許多IDE在混合文檔的語法突出顯示方面存在問題，這可能導致自動完成功能丟失，語法突出顯示正確等。

3. 它使代碼的可重用性降低。 考慮一個執行常見任務的JavaScript函數，例如回顯一系列事物。 如果您將JavaScript邏輯與要遍歷的數據分開，則可以在整個應用程序中使用相同的功能，並且對該功能的更改僅需執行一次。 如果要迭代的數據與JavaScript輸出循環混合在一起，您可能最終會重復JavaScript代碼，因為混合語言在每個循環之前都有一個附加的if語句。