웹 개발에서 UI 레이어의 느슨한 결합

이번에는 웹 개발 시 UI 레이어의 느슨한 결합에 대해 알려드리겠습니다. 웹 개발에서 UI 레이어의 느슨한 결합을 사용할 때의 주의사항은 무엇인가요?

웹 개발에서 UI는 서로 분리되어 상호 작용하는 세 가지 레이어로 정의됩니다.

HTML은 페이지의 데이터와 의미를 정의하는 데 사용됩니다.

CSS는 페이지에 스타일을 추가하고 시각적 기능을 만드는 데 사용됩니다.

JS는 페이지에 동작을 추가하여 페이지를 보다 상호 작용적으로 만드는 데 사용됩니다.

느슨한 결합 정보 , 말도 안되는 문장을 이야기하겠습니다. 다른 구성요소를 변경하지 않고 하나의 구성요소를 수정할 수 있으면 결합이 느슨한 것입니다. 많은 사람이 코드 유지 관리에 참여하는 대규모 다중 사용자 시스템의 경우 느슨한 결합은 코드 유지 관리에 매우 중요합니다. 개발자는 코드의 한 부분을 수정할 때 다른 사람의 코드를 손상시키지 않기를 절대적으로 원합니다. 대규모 시스템의 각 구성요소의 내용이 제한되면 느슨한 결합이 달성됩니다. 기본적으로 각 구성 요소는 느슨한 결합을 보장할 수 있을 만큼 얇게 유지되어야 합니다. 구성 요소에 대해 덜 알려져 있을수록 전체 시스템을 구성하는 것이 더 좋습니다.

한 가지 주의할 점: 함께 작동하는 구성 요소는 "결합 없음"을 달성할 수 없습니다. 모든 시스템에서 구성 요소는 작업을 수행하기 위해 일부 정보를 공유합니다. 우리의 목표는 한 구성 요소의 변경 사항이 다른 부분에 정기적으로 영향을 미치지 않도록 하는 것임을 이해하기 쉽습니다.

웹 UI가 느슨하게 결합되어 있으면 디버깅하기 쉽습니다. 텍스트나 구조와 관련된 문제는 HTML을 검색하여 찾을 수 있습니다. 스타일 관련 문제가 발생하면 문제가 CSS에 있다는 것을 알 수 있습니다. 마지막으로, 이러한 동작 문제의 경우 JS로 직접 이동하여 문제를 찾는 능력은 웹 인터페이스 유지 관리의 핵심 부분입니다.

웹 페이지 시대에는 HTML/CSS/JS의 3계층 분리를 옹호합니다. 예를 들어 57fe4585505b1157c6f3c54be8a13f23test0a1c32121657d03a6a9c1c07e0b00e76 이런 글을 쓰면 비난을 받을 것입니다. 하지만 WebApp 시대에는 React로 대표되는 MVVM과 MVC 프레임워크(엄밀히 말하면 React는 단지 View 레이어에 초점을 맞춘 프레임워크일 뿐입니다)에서는 모두 HTML, CSS, JS를 함께 작성하는 것을 권장하고 있으며, 이벤트 리스너를 인라인으로 바인딩하는 코드입니다.

우리가 거꾸로 가고 있는 걸까? 궁금하지 않을 수 없습니다.

역사는 가끔 돌고돌아 언뜻 보면 돌아가는 줄 알았어요. 사실 나선은 방향을 바꿔 새로운 출발점에 섰다. ——Yu Bo "웹 R&D 모델의 진화"

기존 웹페이지 시대에는 언어 수준과 프레임워크 수준 모두에서 구성 요소화 지원이 높지 않았는데, 기본적으로 지원되지 않았던 JS(ES6 이전 시대)와 jQuery를 생각해 보세요. 지원 모듈이므로 유지 관리 비용 증가를 방지하려면 3층 분리의 모범 사례가 권장됩니다. ES6 및 프런트엔드 MV* 프레임워크의 등장으로 전체 프런트엔드 개발 모델이 변경되었습니다. 프런트엔드는 페이지를 작성하는 것뿐만 아니라 더 많은 WebApp을 작성하는 것이기도 합니다. 애플리케이션의 규모와 복잡성은 웹페이지 시대와 다릅니다.

React는 JSX를 사용하여 페이지 구조와 페이지 로직을 직접 작성하는 매우 대표적인 예입니다. 이것을 웹페이지 시대에 배치했다면 바로 전형적인 안티패턴 교재라고 생각하겠지만, 웹앱 시대에는 대부분의 사람들이 받아들이고 사용하게 된다. React 팀에서 제안한 JS의 CSS를 포함하여 프론트 엔드 개발이 JS에 의해 완전히 지배되고 구성 요소화가 더 철저하도록 JS에서 CSS를 작성하려고 합니다. 프로젝트에 대한 실제 대규모 실무 경험이 없기 때문에 지금은 여전히 ​​관망하는 태도를 유지하고 CSS 개발에 이전 SASS 및 LESS를 계속 사용하고 있습니다.

두 웹 시대의 개발 모델이 극적으로 바뀌었음에도 불구하고 3계층 느슨한 결합 디자인과 관련하여 따라야 할 몇 가지 일반 원칙이 여전히 있습니다.

CSS에서 JS를 추출합니다. 초기 IE8 및 이전 브라우저에서는 CSS로 JS 작성을 허용했습니다(예를 작성하지 않으면 이는 안티 패턴이므로 기억할 수 없으면 더 좋습니다). 이는 성능 문제를 일으킬 수 있으며 더욱 무서운 점은 다음과 같습니다. 앞으로도 유지하기 어려울 거라는 거죠. 하지만 저는 여기 계신 여러분 중 누구도 이런 종류의 코드에 접근할 수 없을 것이라고 믿습니다. 괜찮습니다.

JS에서 CSS를 추출합니다. JS에서 CSS를 수정할 수 없다는 것은 아닙니다. 스타일을 직접 변경할 수 없다는 의미는 아닙니다. 대신 클래스를 수정하여 간접적으로 스타일을 수정할 수 있습니다. 다음 예를 참조하세요.

// 不好的写法element.style.color = 'red';
element.style.left = '10px';
element.style.top = '100px';
element.style.visibility = 'visible';// 好的写法.reveal {  color: red;
  left: 10px;
  top: 100px;
  visibility: visible;
}
element.classList.add('.reveal');

CSS className은 CSS와 JS 간의 통신 브리지가 될 수 있기 때문입니다. 페이지의 라이프 사이클 동안 JS는 요소의 className을 마음대로 추가하고 삭제할 수 있습니다. className으로 정의된 스타일은 CSS 코드에 있습니다. 언제든지 JS를 업데이트하지 않고도 CSS의 스타일을 수정할 수 있습니다. JS는 CSS와의 느슨한 결합을 유지하기 위해 스타일을 직접 조작해서는 안 됩니다.

style 속성을 사용하는 것이 허용되는 한 가지 상황이 있습니다. 즉, 다른 요소나 전체 페이지를 기준으로 위치를 변경할 수 있도록 페이지에서 요소의 위치를 ​​조정해야 하는 경우입니다. CSS에서는 이 계산을 수행할 수 없으므로 style.top, style.left, style.bottom 및 style.rght를 사용하여 요소를 올바르게 배치할 수 있습니다. CSS에서 이 요소의 기본 속성을 정의하고 Javascript에서 이러한 기본값을 수정하세요.

프론트엔드가 HTML과 JS를 함께 작성하고 있는 현 상황을 고려하여, 원서에서 둘을 분리하는 관행에 대해서는 언급하지 않겠습니다. 그러나 이 모든 말도 안되는 말을 했음에도 불구하고 다음을 기억하십시오. 예측 가능성은 테스트 및 개발 속도를 높이고 버그 디버깅을 시작할 위치를 (추측보다는) 알면 문제 해결 속도가 빨라지고 코드의 전반적인 품질이 높아집니다.

이 기사의 사례를 읽은 후 방법을 마스터했다고 생각합니다. 더 흥미로운 정보를 보려면 PHP 중국어 웹사이트의 다른 관련 기사를 주목하세요!

추천 도서:

JS를 사용하여 참조로 전달하고 값으로 전달하는 방법

node.js 인터페이스를 만드는 방법

위 내용은 웹 개발에서 UI 레이어의 느슨한 결합의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!