웹 구성요소는 재사용 가능한 사용자 정의 요소를 만드는 표준화된 방법을 약속하며 한동안 사용되어 왔습니다. 웹 구성 요소가 상당한 발전을 이루었지만 개발자가 작업하는 동안 직면할 수 있는 몇 가지 주의 사항이 여전히 있다는 것은 분명합니다. 이 블로그에서는 이러한 주의 사항 중 10가지를 살펴보겠습니다.
프로젝트에서 웹 구성 요소를 사용할지 여부를 결정하는 경우. 선택한 프레임워크에서 웹 구성 요소가 완벽하게 지원되는지 고려하는 것이 중요합니다. 그렇지 않으면 몇 가지 불쾌한 주의 사항이 발생할 수 있습니다.
예를 들어 Angular에서 웹 구성 요소를 사용하려면 CUSTOM_ELEMENTS_SCHEMA를 모듈 가져오기에 추가해야 합니다.
@NgModule({
schemas: [CUSTOM_ELEMENTS_SCHEMA],
})
export class MyModule {}
CUSTOM_ELEMENTS_SCHEMA 사용 시 문제는 Angular가 템플릿의 맞춤 요소에 대한 유형 검사 및 intellisense를 선택 해제한다는 것입니다. (문제 참조)
이 문제를 해결하려면 Angular 래퍼 구성 요소를 생성할 수 있습니다.
다음은 그 예입니다.
@Component({
selector: 'some-web-component-wrapper',
template: '<some-web-component [someProperty]="someClassProperty"></some-web-component>
})
export class SomeWebComponentWrapper {
@Input() someClassProperty: string;
}
@NgModule({
declarations: [SomeWebComponentWrapper],
exports: [SomeWebComponentWrapper],
schemas: [CUSTOM_ELEMENTS_SCHEMA]
})
export class WrapperModule {}
이 방법은 작동하지만 수동으로 만드는 것은 좋지 않습니다. 이로 인해 유지 관리가 많이 필요하고 API와의 동기화 문제가 발생할 수 있습니다. 이것을 덜 지루하게 만들기 위해. Lit(여기 참조)와 Stencil(여기 참조)은 모두 자동으로 생성할 수 있는 CLI를 제공합니다. 그러나 처음에 이러한 래퍼 구성 요소를 생성해야 하면 추가 오버헤드가 발생합니다. 선택한 프레임워크가 웹 구성 요소를 적절하게 지원한다면 래퍼 구성 요소를 생성할 필요가 없습니다.
또 다른 예는 React입니다. 이제 이러한 문제를 해결하는 React v19가 출시되었습니다. 그러나 아직 v18을 사용하고 있다면 v18이 웹 구성 요소를 완전히 지원하지 않는다는 점에 유의하세요. React v18에서 웹 구성 요소로 작업하는 동안 직면할 수 있는 몇 가지 문제는 다음과 같습니다. 이는 Lit 문서에서 직접 가져온 것입니다.
"React는 모든 JSX 속성이 HTML 요소 속성에 매핑된다고 가정하고 속성을 설정할 방법을 제공하지 않습니다. 이로 인해 복잡한 데이터(객체, 배열 또는 함수 등)를 웹 구성 요소에 전달하기가 어렵습니다."
"React는 또한 모든 DOM 이벤트에 해당하는 "이벤트 속성"(onclick, onmousemove 등)이 있다고 가정하고 addEventListener()를 호출하는 대신 이를 사용합니다. 이는 더 복잡한 웹 구성 요소를 올바르게 사용하려면 자주 사용해야 함을 의미합니다. ref() 및 명령형 코드입니다."
React v18의 경우 Lit에서는 속성 설정 및 이벤트 수신과 관련된 문제를 해결해 주는 래퍼 구성요소 사용을 권장합니다.
다음은 Lit를 사용하는 React 래퍼 구성 요소의 예입니다.
import React from 'react';
import { createComponent } from '@lit/react';
import { MyElement } from './my-element.js';
export const MyElementComponent = createComponent({
tagName: 'my-element',
elementClass: MyElement,
react: React,
events: {
onactivate: 'activate',
onchange: 'change',
},
});
사용방법
<MyElementComponent
active={isActive}
onactivate={(e) => setIsActive(e.active)}
onchange={handleChange}
/>
다행히 React v19를 사용하면 더 이상 래퍼 구성 요소를 만들 필요가 없습니다. 이야!
마이크로 프런트엔드에서 웹 구성 요소를 사용하면 다음과 같은 흥미로운 과제가 드러납니다.
중요한 문제 중 하나는 맞춤 요소 레지스트리의 전역적 특성입니다.
마이크로 프런트엔드를 사용하고 웹 구성 요소를 사용하여 각 앱에서 UI 요소를 재사용하려는 경우 이 오류가 발생할 가능성이 높습니다.
@NgModule({
schemas: [CUSTOM_ELEMENTS_SCHEMA],
})
export class MyModule {}
이 오류는 이미 사용된 이름으로 맞춤 요소를 등록하려고 할 때 발생합니다. 이는 마이크로 프런트엔드의 각 앱이 동일한 index.html 파일을 공유하고 각 앱이 맞춤 요소를 정의하려고 시도하기 때문에 마이크로 프런트엔드에서 흔히 발생합니다.
이 문제를 해결하기 위한 범위 지정 사용자 정의 요소 레지스트리라는 제안이 있지만 ETA가 없으므로 안타깝게도 폴리필을 사용해야 합니다.
폴리필을 사용하지 않는 경우 한 가지 해결 방법은 이름 충돌을 피하기 위해 접두사를 사용하여 맞춤 요소를 수동으로 등록하는 것입니다.
Lit에서 이 작업을 수행하려면 맞춤 요소를 자동 등록하는 @customElement 데코레이터를 사용하지 않아도 됩니다. 그런 다음 tagName에 대한 정적 속성을 추가합니다.
이전
@Component({
selector: 'some-web-component-wrapper',
template: '<some-web-component [someProperty]="someClassProperty"></some-web-component>
})
export class SomeWebComponentWrapper {
@Input() someClassProperty: string;
}
@NgModule({
declarations: [SomeWebComponentWrapper],
exports: [SomeWebComponentWrapper],
schemas: [CUSTOM_ELEMENTS_SCHEMA]
})
export class WrapperModule {}
이후
import React from 'react';
import { createComponent } from '@lit/react';
import { MyElement } from './my-element.js';
export const MyElementComponent = createComponent({
tagName: 'my-element',
elementClass: MyElement,
react: React,
events: {
onactivate: 'activate',
onchange: 'change',
},
});
그런 다음 각 앱에서 앱 이름의 접두사를 사용하여 맞춤 요소를 정의합니다.
<MyElementComponent
active={isActive}
onactivate={(e) => setIsActive(e.active)}
onchange={handleChange}
/>
그런 다음 맞춤 요소를 사용하려면 새 접두사와 함께 사용하세요.
Uncaught DOMException: Failed to execute 'define' on 'CustomElementRegistry': the name "foo-bar" has already been used with this registry
이 방법은 빠른 단기 솔루션으로 작동하지만 최고의 개발자 경험이 아닐 수 있으므로 범위가 지정된 사용자 정의 요소 레지스트리 폴리필을 사용하는 것이 좋습니다.
Shadow DOM은 캡슐화를 제공하지만 다음과 같은 고유한 과제도 안고 있습니다.
Shadow dom은 캡슐화를 제공하여 작동합니다. 스타일이 구성요소 밖으로 누출되는 것을 방지합니다. 또한 전역 스타일이 구성 요소의 섀도우 돔 내의 요소를 대상으로 삼는 것을 방지합니다. 그러나 해당 스타일이 상속되는 경우 구성 요소 외부의 스타일이 여전히 누출될 수 있습니다.
예를 들어보겠습니다.
@customElement('simple-greeting')
export class SimpleGreeting extends LitElement {
render() {
return html`<p>Hello world!</p>`;
}
}
export class SimpleGreeting extends LitElement {
static tagName = 'simple-greeting';
render() {
return html`<p>Hello world!</p>`;
}
}
<버튼> 버튼은 버블링되는 구성된 이벤트를 발생시킵니다.
구성요소-a
[SimpleGreeting].forEach((component) => {
const newTag = `app1-${component.tagName}`;
if (!customElements.get(newTag)) {
customElements.define(newTag, SimpleGreeting);
}
});
이벤트가 컴포넌트 b에서 발생하므로 대상이 컴포넌트 b 또는 버튼이 될 것이라고 생각할 수도 있습니다. 그러나 이벤트가 재지정되어 대상이 구성 요소 A가 됩니다.
따라서 이벤트가 <버튼> 또는 <컴포넌트-b> 이벤트의 구성 경로를 확인해야 합니다.
링크는 이 예에서와 같이 Shadow DOM 내에서 사용되며 앱에서 전체 페이지 새로고침을 실행합니다.
@NgModule({
schemas: [CUSTOM_ELEMENTS_SCHEMA],
})
export class MyModule {}
라우팅이 프레임워크가 아닌 브라우저에 의해 처리되기 때문입니다. 프레임워크는 이러한 이벤트에 개입하고 프레임워크 수준에서 라우팅을 처리해야 합니다. 그러나 이벤트는 섀도우 DOM에서 대상이 변경되므로 프레임워크가 앵커 요소에 쉽게 액세스할 수 없기 때문에 이를 수행하기가 더 어려워집니다.
이 문제를 해결하려면 그러면 이벤트 전파가 중지되고 새 이벤트가 발생합니다. 새 이벤트는 버블링되고 구성되어야 합니다. 또한 세부적인 내용에도 접근이 필요합니다
e.currentTarget에서 얻을 수 있는 인스턴스입니다.
@Component({
selector: 'some-web-component-wrapper',
template: '<some-web-component [someProperty]="someClassProperty"></some-web-component>
})
export class SomeWebComponentWrapper {
@Input() someClassProperty: string;
}
@NgModule({
declarations: [SomeWebComponentWrapper],
exports: [SomeWebComponentWrapper],
schemas: [CUSTOM_ELEMENTS_SCHEMA]
})
export class WrapperModule {}
소비 측면에서는 이 이벤트를 수신하고 프레임워크별 라우팅 함수를 호출하여 라우팅을 처리하도록 전역 이벤트 리스너를 설정할 수 있습니다.
웹 구성 요소를 구축할 때. 다른 웹 구성요소를 슬롯에 배치할지, 아니면 다른 웹 구성요소 안에 중첩할지 결정할 수 있습니다. 예시는 다음과 같습니다.
슬롯 아이콘
import React from 'react';
import { createComponent } from '@lit/react';
import { MyElement } from './my-element.js';
export const MyElementComponent = createComponent({
tagName: 'my-element',
elementClass: MyElement,
react: React,
events: {
onactivate: 'activate',
onchange: 'change',
},
});
중첩 아이콘
<MyElementComponent
active={isActive}
onactivate={(e) => setIsActive(e.active)}
onchange={handleChange}
/>
구성 요소를 중첩하기로 결정하면 중첩된 구성 요소를 쿼리하기가 더 어려워질 수 있습니다. 특히 페이지의 특정 요소를 대상으로 해야 하기 때문에 엔드 투 엔드 테스트를 작성해야 하는 QA 팀이 있는 경우.
예를 들어 some-icon에 액세스하려면 먼저 ShadowRoot를 가져와 some-banner에 액세스한 다음 해당 섀도우 루트 내에 새 쿼리를 생성해야 합니다.
Uncaught DOMException: Failed to execute 'define' on 'CustomElementRegistry': the name "foo-bar" has already been used with this registry
간단해 보일 수 있지만 구성요소가 더 깊이 중첩될수록 점점 더 어려워집니다. 또한 구성 요소가 중첩된 경우 도구 설명 작업이 더 어려워질 수 있습니다. 특히 깊게 중첩된 요소를 대상으로 하여 그 아래에 도구 설명을 표시해야 하는 경우에는 더욱 그렇습니다.
제가 발견한 바에 따르면 슬롯을 사용하면 구성 요소가 더 작고 유연해지며 유지 관리도 더 용이해집니다. 따라서 슬롯을 선호하고 중첩된 섀도우 돔을 피하세요.
슬롯은 UI 요소를 구성하는 방법을 제공하지만 웹 구성 요소에는 한계가 있습니다.
::slotted 선택기는 슬롯의 직계 하위 항목에만 적용되므로 더 복잡한 시나리오에서는 유용성이 제한됩니다.
예를 들어보겠습니다.
@customElement('simple-greeting')
export class SimpleGreeting extends LitElement {
render() {
return html`<p>Hello world!</p>`;
}
}
export class SimpleGreeting extends LitElement {
static tagName = 'simple-greeting';
render() {
return html`<p>Hello world!</p>`;
}
}
[SimpleGreeting].forEach((component) => {
const newTag = `app1-${component.tagName}`;
if (!customElements.get(newTag)) {
customElements.define(newTag, SimpleGreeting);
}
});
웹 구성 요소는 새로운 기능과 모범 사례를 채택하는 데 있어 Vue, React, Svelte, Solid와 같은 인기 프레임워크보다 뒤처지는 경우가 많습니다.
이는 웹 구성요소가 브라우저 구현 및 표준에 의존하기 때문에 최신 JavaScript 프레임워크의 빠른 개발 주기에 비해 발전하는 데 더 오랜 시간이 걸릴 수 있기 때문일 수 있습니다.
결과적으로 개발자는 특정 기능을 기다리거나 다른 프레임워크에서 쉽게 사용할 수 있는 해결 방법을 구현해야 할 수도 있습니다.
이에 대한 몇 가지 예는 JS에서 CSS를 스타일 지정의 기본 옵션으로 사용하는 Lit입니다. JS 프레임워크의 CSS에 성능 문제가 있다는 것은 오랫동안 알려져 왔습니다
추가 런타임 오버헤드가 발생하는 경우가 많았기 때문입니다. 그래서 우리는 런타임 기반 솔루션이 없는 JS 프레임워크에서 최신 CSS를 보기 시작했습니다.
Lit의 JS 솔루션 CSS는 여전히 런타임 기반입니다.
또 다른 예는 Signals입니다. 현재 Lit의 기본 동작은 @property 데코레이터를 추가하여 클래스 속성에 반응성을 추가하는 것입니다.
그러나 속성이 변경되면 전체 구성 요소가 다시 렌더링됩니다. 신호를 사용하면 신호에 의존하는 구성 요소의 일부만 업데이트됩니다.
이는 UI 작업에 더 효율적입니다. 매우 효율적이어서 이를 JavaScript에 추가하는 새로운 제안(TC39)이 있습니다.
이제 Lit는 Signals를 사용하기 위한 패키지를 제공하지만 Vue 및 Solid와 같은 다른 프레임워크가 이미 수년 동안 이 기능을 수행해 왔을 때 이는 기본 반응성이 아닙니다.
신호가 웹 표준에서 벗어날 때까지 몇 년 동안 신호를 기본 반응성으로 보지 못할 가능성이 높습니다.
이전 경고 "9. 슬롯 요소는 항상 돔에 있습니다"와 관련된 또 다른 예입니다. Svelte의 창시자인 Rich Harris가 이에 대해 이야기했습니다
5년 전 "내가 웹 구성 요소를 사용하지 않는 이유"라는 제목의 그의 블로그 게시물에서.
그는 Svelte v2에서 슬롯 콘텐츠가 열심히 렌더링되는 방식에 대해 웹 표준 접근 방식을 어떻게 채택했는지에 대해 이야기합니다. 그러나 그들은 그것에서 벗어나야 했습니다
Svelte 3에서는 개발자에게 큰 좌절감을 안겨주었기 때문입니다. 그들은 대부분의 경우 슬롯 콘텐츠가 느리게 렌더링되기를 원한다는 사실을 알아냈습니다.
Vuejs와 같은 다른 프레임워크가 이미 이를 지원하는 경우 웹 구성 요소에서 슬롯에 데이터를 전달하는 쉬운 방법이 없다는 것과 같은 더 많은 예를 생각해 낼 수 있습니다. 하지만 여기서 중요한 점은
웹 표준을 따르기 때문에 웹 구성 요소는 웹 표준을 따르지 않는 프레임워크보다 기능을 훨씬 느리게 채택합니다.
웹 표준에 의존하지 않음으로써 우리는 혁신을 이루고 더 나은 솔루션을 제시할 수 있습니다.
웹 구성 요소는 재사용 가능하고 캡슐화된 맞춤 요소를 만드는 강력한 방법을 제공합니다. 그러나 우리가 살펴본 것처럼 개발자가 작업할 때 직면할 수 있는 몇 가지 주의 사항과 과제가 있습니다. 프레임워크 비호환성, 마이크로 프런트엔드의 사용, Shadow DOM의 제한 사항, 이벤트 대상 변경 문제, 슬롯 및 느린 기능 채택 등은 모두 신중하게 고려해야 하는 영역입니다.
이러한 과제에도 불구하고 진정한 캡슐화, 이식성, 프레임워크 독립성과 같은 웹 구성 요소의 이점은 웹 구성 요소를 현대 웹 개발의 귀중한 도구로 만듭니다. 생태계가 계속 발전함에 따라 이러한 문제를 해결하는 개선 사항과 새로운 솔루션을 기대할 수 있습니다.
웹 구성 요소를 고려 중인 개발자의 경우 이러한 장단점을 평가하고 해당 분야의 최신 발전 사항에 대한 최신 정보를 얻는 것이 중요합니다. 올바른 접근 방식과 이해를 통해 웹 구성요소는 개발 툴킷에 강력한 추가 기능을 제공할 수 있습니다.
위 내용은 웹 구성 요소로 작업하는 동안 직면할 수 있는 주의 사항의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
