Почему загружается встроенный JavaScript внутри просмотров с AJAX плохо?

У нас есть интерфейс с вкладками, внутри одной из этих вкладок - форма конфиденциальности. Эта форма конфиденциальности, а также использование внешнего файла JavaScript для большей части своей работы также использует встроенный JavaScript, поскольку в настоящее время он использует динамический код (на стороне сервера).

formTabs wrapper (вкладки ajax без функций обратного вызова)

...
<script type ="text/javascript">
    var messagingTabset = ProjectName.Tabset.init({
        'tabID': 'preferences-tabset',
        'ajaxUrl0': '<%=Url.Action("PreferencesMainForm", "Profile")%>',
        'ajaxUrl1': '<%=Url.Action("ProfileImageForm", "Profile")%>',
        'ajaxUrl2': '<%=Url.Action("InterestsForm", "Profile")%>',
        'ajaxUrl3': '<%=Url.Action("PrivacyForm", "Profile")%>',
        'ajaxUrl4': '<%=Url.Action("PasswordForm", "Profile")%>',
        'ajaxUrl5': '<%=Url.Action("CustomUrlForm", "Profile", new {userId = Model.UserId})%>',
        'defaultAjaxUrl': '<%=Url.Action(Model.PartialName, "Profile")%>'
    });
</script>
...

вид конфиденциальностиForm (более встроенный javascript с серверным кодом)

...
<script type = "text/javascript">
    var preferencesPrivacyForm = new ProjectName.AJAX.Form({
        "ajaxFormID": "preferences-privacy-form",
        "actionUrl": '<%= Url.Action("SavePrivacy","Profile") %>',
        "dataReturnType":"json"
    });
</script>
...

Разработчик заглавных букв: "Код JavaScript конфигурации для этой формы должен оставаться в режиме конфиденциальностиForm"

Разработчик интерфейсов: "Хм, я уверен, что я читал, что это не способ сделать это - ненадежный, весь JavaScript должен быть внутри HTML-страницы, содержащей вкладки обертка, внутри функции обратного вызова этой загрузки вкладок. Вы должны действительно a) предоставить логику для меня, чтобы получить динамические данные внутри вкладки-обертки или b) позволить мне захватить эти динамические переменные через обход DOM"

Разработчик заставкой: "Оба эти метода - большая часть работы, без реальной выплаты! Первый пример плох, потому что это означает, что мне придется изменить способ его создания ( и работает отлично).Это, вероятно, будет означать дублирование. Второй пример является изворотливым, поскольку разметка может измениться, поэтому кто-то, кто работает над кодом, может забыть отредактировать методы обхода DOM в wrap-wrapper. Это еще один уровень абстракции, который нам не нужно. Если вы предоставите мне некоторые доказательства того, почему это действительно очень плохо, я проверю это, но в противном случае я не могу оправдать время в

Разработчик интерфейсов: "Ну, я уже потратил несколько дней на то, чтобы устранить проблемы с загруженным JavaScript AJAX, поставив их в обратные вызовы своих оберток, но да, теперь вы думаете об этом, Хорошая ссылка на эту вещь была бы очень приятной, потому что вы правы, на данный момент приложение работает без проблем. '

Это один из многих примеров в большом приложении, где мы загружаем встроенный JavaScript с помощью Ajax.

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

ОТВЕТЫ

Ответ 1

Я бы рекомендовал прочитать Dale Carnegie "Как завоевать друзей и влиять на людей".

Кажется, разработчики постоянно попадают в эту ситуацию, где знают, что лучше всего делать, но они не покупают у других разработчиков или руководства.

Эта книга, безусловно, стоит читать; абсолют ДОЛЖЕН читать для этой профессии.

Ответ 2

Это не совсем "плохо", если оно служит цели (например, оно загружает контент с других веб-сайтов, таких как панель инструментов WordPress), но все дополнительные вызовы на сервер являются пустой тратой ресурсов, если вы не абсолютно необходимо это сделать.

Обычно самый простой ответ является наиболее правильным. В этом случае это означает, что вы не добавляете лишние накладные расходы, чтобы избежать небольшой перекодировки back-end.

Ответ 3

Это основной аргумент в пользу того, почему ненавязчивый Javascript (UJS) хорош. Я никогда не понимал его достоинства, потому что не знал, как решать проблемы без встроенного Javascript. В конце концов я узнал.

Прежде всего, UJS хорош, потому что он разделяет ваш код переднего конца следующим образом:

  • HTML - чистый HTML предназначен для структурирования вашей информации.
  • CSS - CSS используется для стилизации вашего документа и его компоновки.
  • Javascript - Javascript используется для определения поведения вашей страницы.

Чтобы они работали вместе, файл HTML загружается во внешние файлы CSS для определения стилей и внешних файлов Javascript для определения поведения. Кроме того, вам нужны хорошо известные символы в вашем HTML (такие как идентификаторы, имена классов и теги), ваши CSS (правила id и class), чтобы ваш Javascript мог управлять структурой, макетом и стилями в соответствии с реализацией поведения.

С инфраструктурой Javascript, такой как jQuery, вы можете динамически привязывать обработчики javascript к событиям на ваших различных объектах HTML DOM. Это позволяет вам не делать это внутри HTML.

Я работал с кодом, который является чисто разделенным (структура, стиль/макет, поведение) и код, который является собачьим завтраком HTML, CSS и Javascript, включая HTML/JS-код, который был динамически сгенерирован с использованием ERB. Оба были трудно понять по разным причинам. Первый из них был трудным, потому что я должен был понять, что было в каждом из файлов, в то время как смешанный код был трудно понять, потому что мне приходилось выяснять, что такое JS, что такое HTML, что такое CSS, что инициализировали, когда и что был сгенерирован. Однако, как только я поехал по кривой обучения, разработка четкого разделения кода была менее эффективной и легче тестировать.

Для сгенерированного Javascript (например, с помощью ERB) вы можете, как правило, структурировать код, в котором у вас есть статический javascript, основанный на определенных пользовательских или контекстно-зависимых данных. Как было предложено предыдущим человеком, вы можете просто установить значения этих данных в разделе HEAD, а затем перейти со статическими файлами Javascript. Вы также можете использовать вызов AJAX для захвата этих же данных с сервера.

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

Ответ 4

Непонятно из примера, почему вам нужен AJAX в первую очередь. Почему бы просто не поставить

<script type ="text/javascript">
    var userId = "<<<<= userId >>>>"
</script>

прямо в голову HTML? Это быстрее для пользователя, проще на сервере, и вы избегаете всех видов сбоев с синхронизацией и обработкой ошибок для неудавшихся запросов.