Какова наилучшая практика для ссылки на javascript, специфичный для PartialView в asp.net-mvc?

Мне кажется, что вам лучше всего держать его с остальными скриптами.

вы должны связывать, минимизировать и "навсегда кэшировать" сценарии. Если вы это делаете, то даже у новых пользователей на вашем сайте есть только небольшой файл для загрузки. Разбивая его на несколько файлов, вы только вредите вещам. Лучше для них просто загрузить все, что им понадобится для вашего сайта, сразу.

Я бы рассмотрел отдельные пакеты, если у вас есть очень разные разделы вашего сайта,которые вы не ожидаете, что пользователи пересекут. Например, возможно, ваш неавторизованный раздел и раздел "только для участников". Даже тогда это не будет иметь большого значения, поэтому может иметь смысл просто объединять их таким образом, чтобы иметь смысл для общей архитектуры вашего сайта (например, возможно, раздел только для членов-это другая область mvc).

но вытаскивание скриптов, которые нужны частичным только потому, что не каждая страница будет использовать это будет контрпродуктивно.

EDIT: я думаю, что понимаю лучше после перечитывания. То, что я сказал, все еще в силе, но акцент сделан на связывании. Не просто включайте отдельные ссылки на сценарии для всех ваших сценариев на каждой странице, которая в этом нуждается. Лучше в основном объединить все сценарии, необходимые вашему сайту, и включить их на каждой странице. С кэшированием пользователи будут загружать его только один раз, а затем не делать дальнейших запросов скриптов при навигации по вашему сайту, а не каждая страница заканчивается еще одним уникальным скриптом, который требует скачивания.

Я думаю, что хорошее решение-создать методы расширений для добавления javascript в partialView

хороший пример : как отобразить раздел в частичном виде в MVC3?

ответ на ваш вопрос может быть получен из ответа на этот вопрос:

• считаете ли вы, что это частичное представление является частью всего веб-приложения или просто отдельным компонентом?

обычно это часть веб-приложения, так как вы собираетесь использовать его только внутри этого веб-приложения. Таким образом, с этой точки зрения нет необходимости связывать представление с его javascript, так как javascript, а также представление являются частью интернета во всяком случае, полностью.

• когда мы связываем вещи?

когда они связаны друг с другом и не связаны ни с чем другим вне его целостности. Я сомневаюсь, что ваш javascript для этого представления не зависит ни от чего другого за его пределами. Даже не jQuery? даже никаких рамок, например нокаут или боб.Яш? Если да, то почему бы вам не связать свой взгляд с этими рамками в нем тоже?

Да, Ответ - зависимостей. Их реализации и других зависимостей. Однако граница между реализацией и зависимостями становится размытой при работе с частичными представлениями внутри одного веб-приложения. Причина в том, что частичное представление является частью веб-приложения. Это просто способ обработки фреймворка, позволяющий вам отделять частичные представления многоразовым способом. Но все же частичное представление остается частью всего веб-приложения и, следовательно, скрипта его реализации.

Если вы следили за всеми этими мыслями, тогда вы согласитесь, что в данном конкретном случае не имеет значения, хотите ли вы связать код с частичным представлением или хотите связать его с остальными сценариями веб-приложения. это просто то же самое.

таким образом, решение должно быть продиктовано другими показателями, такими как производительность загрузки скрипта и так далее. Это выходит за рамки вопроса, но описания должны быть достаточно как ответ.

загрузка javascript ad-hoc по просто помещая эту ссылку внутри тела частичного представления - это правильная стратегия. Вы избегаете разбора и интерпретации накладных расходов на всех других страницах. Даже если ваш файл javascript кэшируется, все равно потребуется время (хотя и незначительное) для выполнения на каждой странице, которая включает его. Что делать, если у вас есть сложная логика или итерация по DOM, или у вас есть много таких файлов?..

действительно, это первый шаг к зрелой зависимости управление. Если вы знаете, что функция используется, на какой странице, какой именно рефакторинг или усилия обслуживании будет дешевле в будущем.

вопрос как для ссылки на ресурсы javascript из частичного представления. Вы не хотите просто сбросить <script> тег в середине страницы ^{[цитата необходимый]}, вместо этого вы можете использовать специальный управляющий активами, как кассета. Есть многочисленные льготы для используя его, но в первую очередь вы можете ссылаться на активы в одном месте жизненного цикла Страницы (например, из вашего частичного представления):

@{
  Bundles.Reference("scripts/your-dependency.js");
  Bundles.Reference("scripts/another-dependency.js");
}

...а затем сделайте требуемое<script> теги в другом месте (например, в главный вид):

<body>
  ...
</body>
  @Bundles.RenderScripts()
</html>

...который может включать дополнительные ресурсы, необходимые из других представлений и / или мини-пакетов, содержащих общий код javascript.

Я использую что-то вроде того, что объясняется здесь, отлично работает. http://blog.mariusschulz.com/2013/07/07/generating-external-javascript-files-using-partial-razor-views

Я думаю, что u должен использовать requirejs из-за

на мой взгляд, есть три важные причины:

вы можете создавать и повторно использовать модули, не засоряя глобальное пространство имен. Чем более загрязнено ваше глобальное пространство имен, тем больше вероятность столкновения функции/переменной. Это означает, что вы определяете функцию под названием "foo", а другой разработчик определяет функцию" foo " = одна из функций перезаписывается.

вы можете структурировать ваш код в отдельные папки и файлы и requirejs будет загружать их асинхронно, когда это необходимо, поэтому все просто работает.

вы можете построить для производства. RequireJS поставляется со своим собственным инструментом сборки под названием R. JS, который будет объединять и уродовать ваши модули javascript в один (или несколько) пакетов. Это улучшит скорость вашей страницы, поскольку пользователю придется делать меньше вызовов скриптов и загружать меньше контента (поскольку ваш JS уродлив).

вы можете взглянуть на эту простую демку проект:http://bit.ly/requirejs (в cloud9ide).

чтобы построить свои модули в одно приложение, все, что вам нужно сделать, это установить пакет requirejs npm и запустить команду: r.JS-o сборка / сборка.свойства.js

в разработке наличие всех модулей в отдельных файлах - это просто хороший способ структурировать и управлять кодом. Это также помогает вам в отладке (например, ошибка на " модуле.JS строка 17" вместо "скриптов.Яш линии 5373").

для производства, вы должны использовать инструмент сборки, чтобы объединить и уродовать javascript в один файл. Это поможет быстрее загрузить страницу, так как вы делаете меньше запросов. Каждый запрос, который вы делаете, чтобы загрузить что-то, замедляет вашу страницу. Чем медленнее ваша страница, тем меньше очков Google дает вам. Чем медленнее страница, тем более разочарованными будут ваши пользователи. Чем медленнее ваша страница, тем меньше продаж вы получите.

Если вы хотите узнать больше о производительности веб-страницы, посмотрите http://developer.yahoo.com/performance/rules.html