Polymer팀은 지난 1년 동안 개발자에게 자체 요소를 만드는 방법을 가르치는 데 많은 시간을 보냈습니다. 그 결과 Polymer의 Core 및 Paper 요소와 Mozilla팀에서 만든 Brick 요소를 중심으로 빠르게 성장하는 생태계가 조성되었습니다.
개발자가 자체 요소를 만드는 방법을 익히고 애플리케이션 빌드를 고려하기 시작하면 다음과 같은 여러 질문이 생깁니다.
- 애플리케이션의 UI를 어떻게 구조화해야 하나요?
- 여러 상태를 통해 전환하려면 어떻게 해야 하나요?
- 실적을 개선하기 위한 전략에는 어떤 것이 있나요?
- 오프라인 환경은 어떻게 제공해야 하나요?
Chrome Dev Summit에서 저는 작은 연락처 애플리케이션을 빌드하고 빌드하는 과정에서 거친 프로세스를 분석하여 이러한 질문에 답변하려고 했습니다. 다음과 같은 결과를 얻었습니다.
구조
애플리케이션을 결합하고 재사용할 수 있는 모듈식 부분으로 나누는 것은 웹 구성요소의 핵심 원칙입니다. Polymer의 core-* 및 paper-* 요소를 사용하면 paper-toolbar 및 paper-icon-button과 같은 작은 부분으로 쉽게 시작할 수 있습니다.
그리고 컴포지션의 힘을 통해 이를 임의의 수의 요소와 결합하여 애플리케이션 스켈레톤을 만들 수 있습니다.
일반 스켈레톤이 있으면 자체 CSS 스타일을 적용하여 브랜드 고유의 환경으로 변환할 수 있습니다. 구성요소를 사용하여 이를 실행하면 동일한 앱 빌드 프리미티브를 활용하면서 매우 다른 환경을 만들 수 있다는 장점이 있습니다. 스케폴드가 마련되면 콘텐츠에 관해 생각해 볼 수 있습니다.
많은 콘텐츠를 처리하는 데 특히 적합한 요소는 core-list입니다.
core-list는 데이터 소스 (기본적으로 객체 배열)에 연결할 수 있으며 배열의 각 항목에 대해 템플릿 인스턴스를 스탬프합니다. 템플릿 내에서 Polymer의 데이터 결합 시스템을 활용하여 콘텐츠를 빠르게 연결할 수 있습니다.
화면전환
앱의 다양한 섹션을 설계하고 구현했으므로 다음 작업은 섹션 간에 실제로 이동하는 방법을 알아내는 것입니다.
아직 실험용 요소이지만 core-animated-pages는 애플리케이션의 여러 상태 간에 전환하는 데 사용할 수 있는 플러그인 가능한 애니메이션 시스템을 제공합니다.
하지만 애니메이션은 퍼즐의 절반에 불과합니다. 애플리케이션은 이러한 애니메이션을 라우터와 결합하여 URL을 올바르게 관리해야 합니다.
웹 구성요소의 라우팅에는 명령형과 선언형이라는 두 가지 유형이 있습니다. 프로젝트 요구사항에 따라 core-animated-pages를 두 가지 접근 방식과 결합하는 것이 적절할 수 있습니다.
명령형 라우터 (예: Flatiron의 Director)는 일치하는 경로를 리슨한 다음 core-animated-pages에 선택한 항목을 업데이트하도록 지시할 수 있습니다.
이는 경로가 일치한 후 다음 섹션이 전환되기 전에 작업을 실행해야 하는 경우에 유용합니다.
반면 선언적 라우터 (예: app-router)는 실제로 라우팅과 core-animated-pages를 단일 요소로 결합할 수 있으므로 두 가지를 더 효율적으로 관리할 수 있습니다.
더 세부적으로 제어하려면 데이터 결합을 사용하여 core-animated-pages와 결합할 수 있고 두 가지 방법의 장점을 모두 제공할 수 있는 more-routing과 같은 라이브러리를 살펴보세요.
성능
애플리케이션이 형성되면 특히 모바일 웹 애플리케이션에서 가장 느린 부분인 네트워크와 관련된 모든 항목을 포함하여 성능 병목 현상을 주의 깊게 살펴봐야 합니다.
웹 구성요소 폴리필을 조건부로 로드하면 간편하게 성능을 개선할 수 있습니다.
플랫폼에서 이미 모든 기능을 지원하는 경우 그 많은 비용을 지출할 필요가 없습니다. 새로운 webcomponents.js 저장소의 모든 출시에서 폴리필도 독립형 파일로 분할되었습니다. 이는 폴리필의 하위 집합을 조건부로 로드하려는 경우에 유용합니다.
<script>
if ('import' in document.createElement('link')) {
// HTML Imports are supported
} else {
document.write(
'<script src="bower_components/webcomponentsjs/HTMLImports.min.js"><\/script>'
);
}
</script>
Vulcanize와 같은 도구를 통해 모든 HTML 가져오기를 실행하면 네트워크 성능이 크게 향상됩니다.
Vulcanize는 가져오기를 단일 번들로 연결하여 앱에서 실행하는 HTTP 요청 수를 대폭 줄입니다.
오프라인
하지만 성능이 우수한 앱을 빌드한다고 해서 연결이 거의 없거나 전혀 없는 사용자의 딜레마가 해결되지는 않습니다. 즉, 앱이 오프라인에서 작동하지 않으면 진정한 모바일 앱이 아닙니다. 현재는 오해의 소지가 많은 애플리케이션 캐시를 사용하여 리소스를 오프라인 저장할 수 있지만, 앞으로는 서비스 워커를 통해 곧 훨씬 더 나은 오프라인 개발 환경을 제공할 수 있을 것입니다.
제이크 아치볼드가 최근에 멋진 서비스 워커 패턴의 레시피북을 게시했지만, 시작하는 데 도움이 되는 빠른 시작을 소개해 드리겠습니다.
서비스 워커를 설치하는 것은 매우 쉽습니다. worker.js 파일을 만들고 애플리케이션이 부팅될 때 등록합니다.
worker.js를 애플리케이션의 루트에 배치하는 것이 중요합니다. 이렇게 하면 앱의 모든 경로에서 요청을 가로챌 수 있습니다.
작업자의 설치 핸들러에서 앱을 실행하는 데이터를 비롯한 많은 리소스를 캐시합니다.
이렇게 하면 앱이 사용자가 오프라인에서 액세스하는 경우 최소한 대체 환경을 제공할 수 있습니다.
힘차게 전진하세요.
웹 구성요소는 웹 플랫폼에 큰 도움이 되며 아직 초기 단계에 있습니다. 더 많은 브라우저에 제공되면 개발자 커뮤니티에서 애플리케이션을 구성하기 위한 권장사항을 찾아야 합니다. 위의 솔루션은 시작점일 뿐이며 아직 배울 것이 많습니다. 더 나은 앱을 빌드해 보세요.