웹 구성 요소 라이브러리에 약간

최근 웹 구성 요소에 대한 많은 소식이 있었으며 여기에서 분류하겠습니다.

웹 구성 요소에 가장 적합한 응용 프로그램 시나리오 중 하나는 패턴 라이브러리라고 생각합니다. 부트 스트랩처럼 사용하는 대신<div> 또는 Bulma처럼 사용하십시오<code><div> , 예를 들어 사용자 정의 요소를 사용하는 것이 좋습니다.<code><designsystem-tabs></designsystem-tabs> . 새로운 Shoelace 라이브러리는 sl 네임 스페이스를 사용하여 구성 요소를 정의합니다. 태그가있는 웹 구성 요소를 기반으로하는 스키마 라이브러리입니다.<sl-tab-group></sl-tab-group> 요소.

이 작업의 이점은 무엇입니까? 먼저 구성 요소 모델을 소개합니다. 즉, 구성 요소에서 작업하는 경우 위치와 관련된 템플릿과 스타일 시트가 있음을 의미합니다. Shoelace의 내부 구현을 살펴보면 모든 것이 스텐실을 기반으로한다는 것을 알 수 있습니다.

또 다른 이점은 구성 요소가 그림자 dom을 사용할 수 있고 사용하는 것입니다. 이것은 웹 플랫폼에서 직접 격리 메커니즘을 제공합니다. 미국 CSS 개발자에게는 태그 구성 요소의 태그 스타일이 .tab 클래스 (와우, 너무 멋지다!)를 사용하여 수행되지만 해당 구성 요소에서 격리되어 있음을 의미합니다. 그러한 일반적인 이름이 있더라도 페이지의 공통 클래스의 다른 구성 요소에 실수로 영향을 미치지 않으며 여기에서 내부 구조를 방해 할 외부 CSS도 없습니다. Shadow Dom은 스타일이 새는 것을 방지하는 보안 벽과 같습니다.

또한 일련의 구성 요소 인 빠른 프레임 워크 ¹도 볼 수 있습니다. 태그는 다음과 같이 정의됩니다<fast-tabs></fast-tabs> . 이것은 스키마 라이브러리 메소드로서 웹 구성 요소의 또 다른 장점을 상기시켜줍니다. 실제로 HTML에서 사용하는 구성 요소 자체의 이름으로 시작하는 API 중심 인 것 같습니다. 이 요소의 속성을 완전히 사용자 정의 할 수 있습니다. 새로운 표준은 사용자 정의 속성에 data- 접두사를 추가 할 필요조차없는 것 같습니다. 그래서 태그 구성 요소를 만들고 싶다면<chris-tabs active-tab="lunch" variation="rounded"></chris-tabs> .

아마도 스키마 라이브러리로 웹 구성 요소를 사용하는 가장 큰 플레이어는 이온 일 것입니다. 그들의 라벨은입니다<ion-tabs></ion-tabs> , 당신은 다른 프레임 워크를 포함하지 않고 사용할 수 있습니다 (그들은 자신의 스텐실 외에 각도, 반응 및 vue를 지원하지만). Ionic은 웹 구성 요소에서 큰 진전을 이루었으며 최근에 그림자 부품을 지원했습니다. 다음은 포장을 설명하는 Brandy Carney의 설명입니다.

Shadow Dom은 스타일이 구성 요소에서 유출되고 실수로 다른 요소에 적용되는 것을 방지합니다. 예를 들어, 우리는 .buttonclass 우리에게 할당합니다<ion-button></ion-button> 구성 요소. 이온 성 프레임 워크 사용자가 .button 클래스를 고유 한 요소 중 하나에서 설정하면 이전 버전의 프레임 워크에서 Ionic 버튼 스타일을 상속합니다. 왜냐하면<ion-button></ion-button> 이제 그림자 웹 구성 요소 이므로이 문제는 더 이상 존재하지 않습니다.

그러나이 캡슐화로 인해 스타일은 그림자 구성 요소의 내부 요소로 침투 할 수 없습니다. 이는 섀도우 구성 요소가 그림자 트리의 요소를 렌더링하면 사용자가 CSS를 사용하여 내부 요소를 찾을 수 없음을 의미합니다.

캡슐화는 좋은 일이지만 스타일링이 "더 단단하게"(고의적으로) 만듭니다. 이해해야 할 중요한 CSS 개념이 있습니다. CSS 사용자 정의 속성은 Shadow Dom에 침투 할 수 있습니다 . 그러나 사람들이 디자인 시스템의 모든 것을“다양하게”결정하는 것이 현명하지 않습니다. 대신, 그들은 그림자 dom 내의 각 HTML 조각을 부품으로 제공합니다 (예 :<div part="icon"> CSS를 사용하여 "외부에서 액세스 할 수 있습니다 (예 : <code>custom-component::part(icon) { } . 나는 부품 기반 스타일 후크가 대부분 좋고 이와 같은 패턴 라이브러리를위한 현명한 솔루션이라고 생각하지만, 그 부분이 나를 귀찮게한다는 것을 인정합니다. 선택기는 예상과 다르게 작동합니다. 예를 들어, 조건부로 컨텐츠를 선택할 수 없습니다. 아동 요소를 선택하거나 캐스케이드를 사용할 수도 있습니다. 다시 말해, 그것은 단지 일회성 일뿐입니다. 앞으로 나아갈 수 있고 무언가를 잡을 수는 있지만 아무것도 할 수 없습니다.

사람들을 화나게하는 것들에 대해 말하면, Andrea Giammarchi는 웹 구성 요소의 현재 상황에 대한 좋은 관점을 가지고 있습니다.

광산을 포함하여 시작된 모든 라이브러리는 " 휴대용 사용자 지정 요소 "라고하는 것을 정의하기 위해 라이브러리를 가져와야한다고 제안합니다.

Google은 항상 LiteLement를 사용하는 것이 좋습니다. Microsoft는 당신이 당신이 패스 범람을 사용하기를 원합니다. 스텐실에는 자체 구성 요소가 있습니다. HyperHTML에는 고유 한 구성 요소가 있습니다. 아무도 "원시"웹 구성 요소 만 사용하지 않습니다. 이것은 매우 이상합니다! 내가 생각하는 최악의 부분은 웹 구성 요소가 "기본 플랫폼"이어야한다는 것입니다. 즉,이를 사용하기 위해 특정 기술에 의존 할 필요는 없습니다 . 우리가 이것을 할 때, 우리는 React 또는 다른 것을 사용하는 것처럼 그것에 잠겨 있습니다.

Andrea는 기사에 새롭고 작은 라이브러리를 사용하는 것을 포함하여 몇 가지 아이디어를 제시합니다. 내가보고 싶은 것은 도서관을 전혀 사용하지 않는 스키마 라이브러리라고 생각합니다.

1. Fast는 홈페이지의 연속 문장으로 "인터페이스 시스템"을 호출하고 "UI 프레임 워크"가 이어집니다. Shoelaces는 자체를 "라이브러리"라고 부르지 만이를 "모드 라이브러리"라고 부릅니다. 나는 "디자인 시스템"이이 개념을 설명하는 데 가장 일반적으로 사용되는 용어라고 생각하지만 종종 특정 기술보다 더 광범위합니다. 빠른 코드 자체 에서이 용어를 사용하여 주제를 제어하는 ​​래퍼 요소를 표시합니다. 나는이 모든 것들을 둘러싼 용어가 확실하지 않다고 생각합니다.