Очень часто Javascript привязывают к определенным селекторам, чтобы находить элементы, хранить данные и прослушивать события. Также распространено видеть те же самые селекторы, используемые для стиля.
jQuery (и его механизм выбора Sizzle) поддерживают и продвигают это, ссылаясь на элементы с синтаксисом CSS-типа. Таким образом, эту технику особенно трудно «отучить» (или изменить) при создании проектов.
Я понял, что это результат истории разработки HTML и Javascript, и что браузеры были созданы для эффективного использования / разбора / и рендеринга такого рода связи. Но поскольку веб-сайты становятся все более сложными, эта реальность может создать трудности при организации и поддержании этих отдельных слоев.
Мой вопрос: можно ли этого избежать на современных веб-сайтах?
Если я новичок в разработке front-end и хочу изучать вещи «правильным образом», стоит ли учиться отделять и избегать таких зависимостей с самого начала? Означает ли это, что нужно избегать jQuery в пользу библиотеки, которая продвигает более разделенную структуру?
источник
Ответы:
Нет способа избежать этого. Они связаны, потому что они взаимодействуют друг с другом. Если ваш javascript намеревается выполнять какие-либо манипуляции с DOM, ему нужен способ ссылки на DOM.
Есть различные соглашения для этого.
DOM API уровня 2 предоставляет методы getElementById, getElementByTagName и getElementsByName. По сей день это рабочие лошадки любого вида обхода DOM. Все другие причудливые селекторы jQuery в конечном итоге преобразуются в их комбинацию и / или прямой обход каждого узла DOM (это был способ сделать getByClassName).
Там нет другого ярлыка. Javascript должен знать, что делать и где. Как правило, если элемент имеет идентификатор или класс, который имеет отношение только к сценариям, многие люди ставят перед ним префикс
js-
или какой-либо другой очевидный флаг.Другое более новое соглашение - выбор атрибута данных.
Атрибут data, как правило, используется в целях написания сценариев, и его выбор имеет смысл. Недостаток в том, что это медленнее, чем при использовании getElementById ().
Другой подход - тот, который используется angularJS, который создает модель представления. В этом соглашении любой вид скриптовых функций определяется специально назначенными атрибутами, такими как
ng-disabled
ng-href
и многие другие. Вы не добавляете селекторы в свой JavaScript. HTML-документ становится основным источником информации о том, что и как пишется в сценарии, а javascript работает над ним абстрактно. Это хороший подход, но, очевидно, с более высокой кривой обучения, чем предыдущие методы. И снова, производительность должна быть рассмотрена.Но никогда не думайте, что вы можете написать интерактивный HTML и javascript, и каким-то образом обе эти части не знают друг о друге. Это больше о том, как вы можете ограничить ссылки на зависимости.
источник
Если вы хотите отказаться от интерактивности, которую вы получаете, вы можете полностью избежать Javascript. Фреймворки, такие как ASP.NET MVC, очень хороши в обслуживании страниц, которые содержат только HTML, CSS и кнопку SUBMIT.
ХОРОШО. Может быть, это немного экстрим.
Разделение в веб-приложении уже происходит на многих уровнях. Приложения REST позволяют определять ваше приложение в терминах «веб-ресурсов», связанных с URL-адресом. Модели представления позволяют вам представлять данные в пользовательском интерфейсе, который отделен от модели предметной области, но имеет форму, необходимую для правильного отображения. Уровни обслуживания позволяют менять один пользовательский интерфейс на другой и т. Д.
Исторически всегда существовал компромисс между интерактивностью и взаимодействием. Чем более интерактивна ваша веб-страница, тем более тесно она связана с приложением. Но логика интерактивности на веб-странице ограничена самой веб-страницей; любая связь с сервером происходит через POST или AJAX. Поэтому я не уверен, что вы должны быть чрезмерно обеспокоены связью на уровне Javascript, кроме как обращать внимание на то, как пакеты данных передаются между браузером и сервером.
Наиболее «современный» подход (т. Е. Аромат недели) - это, вероятно, SPA-приложения .
источник
Мартин Фаулер описывает один из подходов к этому как Segregated DOM , где вы отделяете свой DOM JavaScript от логики страницы JavaScript.
источник
Нет, не следует избегать использования селекторов классов, элементов и идентификаторов на стороне клиента. Синтаксис используется потому, что CSS-селекторы являются очень зрелым и хорошо зарекомендовавшим себя предметным языком, а наличие общего дизайна значительно упрощает совместное использование общей логической модели страницы между программой и дизайном, что очень и очень хорошо.
Хотя можно неправильно использовать этот синтаксис и создать ужасное и не поддерживаемое приложение, это возможно независимо от вашего языка или набора инструментов.
источник
[data-*]
селекторов атрибутов, которые можно использовать очень мощными способами.Кто-то должен создать интерфейс менеджера путей jQuery для уровня косвенности и кеша в dom.
Затем,
Так,
источник