자신만의 구성 요소 라이브러리를 처음부터 구축하기 전에 다양한 유형의 구성 요소 라이브러리와 이를 사용할 때의 장점과 단점을 살펴보겠습니다.
? 교정과 피드백을 주신 stephband (Mastodon, Bluesky)에게 특별히 감사 인사를 전하고 싶습니다.
이 글은 제 사이트의 X-Post라는 점을 참고해 주세요. 내용은 거의 동일하지만, 원본 게시물에는 이 글에서 생략된 대화형 스니펫과 동영상이 있습니다.
저는 엄청난 음악 팬입니다. 제가 가장 좋아하는 취미 중 하나는 녹음을 해서 앞에서 뒤로 듣는 것입니다. 음악 앨범은 개념이 간단하며 아티스트가 녹음한 트랙 모음이며 완전하고 일관된 노래 세트로 간주됩니다.
하지만 녹음된 음악이 존재하지 않는다면 어떨까요? 노래를 테이프, CD, mp3(또는 원하는 경우 FLAC)에 저장하는 대신 아티스트가 라이브로 연주한 경우에만 앨범을 들을 수 있습니다. 밴드에 가서 장비를 설정하고 앨범을 처음부터 끝까지 재생하도록 요청해야 합니다. 모두가 똑같은 경험을 하도록 하려면 매번 같은 방식으로 플레이해야 합니다.
균열이 보이기 시작합니다. 밴드의 음악에 관심이 있는 사람이라면 누구나 들을 수 있도록 하는 것은 효율적인 방법이 아닙니다. Taylor Swift가 자신의 노래 Fortnight를 Spotify에서 듣는 모든 사람을 위해 개인적으로 재생한다면 3,179년이 걸릴 것입니다. 그리고 그것은 비행기 여행을 설명하지 않습니다. 아티스트는 지루해하고 심지어 부주의할 수도 있으며, 이로 인해 청취자의 경험이 줄어들게 됩니다.
그럼 이것이 웹 개발과 어떤 관련이 있나요? UI 컨트롤을 구축할 때마다 해당 컨트롤이 제대로 작동하고, 견고하며, 접근성이 높은지 확인해야 합니다. 매번 같은 UI를 계속해서 다시 작성하면 지루해질 것입니다. 실수가 간과되어 최종 사용자의 경험이 더욱 악화될 수 있습니다.
저는 거의 10년 동안 웹 개발자로 일해 왔으며 종종 동일한 UI 패턴을 여러 번 사용하면서 수백 개의 구성 요소를 직접 작성했습니다. 저는 수십 개의 구성 요소 라이브러리를 사용했으며 관리 대시보드, 구성 요소 라이브러리, 모바일 애플리케이션, 블로그, figma 플러그인, VSCode 확장 등을 구축했습니다. 이 기사는 구성 요소, 라이브러리의 역할과 개발자가 직접 작성해야 하는지 여부에 대해 정리한 것입니다.
사용자 인터페이스를 구축할 때 매번 처음부터 모든 HTML 마크업을 작성하지는 않습니다. 우리는 일반적인 UI 패턴을 캡슐화하는 재사용 가능한 구성 요소인 구성 요소를 사용하여 UI를 작성합니다. 구성 요소를 작성하면 단일 프로젝트는 물론 독립 프로젝트에서도 여러 번 사용할 수 있습니다.
여기서 카운터 구성요소를 작성했는데, 한 번 작성하고 페이지의 여러 위치에서 사용했습니다.
<body>
<div class="wrapper">
<counter-button></counter-button>
<counter-button></counter-button>
<counter-button></counter-button>
</div>
<script type="module">
import { LitElement, html } from 'lit';
class CounterButton extends LitElement {
constructor() {
super();
this.count = 0;
}
static properties = {
count: { type: Number }
};
_increment() {
this.count++;
}
render() {
return html`
<button @click=${this._increment}>Count: ${this.count}</button>
`;
}
}
customElements.define('counter-button', CounterButton);
</script>
</body>
우리 튜토리얼 작성자는 카운터가 유행에 뒤떨어지는 것처럼 시연하는 것을 좋아하지만 실제 애플리케이션에는 구성 요소로 작성된 수십 가지의 다양한 UI 패턴이 포함됩니다.
이 기사에서는 특정 UI 패턴에 대한 스타일을 제공하는 CSS 규칙을 구성 요소 아래에 그룹화하겠습니다. 누구에게 질문하느냐에 따라 정의가 모호해질 수 있습니다.
모든 구성 요소가 독립형은 아닙니다. 많은 구성 요소를 구성 요소 라이브러리라고 하는 단일 패키지 내에 그룹화하는 것이 합리적입니다.
사이트에 특정한 모양이나 느낌을 주고 싶다면 구성 요소 라이브러리를 사용할 수 있습니다. 다음과 같은 구성 요소 라이브러리가 있습니다.
하지만 모양과 크기가 다릅니다. 구성 요소 라이브러리를 정의할 때 사용하게 된 정의는 다음과 같습니다.
구성 요소 라이브러리는 유틸리티나 외관(또는 둘 다)이 응집된 재사용 가능한 구성 요소 집합입니다. 훌륭한 구성 요소 라이브러리는 개발자가 UI 요구 사항을 효율적으로 달성하는 데 도움이 되는 동시에 최종 사용자에게 모범적인 경험을 제공합니다.
이 기사 뒷부분에서 가이드라인과 디자인 시스템에 대해 이야기하므로 잠시 시간을 내어 이를 명확하게 설명하겠습니다. 한쪽이 어디서 끝나는지, 한쪽이 시작하는지, 한쪽이 다른 쪽을 포괄하는지 확인하기 어려울 수 있습니다.
디자인 시스템
저는 디자인 시스템을 사물이 어떻게 보이고, 느껴지고, 행동해야 하는지에 대한 사양이라고 생각합니다. 디자인 시스템은 제품, 브랜드 또는 회사를 포괄하여 경험 전반에 걸쳐 일관성을 보장할 수 있습니다. 포괄적인 디자인 시스템은 글꼴 모음, 글꼴 크기, 간격 크기, UI 패턴, 복사 지침 등 모든 것을 규정합니다.
가장 잘 알려진 디자인 시스템은 다음과 같습니다.
많은 디자인 시스템이 회사에만 적용되는 반면, 머티리얼 디자인과 같은 디자인 시스템은 전 세계 팀에서 친숙한 느낌의 제품을 만드는 지름길로 사용합니다. 머티리얼 디자인 원칙을 적용한 제품을 몇 군데 사용해 보셨을 텐데요, 기본적인 사용성 문제에서 자유롭지는 않습니다.
구성 요소 라이브러리
구성 요소 라이브러리의 경우 디자인 시스템의 코드 구현일 수도 있고 아닐 수도 있습니다. 디자인 시스템을 갖춘 회사에서 일하는 경우 해당 구성 요소 라이브러리(존재하는 경우)가 긴밀하게 통합되어 있을 가능성이 높습니다.
예를 들어 Google의 Material Web은 Material Design의 웹 구성 요소 구현입니다. 기본 웹 및 Lightning 웹 구성 요소도 오픈 소스입니다.
UI 컴포넌트(또는 위젯)의 개념은 오래전부터 존재해 왔습니다. 박물관의 복고풍 사용자 인터페이스를 보고 싶다면 팝콘을 들고 1974년부터 1990년까지의 "모든 위젯"에 대한 2시간 이상의 비디오를 시청하세요.
2000년대 초반부터 개발자가 웹용으로 구축하는 데 도움을 주기 위해 만들어진 구성 요소 라이브러리를 보기 시작했습니다. 그 당시의 웹 브라우저 환경은 지금 우리가 보는 것과는 비교할 수 없을 정도였습니다. Internet Explorer 버전은 사양에서 완전히 벗어났는데, 이는 당시 IE가 가졌던 엄청난 시장 점유율을 고려할 때 특히 문제가 되었습니다. Internet Explorer 6은 개발하기 어려운 것으로 유명했습니다. 주로 박스 모델의 잘못된 구현과 CSS2 지원 부족으로 인해 발생합니다.
? TIL, Internet Explorer는 개발자가 표준을 지원하지 않는 이전 브라우저를 달래기 위해 비표준 HTML 및 CSS를 작성할 수 있는 "특수 모드"를 지원했습니다.
다행히 웹 개발을 본격적으로 시작하면서 이런 문제들은 많이 해결되었습니다. 이 시점에는 브라우저 간 지원을 통해 복잡한 인터페이스 작성을 좀 더 쉽게 만들어주는 라이브러리가 여전히 몇 개 있었습니다. 내가 사용한 첫 번째 구성 요소 라이브러리인 jQuery UI는 아코디언과 기타 위젯을 지원했습니다. 그러나 브라우저는 지속적으로 발전하고 있으며 이제 2020년 모든 브라우저에서 사용할 수 있는 세부 정보 및 요약 요소를 사용하여 이 아코디언 패턴을 구현하는 기본 방법을 갖게 되었습니다. 이러한 요소를 사용하면 JavaScript 없이 대화형 아코디언을 만드는 데 상당한 진전을 이룰 수 있습니다.
2009년과 비교해 보면 이러한 요소는 어떤 브라우저에서도 구현되지 않았습니다. 작업하려면 상당한 양의 JS가 필요했습니다. 15년 전 웹 개발자들이 어떻게 아코디언을 구현했는지 알고 싶다면 jQuery UI v1.7 소스 코드를 살펴보고 CTRL+F "아코디언"을 살펴보세요.
향후 20년 동안 웹의 기능은 성장했습니다. 더 강력한 장치는 더 강력한 브라우저를 의미했습니다. 브라우저가 더욱 강력해짐에 따라 웹 애플리케이션은 더욱 야심차게 되었습니다. 개발자들은 빌딩 블록, 즉 구성 요소 모델을 사용하여 UI를 만들 수 있도록 함으로써 이러한 애플리케이션을 구축하는 데 도움이 되는 도구를 만들어 응답했습니다. 우리는 이러한 구성 요소 기반 프레임워크가 확산되는 것을 보았습니다. 저는 Angular, React, Vue에 대해 이야기하고 있습니다. 각각은 구성 요소 라이브러리로 구성된 풍부한 생태계를 갖추고 있습니다.
과도한 수정이 있었고 현재 프런트엔드 환경이 대부분의 사람들의 요구에 비해 너무 강력한 도구로 과포화되어 있다는 합리적인 주장이 있습니다. 하지만 거기까지 가지 맙시다.
이 버전은 원본 게시물의 대화형 스니펫으로 확장되었습니다
구성 요소 라이브러리 구축의 과제는 일회성 거래가 아니라는 것입니다. 가장 인기 있는 라이브러리 중 다수는 수년 동안 존재해 왔으며 현재의 위치에 도달하기 위해 많은 연구, 사용 피드백 및 기여를 해왔습니다.
좋은 구성 요소 라이브러리에는 다음과 같은 특징이 있는 경우가 많습니다.
반대로, 구성 요소 라이브러리가 좋지 않은지 식별하는 방법은 접근성을 고려하지 않거나, API가 일관되지 않거나, 프로젝트 관리 책임이 거의 또는 전혀 없거나, 아무런 권한도 없는 경우입니다. 명확하고 일관된 문서화.
우리는 좋은 구성 요소 라이브러리가 어떤 것인지 알고 있으므로 이것이 어떻게 여러분의 삶과 사용자의 삶을 좀 더 좋게 만들 수 있는지 살펴보겠습니다.
기한이 촉박한 프로젝트를 진행하는 경우 효율성을 높이는 것이 중요합니다. 하지만 강력한 웹 경험을 구축하는 데 효율성이 희생되어서는 안 됩니다. 구성 요소 라이브러리를 사용하면 바퀴를 재발명하는 데 소요되는 시간을 줄이고 더 미세한 세부 사항에 집중하는 데 더 많은 시간을 할애할 수 있습니다.
우리는 반복적인 작업에 의욕을 느끼지 않습니다. 우리는 기술적인 도전을 즐기며 동일한 구성 요소를 다시 작성하는 것은 재미있는 도전이 아닙니다. 우리는 지루해져서 실수를 그냥 지나칠 때 무슨 일이 일어나는지 이미 이야기했습니다.
대화상자 구성요소를 처음부터 구현하려면 다음을 수행해야 합니다.
위 내용을 기억하고 구현하려면 작업이 필요하지만, 잘못하면 인터페이스를 문자 그대로 사용할 수 없게 될 수 있습니다. 포커스를 잘못 처리하는 경우가 그렇습니다.
최종 사용자를 염두에 두고 구축된 구성 요소 라이브러리를 사용하면 동일한 구성 요소를 재구축하는 데 소요되는 시간을 줄이면서 손상된 경험이 발생할 위험을 방지할 수 있습니다.
여러 웹 애플리케이션을 사용하는 회사에서 일하는 경우 일반적으로 일련의 지침을 따릅니다. 이러한 지침에 따라 사용할 색상 팔레트, 서체 크기, UI 요소의 모양과 동작 방식이 결정될 수 있습니다.
그러나 구성 요소를 다시 작성하면 애플리케이션이 스타일 가이드에서 벗어날 가능성이 높아집니다. 구성 요소 라이브러리를 사용하면 브랜드 지침에 따라 구성 요소의 UI를 더 쉽게 감사할 수 있으므로 어디서 사용하든 멋지게 보일 수 있습니다.
Uber에는 동일한 사용자 인터페이스 요소를 공유하는 여러 가지 앱이 있습니다. 나는 그들이 이러한 앱 전체에서 동일한 구성 요소 라이브러리를 사용한다고 거의 확신합니다. 이렇게 하면 각각의 새로운 앱이 사실상 브랜드 지침을 준수한다는 것이 보장됩니다.
위에 언급한 이점은 자체 구성 요소 라이브러리를 사용하든 타사를 사용하든 관계가 없습니다. 귀하 또는 귀하의 팀이 라이브러리를 구축하지 않고 대신 제3자에 의존하기로 결정했다면 다음 사항을 고려해 볼 가치가 있습니다.
구성 요소 라이브러리를 선택하면 프런트엔드 코드 작성 방법과 인터페이스의 모양과 동작에 큰 영향을 미칠 파트너를 선택하는 것입니다.
전자는 귀하에게 큰 영향을 미칠 것이고, 후자는 최종 사용자에게 큰 영향을 미칠 것입니다. 구성 요소 라이브러리를 사용하면 해당 구성 요소 라이브러리의 표준에 갇히게 됩니다.
라이브러리는 전용 개발 시간이 필요할 수 있는 대규모 주요 버전의 주요 변경 사항을 도입할 수 있으며, 심각한 회귀가 도입되지 않았는지 확인하기 위한 많은 테스트도 수행할 수 있습니다.
몇 년 전 저는 React Admin을 사용하여 내부 부서에 복잡한 관리 대시보드를 구축했습니다. 라이브러리는 복잡한 데이터를 가져오고 표시하는 전용 구성 요소 모음을 제공했습니다. 당시 우리 애플리케이션은 React Admin에 크게 의존했기 때문에 주요 버전 간의 업그레이드가 어려웠습니다. 특히 React Admin에서 사용하는 많은 내부 도구가 다른 도구로 교체되었기 때문입니다. 변경 범위가 매우 넓기 때문에 우리는 발견한 문제를 업그레이드하고 플래그를 지정하는 데 많은 시간을 보냈습니다.
자체 솔루션을 구축한다고 해서 장기적으로 시간이 절약될 것이라고는 생각하지 않습니다. 하지만 이러한 종류의 공급업체 종속은 특히 도구에 모든 것을 집중하기 전에 고려해 볼 가치가 있습니다.
놀랍게도 구성 요소가 많은 라이브러리는 많은 코드를 사용하여 작성되는 경향이 있습니다. 종속성을 설치할 때 다운로드하는 코드와 최종 사용자에게 보내는 코드.
최신 도구를 사용하면 트리 쉐이킹과 같은 번들 최적화를 더 쉽게 수행하여 사용하지 않는 코드를 제거할 수 있지만 사용자에게 필요하지 않은 코드를 모두 제거한다는 보장은 없습니다.
사용 중인 라이브러리를 자세히 살펴보지 않으면 해당 라이브러리가 가져오는 개별 패키지를 모두 알지 못할 수도 있습니다. 수백 개의 불필요한 종속성이 생길 수 있습니다. e18e 커뮤니티의 사람들은 이 문제를 밝히고 해결하기 위해 열심히 노력해 왔습니다.
이러한 문제 중 상당수는 자체 구성 요소 라이브러리를 롤링하는 것과 관련해서도 발생할 수 있습니다. 가장 큰 차이점은 구성 요소 라이브러리에 대한 관리 권한이 있다는 것입니다. 특정 문제를 해결하는 방법을 정의하고 단점을 개선하는 방법을 제어할 수 있습니다.
월드와이드웹의 초기 제안은 CERN 연구원들 간의 의사소통을 개선하기 위한 도구였습니다. 제안서는 하이퍼텍스트를 사용하여 문서를 공유하고 서로 연결하는 방법을 설명했습니다. 이것이 웹의 기본 초석이며 우리는 여전히 웹상의 다른 HTML 문서를 연결하는 태그입니다.
그러나 지난 수십 년 동안 웹의 범위가 확대되면서 우리가 웹을 탐색하는 데 사용하는 브라우저는 그 자체로 괴물이 되었습니다. 오늘날의 브라우저는 강력한 형태의 창의적인 표현과 네이티브와 유사한 소프트웨어의 실행을 가능하게 합니다.
일반 용도, 초틈새용 등 수백 가지의 다양한 솔루션이 있지만 다음 프로젝트에 적합한 도구를 찾으려면 다음과 같은 복잡한 결정 프로세스가 필요합니다.
이는 모든 사용 사례 또는 구성 요소 라이브러리 유형의 포괄적인 목록은 아니지만 다음 측면에서 구성 요소 라이브러리의 차이점을 보여줍니다.
가장 일반적인 구성 요소 라이브러리 유형을 살펴보겠습니다
? 간단한 참고 사항: 자신만의 웹 구성 요소 라이브러리를 구축하는 데 관심이 있다면 내 강좌 Component Odyssey를 확인해 보세요. 모든 프런트엔드 프레임워크에서 작동하는 구성 요소 라이브러리를 구축하고 게시하는 방법을 배우게 됩니다.
저에게는 부트스트랩이 가장 먼저 떠오릅니다. 예전에는 사이트에 빠르게 페인트칠을 하고 싶다면 CDN 링크를 부트스트랩 CSS 파일에 추가하고 즉시 부트스트랩 모양을 얻었습니다. 2010년대 중반에는 어디든 있었습니다.
이러한 종류의 도구의 기술적 범위는
에
Open Props와 같은 수십 가지 다른 도구도 그 중간에 적합합니다.
대화형 웹 애플리케이션을 구축하는 경우 보기에도 좋고 기능도 뛰어난 구성 요소 모음을 사용하고 싶을 수도 있습니다. 필요한 모든 것을 제공하는 기성 구성 요소 라이브러리가 많이 있습니다.
어떤 프레임워크를 사용하여 앱을 작성하든 관계없이 사용할 수 있는 멋진 구성 요소 세트가 있을 것입니다.
또 다른 훌륭한 구성 요소 라이브러리는 Shoelace로, 완전히 대화형이며 완전한 스타일의 구성 요소를 수십 개 제공합니다.
Shoelace와 같은 라이브러리를 특히 흥미롭게 만드는 점은 브라우저에 내장된 구성 요소 작성 방식인 웹 구성 요소를 사용하여 구축되었다는 것입니다. Shoelace와 같은 도구를 사용하여 UI를 구축하면 다양한 프런트엔드 프레임워크에서 사용할 수 있다는 추가적인 이점을 얻을 수 있습니다. 제가 예전에 조금 말씀드린 적이 있는 내용입니다.
Vue와 React에서 사용되는 동일한 Shoelace 구성요소는 다음과 같습니다.
프로젝트 사양에 따라 기성 도구를 사용할 여유가 없을 수도 있습니다. 귀하의 디자인 사양은 매우 구체적일 수 있습니다.
마찰의 첫 징후가 보이면 팀이 부품을 굴리는 모습을 본 적이 있습니다. 그리고 수동으로 데이터를 선택하는 경우에는 사용자 경험이 훨씬 더 악화되었습니다. 돌이켜보면 스타일이 지정되지 않은 구성 요소 라이브러리를 사용하면 팀에 외관 유연성을 제공하는 동시에 시간도 확보할 수 있었을 것입니다
그래서 유연한 스타일링 후크와 함께 전혀 스타일이 지정되지 않은 구성 요소를 제공하는 라이브러리를 찾을 수 있습니다. 좋은 라이브러리라면 복잡한 상호작용도 모두 처리해 줄 것입니다. 이는 두 세계 모두에서 가장 좋은 상황입니다.
다양한 장치와 입력 모드로 테스트하지 않는 한 브라우저가 제공하는 스타일 후크 이상을 적용하려는 경우 확인란을 엉망으로 만들기 쉽습니다.
원본 기사에는 스크린 리더를 사용하여 다양한 체크박스 구현과 상호 작용하는 모습을 보여주는 비디오가 있습니다
Radix는 널리 사용되는 라이브러리의 예이지만 React를 사용하여 구축되었습니다.
이와 같은 구성 요소 라이브러리의 다른 예로는 Lion 및 HeadlessUI가 있습니다.
일부 개발자는 두 가지 장점을 모두 원할 수도 있습니다. 그들은 마크업, 스타일 및 기능을 완전히 제어하면서 신뢰할 수 있는 타사 라이브러리로 구축된 구성 요소를 원할 수도 있습니다. ShadCN과 같은 라이브러리는 개발자가 구성 요소 정의를 복사하여 자신의 프로젝트에 붙여 넣어 구성 요소를 효과적으로 소유
할 수 있도록 함으로써 이러한 종류의 작업 흐름을 허용합니다.이 시점에서는 그러한 단일 구성 요소 라이브러리가 존재하지 않는 이유가 분명해졌습니다. 다양한 구성 요소 라이브러리 그룹을 전체적으로 살펴보았습니다.
그런데 브래드 프로스트(Brad Frost)가 주도한 개념인 '글로벌 디자인 시스템(Global Design System)'을 도입하려는 움직임이 있습니다.
발표에서 Brad는 자신이 참여한 수백 개의 프로젝트에서 많은 UI 컨트롤이 다양한 프로젝트에서 유사하게 작동(또는 작동해야 함)하지만 개발자는 모든 단일 프로젝트에서 동일한 것을 다시 구현한다고 간략하게 설명했습니다. 이로 인해 많은 시간과 노력이 낭비되고 프로젝트 간 불일치가 발생했습니다. 이는 또한 기존 구성 요소 라이브러리로 확장됩니다. React Aria의 콤보박스에 대한 키보드 동작이 ShadCN의 콤보박스와 다르다는 것을 알 수 있습니다.
원본 기사에는 키보드를 사용하여 다양한 콤보박스 구현과 상호 작용하는 모습을 보여주는 비디오가 있습니다
Brad Frost는 아직 HTML에서 사용할 수 없는 컨트롤의 기능 기준을 보장하기 위해 거의 모든 프런트엔드 프로젝트에서 채택할 수 있는 웹 구성 요소 집합인 글로벌 디자인 시스템을 제안하고 있습니다.
향후 몇 년 내에 이것이 어떻게 구체화될 수 있는지 알아보기 위해 Open UI 내에서 논의가 진행되고 있습니다.
이 기사는 구성 요소 라이브러리에 대해 폭넓게 다루었으며, 모든 맥락에서 다음 대규모 프로젝트를 위해 빈 HTML 페이지를 볼 때 자신만의 구성 요소 라이브러리를 구축할지 아니면 존재합니다.
첫 번째 생각은 라이브러리를 구축하면 안 된다고 생각합니다.
저는 일반적으로 검증된 라이브러리를 선택하는 것을 선호합니다. 특히 다음과 같은 특징이 있습니다.
가장 중요한 것은 구성 요소 라이브러리를 사용하여 접근 가능한 구성 요소를 만드는 데 주의를 기울인다는 것입니다.
예를 들어 콤보박스를 생각해 보세요. 검색 입력과 선택 메뉴가 하나로 혼합되어 있습니다. 직접 만든 경우 보기에도 좋고 마우스로 작업할 수도 있습니다. 하지만 다음 사항도 고려해야 합니다.
웹 + 웹 컴포넌트 공간에서 뛰어난 작업을 수행하는 Konnor Rogers는 접근 가능한 콤보박스를 구축한 경험으로 수많은 좌절감을 공유했습니다. 그가 공유한 트윗은 다음과 같습니다.
스크린 리더 지원은 특히 복잡하며 자체 중요 항목 목록만큼 가치가 있습니다. 스크린 리더를 지원하려면 다음도 처리해야 합니다.
참고로 저는 Voiceover에만 액세스할 수 있습니다. 즉, 다양한 스크린 리더를 사용하여 이러한 복잡한 UI 패턴을 테스트하기가 어렵습니다. 브라우저와 마찬가지로 화면 판독기에도 차이가 있습니다. Are We Live? 기사에서 Scott O'Hara는 라이브 영역을 처리하는 방식의 차이에 대해 설명합니다.
즉, 접근성을 염두에 두고 개발되었으며 신뢰할 수 있는 구성 요소 라이브러리를 선택하는 것도 개발자의 몫입니다. 그렇기 때문에 강력한 커뮤니티가 있는 구성 요소 라이브러리를 선택하는 것도 중요합니다. 다음을 수행할 수 있는 것이 중요합니다.
마지막으로 훌륭한 구성 요소 라이브러리는 구성 요소의 미적 측면보다 훨씬 더 많은 것을 고려합니다. 웹용으로 설계된 구성 요소 라이브러리의 경우 다음을 수행하는 것이 가장 좋습니다.
구성 요소 라이브러리를 구축하는 것에 대해 걱정하지 않으셨다면 스스로 모순을 설명하고 자신만의 라이브러리를 구축하는 것이 왜 정말 좋은지 설명하겠습니다.
시간을 들여 구성 요소 라이브러리를 구축하는 데 주의를 기울이면 브라우저 플랫폼, 접근성 모범 사례, 테스트 사례 등을 더 잘 이해하는 개발자가 될 것입니다.
그러나 여기서 그치지 않고 자신만의 라이브러리를 구축해야 하는 몇 가지 훌륭한 이유가 있습니다.
우선, 필요에 맞는 것을 구축하고 기성 구성 요소 라이브러리에서 얻을 수 있는 부풀림을 피할 수 있습니다. 최종 사용자를 이해하는 것은 귀하와 팀의 몫이며, 최종 사용자를 위해 특별히 무언가를 구축할 수 있습니다.
새로운 접근 방식을 실험해 볼 기회도 있습니다. 하이퍼 틈새 문제가 있는 경우 해당 요구 사항을 해결할 수 있는 구성 요소 라이브러리가 없을 수도 있습니다. 다음과 같은 구성 요소 라이브러리가 될 수 있습니다.
이를 통해 귀하의 필요에 맞는 것을 구축할 수 있는 기회가 제공됩니다. 그런 다음 요구 사항이 변경되거나 문제 공간을 더 잘 이해함에 따라 상황을 변경하고 수정할 수 있는 기회를 갖게 됩니다.
중요한 점은 그렇게 하면 웹에 대해 더 많이 배울 수 있다는 것입니다. 구성 요소 라이브러리를 처음 구축하는 경우 HTML 브라우저 사양에 대해 더 자세히 알아보거나 웹 접근성 지식을 복습할 수 있는 기회가 될 수 있습니다. 이는 웹 개발자로서의 능력을 향상시켜 미래의 모든 프런트엔드 프로젝트에서 도움이 될 것입니다. 다음 직장을 구하는 데에도 도움이 될 수 있습니다.
따라서 구성 요소 라이브러리를 구축해야 하는지 여부는 최종 목표에 따라 다릅니다. 다음과 같은 질문을 고려해보세요.
귀하의 답변에 따라 귀하의 프로젝트에 적합한 결정을 내릴 수 있습니다.
읽어주셔서 감사합니다! 자신만의 웹 구성 요소 라이브러리를 구축하는 데 관심이 있다면 내 강좌 Component Odyssey를 확인해 보세요. 모든 프런트엔드 프레임워크에서 작동하는 구성 요소 라이브러리를 구축하고 게시하는 방법을 배우게 됩니다.
위 내용은 구성 요소 라이브러리란 무엇이며 직접 구축해야 합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
