자바 스크립트, HTML 및 CSS 간의 긴밀한 결합 :보다 현대적인 접근 방식?

Javascript가 특정 선택기에 바인딩되어 요소를 찾고 데이터를 저장하며 이벤트를 수신하는 것이 일반적입니다. 스타일링에 이와 동일한 선택기가 사용되는 것도 일반적입니다.

jQuery (및 선택기 엔진 Sizzle)는 CSS 유형 구문으로 요소를 참조하여이를 지원하고 승격시킵니다. 따라서이 기술은 프로젝트를 구축 할 때 '학습'(또는 리팩토링)하기가 특히 어렵습니다.

나는 이것이 HTML 및 Javascript 개발의 역사의 결과이며 브라우저가 이러한 종류의 커플 링을 효율적으로 소비 / 구문 분석 / 렌더링하도록 구축되었다는 것을 이해했습니다. 그러나 웹 사이트가 점점 복잡 해짐에 따라 이러한 현실은 이러한 개별 계층을 구성하고 유지 관리하는 데 어려움을 초래할 수 있습니다.

내 질문은 : 현대 웹 사이트에서 이것을 피할 수 있습니까?

프론트 엔드 개발에 익숙하지 않고 '올바른 방법'을 배우고 싶다면 처음부터 그러한 의존성을 분리하고 피하는 것이 좋습니다. 이것은 더 분리 된 구조를 장려하는 라이브러리를 선호하여 jQuery를 피하는 것을 의미합니까?

그것을 피할 방법이 없습니다. 그들은 서로 상호 작용하기 때문에 연결됩니다. 자바 스크립트가 어떤 종류의 DOM 조작을하려는 경우 DOM을 참조 할 방법이 필요합니다.

그것에 대한 다양한 규칙이 있습니다.

레벨 2 DOM API는 getElementById, getElementByTagName 및 getElementsByName 메소드를 제공합니다. 오늘날까지 이것들은 모든 종류의 DOM 순회 작업의 핵심입니다. 다른 모든 더 멋진 jQuery 선택기는 이러한 조합을 결정하거나 각 DOM 노드를 순회합니다 (이것은 getByClassName을 수행하는 방법이었습니다).

다른 바로 가기가 없습니다. 자바 스크립트는 무엇을하고 어디에서해야하는지 알아야합니다. 일반적으로 요소에 스크립팅에만 관련된 id 또는 클래스가있는 경우 많은 사람들이 접두사 js-또는 다른 명백한 플래그를 접두어로 사용합니다 .

또 다른 최신 규칙은 데이터 속성 선택입니다.

<ul data-myapp-sortable="true">

jQuery('[data-myapp-sortable]').makeSortable();

데이터 속성은 일반적으로 스크립팅 목적으로 사용되며이를 사용하여 선택하는 것이 합리적입니다. 단점은 getElementById ()를 사용하는 것보다 느리다는 것입니다.

또 다른 방법은 angularJS에서 사용하는 방법으로 뷰 모델을 만듭니다. 이 규칙에서 모든 종류의 스크립팅 기능은 특별히 지정된 속성 등으로 지정됩니다 ng-disabled ng-href. 자바 스크립트에 선택기를 추가하지 않습니다. HTML 문서는 스크립팅 된 내용과 방법에 대한 주요 권한이되며 Javascript는 추상적으로 작동합니다. 좋은 접근 방법이지만 이전 방법보다 학습 곡선이 더 높습니다. 그리고 다시 성능을 고려해야합니다.

그러나 대화 형 HTML과 자바 스크립트를 작성할 수 있다고 생각하지 마십시오. 어쨌든 두 부분 모두 상대방에 대해 알지 못합니다. 참조를 종속성으로 제한하는 방법에 대해 자세히 설명합니다.

당신이 얻는 상호 작용을 기꺼이 포기하고 싶다면 Javascript를 완전히 피할 수 있습니다. ASP.NET MVC와 같은 프레임 워크는 HTML, CSS 및 SUBMIT 단추 만 포함 된 페이지를 제공하는 데 매우 적합합니다.

승인. 어쩌면 그것은 약간 극단적 일 수 있습니다.

웹 애플리케이션의 디커플링은 이미 여러 수준에서 발생합니다. REST 애플리케이션을 사용하면 URL과 연관된 "웹 자원"의 관점에서 애플리케이션을 정의 할 수 있습니다. 뷰 모델을 사용하면 도메인 모델과 분리 된 UI에 데이터를 표시 할 수 있지만 데이터를 올바르게 표시해야하는 모양이 있습니다. 서비스 계층을 통해 한 UI를 다른 UI로 교체 할 수 있습니다.

역사적으로, 상호 작용 성과 커플 링 사이에는 항상 상충 관계가있었습니다. 웹 페이지가 대화 형 일수록 웹 애플리케이션과 더 밀접하게 연결됩니다. 그러나 웹 페이지의 상호 작용 논리는 웹 페이지 자체에 국한됩니다. 서버와의 연결은 POST 또는 AJAX를 통해 발생합니다. 따라서 브라우저와 서버간에 데이터 패킷이 전달되는 방식에주의를 기울이는 것 외에 Javascript 수준의 커플 링에 지나치게 신경 써야한다고 확신하지 않습니다.

가장 "현대적인"접근 방식 (즉, 금주의 특징)은 아마도 SPA 응용 프로그램 일 것입니다 .

Martin Fowler는 이에 대한 한 가지 접근 방식을 Segregated DOM 으로 설명 합니다 . 여기서 DOM JavaScript를 페이지 로직 JavaScript와 분리합니다.

Application Logic <----> DOM Manipulation <----> DOM / HTML

아니요, 클래스, 요소 및 ID 선택기를 클라이언트 측에서 사용하지 않아야합니다. CSS 선택기는 매우 성숙하고 잘 정립 된 도메인 언어이기 때문에이 구문이 사용됩니다. 공통 디자인을 사용하면 프로그램과 디자인간에 페이지의 공통 논리 모델을 훨씬 쉽게 공유 할 수 있습니다. 이는 매우 좋은 일입니다.

이 구문을 잘못 사용하고 끔찍하고 유지 관리 할 수없는 응용 프로그램을 만들 수는 있지만 언어 나 도구 집합에 관계없이 가능합니다.

누군가는 dom에 대한 간접 및 캐시 계층을위한 jQuery 경로 관리자 인터페이스를 구축해야합니다.

pathMgr.register(name,selector [,isDynamic=false]);
pathMgr.get(name [,refresh]);

그때,

String.prototype.reg([isDynamic=false]);
String.prototype.get(name [,refresh]);

그래서,

// at init....
var pathMgr=new PathMgr();
'sidebar-links #sidebar a'.reg();// new registery of selector '#sidebar a' under name 'sidebar-links'
// more, more


// in code
'sidebar-links'.get().css(etc...);
//or
'sidebar-links'.addStyleRule({});