Какие-либо проблемы/недостатки, размещающие jQuery в Google?
+ имеет специальное значение в регулярное выражение и не может использоваться в форме ++. Вам нужно выйти из регулярного выражения.
Используя эту функцию source sup>:
function escapeRegExp(string) {
return string.replace(/[.*+?^${}()|[\]\\]/g, '\\[110]amp;'); // [110]amp; means the whole matched string
}
вы можете заменить:
var regexEx = new RegExp(req.query.search, "i"); //ignore case
на
var regexEx = new RegExp(escapeRegExp(req.query.search), "i"); //ignore case
^^^^^^^^^^^^
Вы можете легко повторить ошибку, создав простое регулярное выражение: /c++/ в консоли браузера, которое выдаст следующее сообщение (может варьироваться в зависимости от браузера):
SyntaxError: nothing повторить
blockquote>Примечание : это довольно плохая идея, чтобы позволить пользователю искать необработанный ввод.
8 ответов
Одна проблема состоит в том, что сервер Google может и действительно понижаться в худшие времена. В моем ответе на вопрос, "Каков был Ваш самый неудобный опыт программирования?", ответил я:
Я демонстрировал новое веб-приложение своей команды группе потенциальных пользователей. Я занял несколько минут для разговора обо всем интересном материале, который может сделать Google Visualization API, так как мы использовали его в большой степени в нашем приложении. Для демонстрации я решил изобразить несколько наборов в виде графика данных, которые мы собрали ранее. Это было предназначено для передачи сообщения: "Посмотрите, насколько легкий это! Обычные люди могут сделать красивые графики с помощью нашего продукта".
По стечению обстоятельств серверы Google, которые разместили файлы JavaScript, необходимые для использования Визуализации API, решили прекратить работать на полпути во время моей презентации. Я председательствовал, уставившись на экран, бормоча мне, "но... но они - Google..., их серверы не могут понизиться". Команда пыталась отмахнуться смеясь от него, но все поняли в тот момент, насколько опасный это может быть должно полагаться на любое третье лицо (даже один столь же большой как Google), когда это действительно рассчитывает.
Я знаю, что это кажется маловероятным, но если у Вас действительно нет никакого другого выбора, я рекомендовал бы против хостинга критических файлов на сторонних серверах, даже если они - серверы Google. Имеющие клиенты жалуются на отключение электричества, плохо. Имеющие клиенты жалуются на отключение электричества, которое не является Вашим отказом и что Вы не можете решить, еще хуже.
Я не знаю, но мне нравится брать на себя управление самому :), я всегда загружаю js на веб-сервер
Одним огромным преимуществом является офлайновое использование. Я пишу изрядный объем кода на поезде без мобильных данных - также - js в моем веб-проекте очень полезен. Это также позволяет мне иметь полный контроль и уверенность по управлению изменениями.
Только недавно запустив использование jQuery и только использование локальной копии, я не могу прокомментировать проблему перекрестного сайта.
Так как Ваш заголовок вопроса спрашивает, существуют ли какие-либо недостатки к хостингу этого в Google, самый очевидный ответ, который приходит на ум, они могут обновить свою версию в любое время, потенциально взломав Ваш код или вызвав неожиданные побочные эффекты. ОБНОВЛЕНИЕ: Guillaume прокомментировал, что Вы всегда связываетесь с определенной версией jQuery, когда Вы размещаете. Я не знал это - спасибо.
И наконец, если Вы находитесь в стране, где международные интернет-ссылки иногда отбрасывают, или Вы разрабатываете интранет и интернет-сбросы канала, можно найти локальных пользователей, имеющих ошибки, потому что они не могут добраться до Google.
Самые тяжелые пользователи Вашего сайта являются обычно повторными посетителями, и у них будут Ваши локально размещенные .js файлы кэшируемыми так или иначе, таким образом, они только получат тот удар пропускной способности в первый раз, когда они посещают сайт.
- Посетители моего сайта, обычно повторяют посетителей? (В противоположность новым посетителям)
- У посетителей моего сайта, вероятно, будут быстрые сетевые соединения?
- Я удобно в выделенной способности пропускной способности моего сайта?
Каждый "да" ответ является причиной постараться не полагаться на внешне размещенный JavaScript в Google.
Например: если Вы выполняете сайт как StackOverflow, где Ваши посетители являются обычно технически подкованными людьми с быстрыми соединениями и кэшами, которые полностью заполняются с пятидесяти других раз, они проверили StackOverflow этим утром, усиления от хостинга Вашего JavaScript в другом месте будут довольно минимальными.
Но если Вы выполните сайт для пенсионеров в Куала Lumpor прочь абонентской линии DSL на 256 Кбит/с в Вашем подвале, то Ваши посетители будут видеть некоторые хорошие усиления, если Вы разгрузите те файлы JS к Google!
Существует много недостатков к наличию хоста Google Ваш jQuery. Как другие пользователи указали:
- Google мог обновить их копию
- Google мог понизиться
- Конечные пользователи не могут достигать Google
Лучший способ ответить на это может состоять в том, чтобы спросить: Что ПРЕИМУЩЕСТВАМИ является к наличию хоста Google Ваш jQuery? Только в конкретных случаях был бы я использовать хостинг перекрестного сайта для зависимостей. А именно:
- Google, вероятно, имеет серверы ближе, чем Ваш Вашему конечному пользователю
- Пользователям, более вероятно, будут кэшировать версию Google локально, чем Ваша (если они не будут регулярно посещать),
Я предполагаю путем хостинга в Google, Вы имеете в виду Библиотеки Ajax API? Преимущества, которые я вижу:
- Вы сохраните пропускную способность на своем сайте, так как JS прибывает из CDN Google
- Можно видеть лучшую скорость отклика и скорость, так как содержание прибывает из Google, распределил CDN, вместо серверов.
- Если пользователи ранее посетили другой сайт, который использует Google для хостинга его библиотек JS, браузеру пользователя можно было уже кэшировать их.
- Google применяет последние исправления ошибок и патчи безопасности для версии библиотеки, которую Вы выполняете. Вопреки тому, чего требовали другие, они автоматически не обновляют Вас до последней версии. Например, если Вы укажете желание Mootools 1.11 то Вам не дадут 1.2 или никакая более поздняя версия, если Вы конкретно не изменитесь, Ваш сценарий включают вызов для запроса этого. Но они будут применяться, фиксирует характерный для той версии.
И недостатки:
- Как Вы упоминание, некоторые более рьяные средства обеспечения безопасности и продукты могут не согласиться с включением сценариев от другого хоста. Я не знаю, насколько широко распространенный проблема это, но это стоит расследования.
- Это потенциально добавляет другой поиск DNS к загрузке страницы.
- Google передал для хостинга каждой версии библиотек "неограниченно долго", и Вы надеялись бы, что они имеют в виду это. Но изменение состояний и политик, и если услуга хостинга прекращена, Вы могли бы иметь необходимость, чтобы повторно посетить много сайтов для фиксации их JS.
- Вы уверены в третьем лице для хостинга части содержания. Очевидно, Вы ожидали бы, что времена работы Google будут довольно хороши, но если у них действительно есть проблемы, Вам, возможно, придется объяснить Вашему клиенту, почему их сайт не работает просто, потому что Google имеет сетевые проблемы.
- Google размещает полную версию каждой библиотеки, но некоторым нравится Mootools, которому позволяют Вы создать пользовательские версии, содержащие просто компоненты, в которых Вы нуждаетесь. Таким образом, версия Google могла бы быть большим количеством полного жира, чем Вам нужно.
- У Вас не было способности настроить или изменить библиотеку. Внесение нисходящих изменений в библиотеку является волосатым суждением, но если Вы находитесь в заторе, это могла бы быть самая легкая опция. Хостинг библиотеки внешне добавляет дополнительную сложность, поскольку необходимо будет переключиться на внутреннюю копию.
- Исправления ошибок действительно становятся использованными Ваша выбранная версия, поэтому если Вы так или иначе зависите от ошибочного поведения, это может вызвать проблемы. По-видимому, авторы библиотеки будут очень осторожны относительно потенциальных изменений повреждения, но это - закон Murphy's, что проблемы возникнут где-нибудь.
Все эти комментарии о пропускной способности, и никто даже не трогает кеширование. Если при размещении веб-сайта вы НЕ сообщаете конечным пользователям о необходимости кэширования файлов и о том, как долго их хранить, вы просите чрезмерного использования полосы пропускания и проблем, которые вызывают.
Мой ответ прост. Разместите его самостоятельно, зарегистрируйте в исходном репозитории и правильно обслужите с очень длинными заголовками истечения срока действия. Таким образом, каждый загружает материал ОДИН РАЗ. Кроме того, я действительно не могу смириться с мыслью о том, что на самом деле я не ВЛАДАЮ каждым файлом, который мой сервер отправляет по сети или приказывает клиенту загрузить.