Почему загружает встроенный JavaScript в представлениях с Ajax плохо?
У нас есть интерфейс с вкладками, в одной из этих вкладок форма конфиденциальности. Эта форма конфиденциальности, а также использование внешнего файла JavaScript для объема его работы, также использует встроенный JavaScript, поскольку это в настоящее время полагается на динамический код (на серверном языке).
обертка formTabs (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>
...
представление privacyForm (больше встроенного JavaScript с серверным кодом)
...
<script type = "text/javascript">
var preferencesPrivacyForm = new ProjectName.AJAX.Form({
"ajaxFormID": "preferences-privacy-form",
"actionUrl": '<%= Url.Action("SavePrivacy","Profile") %>',
"dataReturnType":"json"
});
</script>
...
Разработчик бэкэнда: "Код JavaScript конфигурации для этой формы должен остаться в представлении privacyForm"
Разработчик фронтэнда: "Хм, я уверен, что "ve читаю, что это не способ сделать это - ненадежный, весь JavaScript должен быть в странице HTML, которая содержит обертку вкладок в функции обратного вызова той загрузки вкладок. Необходимо действительно a) обеспечить, логика для меня получают те динамические данные в обертке вкладок или b) позволить мне захватить те динамические переменные через обход DOM"
Разработчик бэкэнда: "Оба из этих методов являются большой работой ни для какой реальной платы прочь! Первый пример плох, потому что это означает, что я оказываюсь перед необходимостью изменять путь его созданный (и хорошо работает). Это, вероятно, собирается означать дублирование. Второй пример изворотлив, поскольку разметка могла измениться, таким образом, кто-то работающий над кодом мог бы забыть редактировать пересекающиеся методы DOM в обертке вкладок. Именно другой уровень абстракции нам не нужно. Если Вы предоставляете мне некоторое доказательство о том, почему это действительно действительно плохо, чем я проверю его, но иначе я не могу выровнять по ширине вставление времени"
Разработчик фронтэнда: 'ну, Я уже потратил впустую несколько дней, решение проблем с Ajax загрузило JavaScript путем помещения их в обратные вызовы их оберток, но да теперь Вы думаете об этом, хорошая ссылка на такого рода вещи была бы действительно хороша, потому что Вы правы, в данный момент, приложение работает без любых проблем'.
Это - один из многих примеров всюду по крупному приложению, где мы загружаем встроенный JavaScript Ajax.
Я должен убеждать разработчика бэкенда, что мы должны использовать обратные вызовы, или я пропускаю что-то?
4 ответа
Это не совсем "плохо", если служит определенной цели (например, загружает контент с других веб-сайтов, таких как панель управления WordPress), но все дополнительные вызовы на сервер это пустая трата ресурсов, если только вы не обязаны это делать.
Обычно самый простой ответ - самый правильный. В этом случае это означает, что не нужно добавлять все дополнительные накладные расходы, чтобы избежать небольшого перекодирования серверной части.
Я бы порекомендовал прочитать книгу Дейла Карнеги «Как заводить друзей и оказывать влияние на людей».
Кажется, что разработчики постоянно попадают в такую ситуацию, когда они знают, что лучше всего делать, но не получают поддержки от других разработчиков или руководства.
Эту книгу определенно стоит прочитать; ОБЯЗАТЕЛЬНО читать для этой профессии.
Из примера неясно, зачем вообще нужен AJAX. Почему бы просто не поместить
<script type ="text/javascript">
var userId = "<<<<= userId >>>>"
</script>
непосредственно в HTML-главу? Это быстрее для пользователя, проще для сервера, и вы избежите всяких мучений с таймингом и обработкой ошибок при неудачных запросах.
Это суть спора о том, почему ненавязчивый Javascript (UJS) - это хорошо. Я никогда не понимал его достоинств, потому что не знал, как решать проблемы без встроенного Javascript. В конце концов я узнал.
Прежде всего, UJS хорош тем, что он разделяет ваш внешний код следующим образом:
- HTML - чистый HTML служит для структурирования информации.
- CSS - CSS используется для стилизации и компоновки документа.
- Javascript - Javascript используется для определения поведения вашей страницы.
Чтобы они работали вместе, HTML-файл загружает внешние CSS-файлы для определения стилей и внешние Javascript-файлы для определения поведения. Более того, вам нужны известные символы в вашем HTML (такие как id, имена классов и теги), в вашем CSS (правила id и классов), чтобы ваш 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, это будет стоить вашей команде больше затрат на развитие и поддержку кода. С точки зрения бизнеса, вам будет больно поддерживать и развивать код в его нынешнем виде. С точки зрения бэкэнд-парня, ему будет дороже, если он будет делать что-то другое, чем то, что работает сегодня. Т.е. ваш руководитель команды и архитектор должны сбалансировать различные точки зрения бизнеса, чтобы определить, как структурировать ваш код.