최근에 잘 알려진 팟캐스트를 듣고 있는데 멋진 호스트들이 웹 구성 요소에 대해 이야기하면서 다양한 웹 구성 요소 사양과 기능에 대한 좋은 점, 나쁜 점, 아쉬운 부분을 모두 나열하고 있었습니다.
완전히 공정한 에피소드와 훌륭한 대화를 해주신 Chris Coyier와 Dave Rupert에게 감사 인사를 전합니다. 여기에서 에피소드를 들어보세요:
샵 토크쇼
누구든지 그 에피소드 깊숙한 곳에서 CSS Parts가 악당 목록에 올랐다는 사실에 놀랐습니다. 하지만 사람들이 CSS Parts가 최고가 아니라고 생각하는 이유를 몇 가지 알 수 있었습니다. 나는 CSS 부분이 꽤 좋을 뿐만 아니라 웹 구성 요소 섀도우 루트 내부의 모든 단일 요소의 스타일을 정확하게 지정할 수 없는 것보다 훨씬 더 짜증나고 실망스러운 시나리오에서 실제로 CSS 부분을 사용하는 우리 모두를 구하고 있다고 생각합니다. 원합니다.
설명하자면, 먼저 더 많은 맥락을 알아보세요!
다음 내용이 모두 사실인지 명시적으로 확인할 수는 없지만 지난 몇 년간 본업에서 사양 웹 구성 요소 기능을 작성하고 사용하고 도움을 주면서 얻은 개인적인 의견은 기존 웹 구성 요소 사양 및 기능이 모두 "타사 구성 요소" 사용 사례를 해결하도록 설계되었습니다. 즉, 웹 구성 요소는 매우 특정한 상황을 지원하도록 설계되었습니다. 다른 소비자가 인터넷에서 다운로드하여 자신의 앱에서 사용할 수 있는 도구를 만드는 구성 요소 작성자.
"타사 구성 요소" 사용 사례의 렌즈를 통해 웹 구성 요소 기능을 살펴보면 사양 작성자와 브라우저 구현자가 취한 많은 접근 방식이 매우 의미가 있다고 생각합니다. 예를 들어 Shadow DOM 스타일 캡슐화의 심각성을 생각해 보세요. 인터넷에서 앱으로 구성 요소를 가져오는 경우 해당 구성 요소의 CSS가 페이지 중 하나를 손상시킬까 봐 걱정할 필요가 없다는 것이 멋지지 않습니까? 작성하지 않은 구성 요소의 내부 구조에 대해 걱정할 필요가 없고 해당 구성 요소를 블랙 박스처럼 처리하고 잘 정의된 API 표면을 통해 상호 작용할 수 있다는 것이 멋지지 않나요?
웹 구성 요소의 작동 방식을 이해하는 데 있어 가장 큰 문제는 웹 구성 요소 사양이 만들어진 이후 업계가 발전해 왔으며 요즘 앱에서 사용하는 구성 요소의 99%가 외부 소스에서 나오지 않는다는 것입니다. . 요즘 우리는 컴포넌트에 대해 생각할 때 대부분 인터넷상의 누군가가 작성한 것이 아니라 우리나 우리 팀이 작성한 "자사 컴포넌트"를 생각합니다. 우리는 애플리케이션에서 외부 구성 요소를 그다지 많이 사용하지 않기 때문에 주로 해당 사용 사례에 맞게 설계된 웹 구성 요소 API가 이상하게 보입니다. 특히 웹 구성 요소를 사용하여 자체 구성 요소를 만들려고 할 때 더욱 그렇습니다.
따라서 이 기사에서 내가 말하려는 다른 모든 내용은 "타사 구성 요소" 상황을 언급한다고 가정합니다. 내가 말하는 구성 요소가 다운로드한 npm 패키지이고 GitHub 추가 정보와 패치 노트 등이 있지만 귀하(또는 귀하의 팀)가 자신의 앱을 위해 직접 작성하지 않았다고 상상해 보세요.
CSS 파트는 자신이나 팀을 위해 작성하고 완전히 제어할 수 있는 스타일링 구성 요소를 위한 훌륭한 인터페이스가 아닙니다.
잘 설계된 구성 요소에는 상호 작용하는 여러 가지 방법이 있습니다. 훌륭한 웹 구성 요소에는 사용자 정의된 HTML을 위한 슬롯, 사용자 정의된 테마를 위한 CSS 사용자 정의 속성, 사용자 정의된 스타일을 위한 CSS 파트가 있습니다. Shop Talk Show 친구들은 자유 형식 스타일링에 투박하다는 맥락에서 CSS 부품에 대해 논의했지만 저는 CSS 부품에 대해 그런 식으로 생각하지 않을 것입니다. 나는 그것들을 속성이나 속성과 거의 같은 방식으로 구성 요소에 대한 또 다른 공개 API 표면으로 생각합니다. 사람들은 일반적으로 인터넷에서 가져온 구성 요소에 대한 사용자 정의 속성이나 속성을 만들 수 없는 것에 대해 크게 걱정하지 않습니다. CSS Parts도 같은 생각이라고 생각합니다. 구성 요소 작성자는 원하는 방식으로 "스타일 지정"이 가능한 내부 템플릿 조각을 지정합니다. 따라서 Shadow dom 웹 구성 요소의 모든 단일 내부 요소에 스타일을 지정할 수 있다는 것이 반드시 기대되는 것은 아닙니다.
복잡한 템플릿의 어느 부분에 어떤 스타일을 적용해도 괜찮은지 구성요소 작성자보다 더 잘 아는 사람이 있을까요? 모든 스타일을 바꾸고 다시 작성하기 위해 인터넷에서 구성 요소를 가져와서 그 과정에서 접근성 등을 파괴할 수 있다면 애초에 구성 요소를 설치한 이유는 무엇입니까? 저는 많은 사람들이 옹호해 온 섀도우 루트에 대한 "내가 무엇을 하는지 알고 있습니다" 선택기의 매력을 이해합니다. 하지만 다음 섹션에서는 정의된 스타일링 API 표면이 있다고 생각하는 이유를 설명하겠습니다. 내부 DOM 구조와의 연결이 끊어진 것은 실제로 놀라운 일이며 우리 모두가 정신을 차리지 않도록 도와준 것에 대해 축하해야 합니다.
옛날 영화 예고편 음성
CSS 파트가 존재하지 않고 "내가 무엇을 하고 있는지 알고 있습니다" 선택기(그리움을 표현하기 위해 /deep/이라고 부르겠습니다)가 존재하고 "방법"인 상상의 세계로 뛰어들어 보겠습니다. 일부 섀도우 루트 웹 구성 요소의 내부 DOM 템플릿 스타일을 지정해야 합니다.
앱에 이러한 구성 요소가 하나 필요하므로 npm 패키지를 다운로드하세요
npm i some-awesome-package@1.2.3
응용프로그램에 다음 HTML이 있어야 합니다.
<some-awesome-component></some-awesome-component>
Some Awesome Component 구성 요소에는 기본적으로 빨간색이고 CSS 사용자 정의 속성을 사용하지 않는 div가 있습니다. 그리고 처음에는 빨간색 div도 완전 괜찮습니다!
그런데 빨간색 div의 색상을 rebeccapurple로 변경해야 한다고 결정했습니다. 그래서 다음 CSS를 작성합니다:
@layer my-overides {
some-awesome-component /deep/ div.the-red-div {
background: rebeccapurple;
}
}
the-red-div는 클래스에 대한 끔찍한 이름이지만, 아무도 Shadow dom 웹 구성 요소의 내부 구조에 관심이 없습니다. 그렇죠? 외부 세계와 충돌할 수 없으므로 구성 요소 작성자는 원할 경우 끔찍한 클래스 이름을 쓸 수 있습니다.
그리고 우리는 /deep/이 존재하는 상상의 세계에 있기 때문에 모든 것이 작동합니다! 빨간색 div는 이제 보라색이고 모든 것이 멋집니다.
당신은 .the-red-div의 색상이 빨간색이 아니라는 우리 두뇌의 작은 인지 부조화를 무시합니다. 그건 내일 문제다.
달콤해요!
그런 다음 구성 요소 작성자는 기능을 추가하고 패치 범프를 게시합니다.
배송으로 바쁜 중에 관련 없는 패키지를 다시 설치하고 Some Awesome Component의 최신 패치 범프를 가져왔고 빨간색 div가 다시 돌아왔습니다!
무엇을 제공하나요? 패치 노트를 검색하면 다음을 찾을 수 있습니다.
## 1.2.4 - [a987s83] Added cool button, fixed a11y issues
괜찮은 것 같은데 왜 CSS가 깨졌나요? 변경 로그 메모에는 단서가 없습니다. 따라서 최신 PR 몇 개를 훑어봐도 눈에 띄는 내용은 없습니다.
그래서 애플리케이션을 실행하고 섀도우 루트를 확인하면 빨간색 div가 지금! 그리고 구성 요소 작성자는 클래스 이름인 the-red-div가 좀 더 일반적이어야 한다는 것을 깨닫고 Colourful로 변경했습니다.
좋아요. CSS를 다음과 같이 편집하세요.
@layer my-overides {
some-awesome-component /deep/ .colorful {
background: rebeccapurple;
}
}
그리고 다시 잘 작동합니다!
그럼 작가님은 다음주에 또 다른 패치 범프를 공개합니다.
현실세계로 점프컷
패턴을 확인하면 소유하거나 제어하지 않는 내부 템플릿에 대한 직접 선택기 액세스에 문제가 있습니까?
구성요소 소비자인 귀하의 제어 범위를 벗어나 내부 템플릿이 필연적으로 변경됩니다. 그리고 필연적으로 이러한 변경은 수동으로 또는 불안정한 시각적 회귀 테스트 도구를 사용하여 실행 중인 앱의 모든 단일 부분을 시각적으로 검사하지 않고도 거의 눈에 띄지 않는 방식으로 발생합니다. 인터넷의 구성 요소를 사용하는 경우 일종의 계약이 있습니다. 구성 요소 작성자는 Shadow DOM을 소유하고 소비자는 :host 요소(작성한 코드의
재미있는 사실은 이러한 취약성은 JS의 DOM 요소에 대해 직접 Shadow DOM querySelector를 수행할 때도 발생합니다. 앱이 항상 존재하기 위해 일부 요소에 의존하는 경우에는 그렇지 않습니다. 제어할 수 없는 DOM에 쿼리하면 어느 날 일부 요소가 존재하지 않게 됩니다. 다른 요소이거나 다른 클래스/속성/ID를 갖습니다.
CSS 부분은 DOM 요소 자체가 아닌 단순한 문자열이기 때문에 이를 사용하면 깨지기 쉬운 코드로부터 애플리케이션을 보호할 수 있습니다. 제3자 작성자는 일부 div가 영원히 div인지 테스트하지 않습니다. 그러나 CSS 부분을 생성하면 획기적인 변경 없이는 제거하거나 변경할 수 없는 구성 요소에 대한 공개 API를 생성한다는 것을 알 수 있습니다. Shadow DOM을 직접 쿼리하는 대신 CSS 부분을 사용하면 구성 요소 작성자가 해당 CSS 부분을 Shadow DOM에서 이동할 수 있으며 애플리케이션 코드는 중단되지 않습니다.
또한 CSS 부분 이름은 관계, 개념 및 기능을 암시하기 때문에 구성 요소 작성자가 CSS 부분의 의미를 실질적으로 변경하는 방식으로 구성 요소를 리팩터링하기가 어렵습니다. 따라서 구성 요소 작성자가 사용자에게 알리지 않고 변경하더라도 코드를 사용하는 CSS 부분이 중단되지 않을 것이라는 점을 아는 것 외에도 CSS 부분이 전체 부분과 관련하여 항상 같은 종류가 될 것임을 합리적으로 확신할 수 있습니다. 요소. 따라서 해당 부품에 적용하는 스타일은 구성 요소가 시간이 지남에 따라 발전하더라도 항상 해당 부품에 대해 "합리적"일 것입니다.
CSS 파트의 어려움과 선택기를 통해 직접적인 Shadow DOM 액세스를 추가하는 것이 훨씬 더 편리할 것이라는 매우 똑똑하고 귀중한 업계 사람들의 의견을 몇 가지 보았습니다. 시간이 지나도 모든 모양이 바뀌지 않는다면 나는 진심으로 동의할 것입니다. 그러나 구성 요소는 시간이 지남에 따라 변경되므로 어떤 CSS 부분을 사용할 수 있는지 기억하는 것보다 직접 Shadow DOM에 액세스하는 것이 더 고통스러울 것이라고 감히 생각합니다.
"앱"과 구성 요소 내부의 섀도우 돔 사이의 경계를 넘나드는 방법에 대한 논의가 있을 때마다 저는 항상 직접 선택기 액세스보다는 CSS 파트와 같은 명명된 구조적 계약 접근 방식을 옹호했습니다. 내 생각에는 CSS 부분이 투박하고 형편없다고 생각하는 사람은 자신도 모르게 섀도우 루트 템플릿이 변경된 모든 위치를 찾기 위해 앱 전체를 뒤질 필요가 없었을 것입니다. :)
CSS 부품은 훌륭하며 이를 사용할 때 100% 훌륭한 개발자이고 자신이 무엇을 하고 있는지 알고 있더라도 잠재적으로 모든 맞춤 CSS를 조정해야 하는 고통을 100% 원하지 않습니다. 당신은 당신이 사용하는 구성요소에 패치 범프가 있을 때마다 글을 썼습니다. 여러분은 자신이 무엇을 하고 있는지 확실히 알고 있지만 우리 모두는 앱이 무작위로 중단되는 것을 방지하기를 원하며 이것이 바로 직접적인 Shadow DOM 스타일링이 수행하는 작업입니다. "내가 뭘 하고 있는지 알아요" 선택기를 사용하면 스타일이 제대로 작동하게 되지만, 스타일을 지정한 패키지 버전을 문자 그대로 업데이트하지 않는 경우에만 보장됩니다. 버전을 업데이트한다면 매번 "내가 뭘 하고 있는지 알아요" 스타일을 모두 주시해야 합니다.
아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아. CSS 파트를 사용하고 구성요소 개발자가 작성한 구성요소에 이를 추가하도록 권장하세요.
위 내용은 CSS Parts가 당신을 악몽에서 구해줄 것입니다의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
