通過Razor向Knockout組件注入依賴項

Question

使用Knockout組件+ Asp.Net MVC時，以下代碼片段是一種好的做法嗎？ 我可能會缺少任何缺點嗎？

基本上是通過使用Razor服務器端渲染來注入部分ko組件依賴項（主要是初始數據）...

程式碼片段：

<my-component params="{ 
    foo: '@Model.FooProperty',
    bar: '@Model.BarProperty',
    baz: @Json.Encode(@Model.SomeArray)
}"> </my-component>

編輯：

為了避免@Quango指出的字符串轉義問題，我實現了此幫助程序：

public static stringEscapeString(this HtmlHelper helper, string value)
{
   return HttpUtility.JavaScriptStringEncode(value, true);
}

用法：

<my-component params="{ 
        foo: '@Html.EscapeString(Model.FooString)', ...

Answer 1

在我的工作中，我們在ASP.NET MVC項目中使用Knockout，並且確實考慮了這種不良做法。 但這可能不適用於您。 這是您必須自己判斷的事情

• 不緩存HTML（因為注入的值可能會更改）
• 不會將HTML與JavaScript捆綁在一起（與上述相同）
• 對於同一問題，混合使用不同的解決方案可能是一個不好的習慣，尤其是在（大型）團隊中。 從本質上講，您已經選擇了Knockout，因此“正常”的做法是獲取JavaScript中所需的任何數據，並在視圖中將其綁定。 如果這是通常的操作，請考慮是否真的要在此處創建異常，僅僅是因為數據（據說）是靜態的。 如果這一切都是為了節省一些字節，那么可以想象一下，將其平衡為以最小的包形式提供所有HTML和JavaScript，這些包也可以緩存在客戶端上。
• 以后無法覆蓋數據，它實際上是由服務器“硬編碼”的。
• 您的代碼變得不那么可移植。 Razor語法實際上將您的前端與所選的后端技術結合在一起。 如果這是一個長期的項目，請考慮是否可能在幾年后的將來有很小的機會，您可能會決定使用另一種后端技術可能是更好的選擇，並且如果真的有必要重寫一半，前端只是為了使之成為可能。

這些原因均與ALL項目無關，因此在很大程度上取決於上下文。 我嘗試列出了我能想到的盡可能多的缺點。