작년 한 해 동안 Polymer 팀은 개발자에게 자체 요소를 만드는 방법을 가르치는 데 많은 시간을 보냈습니다. 그 결과, 폴리머의 Core and Paper와 Mozilla 팀이 만든 Brick 요소가 큰 부분을 차지하며 생태계가 빠르게 성장하고 있습니다.
개발자가 자신만의 요소를 만드는 데 더 익숙해지고 애플리케이션 빌드를 고려하기 시작하면서 다음과 같은 여러 가지 질문들이 제기됩니다.
- 애플리케이션의 UI를 어떻게 구조화해야 할까요?
- 여러 상태 간에 전환하려면 어떻게 해야 하나요?
- 실적 개선을 위한 전략은 무엇인가요?
- 그렇다면 오프라인 경험을 제공하려면 어떻게 해야 할까요?
저는 Chrome Dev Summit에서 소규모 주소록 애플리케이션을 빌드하고 빌드 과정을 분석하여 이러한 질문에 답하고자 했습니다. 생각해 낸 내용은 다음과 같습니다.
구조
웹 구성요소의 핵심 테넌트는 애플리케이션을 결합하고 재사용할 수 있는 모듈식으로 분할하는 것입니다. Polymer의 core-* 및 background-* 요소를 사용하면 core-툴바 및 paper-icon-button과 같은 작은 조각으로 쉽게 시작할 수 있습니다.
...컴포지션의 힘을 활용해 여러 요소와 결합하여 애플리케이션 스캐폴드를 만들어 보세요.
일반 스캐폴드가 준비되면 자체 CSS 스타일을 적용하여 브랜드 고유의 환경으로 변환할 수 있습니다. 구성요소를 사용하여 이렇게 하면 동일한 앱 빌드 기본 요소를 활용하면서 매우 다양한 환경을 만들 수 있다는 장점이 있습니다. 스캐폴드가 마련되어 있으면 콘텐츠에 대해 생각할 수 있습니다.
많은 콘텐츠를 처리하는 데 특히 적합한 요소 중 하나는 core-list입니다.
core-list는 데이터 소스 (기본적으로 객체의 배열)에 연결할 수 있으며 배열의 각 항목에 대해 템플릿 인스턴스를 스탬프 처리합니다. 템플릿 내에서 Polymer의 데이터 결합 시스템을 활용하여 콘텐츠를 빠르게 연결할 수 있습니다.
화면전환
앱의 다양한 섹션을 설계하고 구현한 상태에서 다음 작업은 섹션 사이를 실제로 이동하는 방법을 파악하는 것입니다.
아직 실험 요소이긴 하지만 core-animated-pages는 애플리케이션의 여러 상태 간에 전환하는 데 사용할 수 있는 플러그형 애니메이션 시스템을 제공합니다.
그러나 애니메이션은 퍼즐의 절반에 불과합니다. 애플리케이션은 URL을 적절히 관리하기 위해 이러한 애니메이션을 라우터와 결합해야 합니다.
웹 구성요소 라우팅의 경우 명령적 라우팅과 선언적 라우팅이라는 두 가지 유형이 있습니다. 프로젝트 요구사항에 따라 core-animated-pages와 두 접근 방식을 결합하는 것도 유효할 수 있습니다.
명령형 라우터 (예: Flatiron의 디렉터)는 일치하는 경로를 수신 대기한 다음 core-animated-pages에 선택된 항목을 업데이트하도록 지시할 수 있습니다.
이 방법은 경로 일치 후와 다음 섹션이 전환되기 전에 작업을 수행해야 하는 경우 유용할 수 있습니다.
반면 선언적 라우터 (예: app-router)는 실제로 라우팅과 core-animated-pages를 단일 요소로 결합할 수 있으므로 둘을 더 편리하게 관리할 수 있습니다.
더 세밀하게 제어하려면 more-route와 같은 라이브러리를 참고하세요. 이 라이브러리는 데이터 결합을 사용하여 core-animated-pages와 결합할 수 있고 두 가지 이점을 모두 제공할 수 있습니다.
성능
애플리케이션이 형성됨에 따라 성능 병목 현상, 특히 네트워크와 관련된 모든 요소에 주의를 기울여야 합니다. 모바일 웹 애플리케이션에서 가장 속도가 느린 부분인 경우가 많기 때문입니다.
웹 구성요소 폴리필을 조건부로 로드하면 쉽게 성능을 얻을 수 있습니다.
플랫폼에서 이미 완벽한 지원을 받고 있다면 그 많은 비용이 발생할 이유가 없습니다. 새로운 webcomponents.js 저장소의 모든 출시 버전에서 polyfill도 독립형 파일로 분리되었습니다. 이는 폴리필의 하위 집합을 조건부로 로드하려는 경우에 유용합니다.
<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를 찾는 것이 중요합니다. 이렇게 하면 앱의 모든 경로에서 요청을 가로챌 수 있습니다.
작업자의 설치 핸들러에서 수많은 리소스 (앱에 사용되는 데이터 포함)를 캐시합니다.
이렇게 하면 앱에서 사용자가 오프라인으로 액세스하는 경우 최소한 대체 환경을 제공할 수 있습니다.
힘차게 전진하세요.
웹 구성 요소는 웹 플랫폼에 많이 추가된 기능이며 아직 초기 단계입니다. 더 많은 브라우저를 사용하게 됨에 따라 애플리케이션 구조화를 위한 모범 사례를 파악하는 것은 개발자 커뮤니티인 Google의 몫입니다. 위의 솔루션은 시작점을 제공하지만 아직 배울 것이 더 많이 있습니다. 더 나은 앱을 개발하기 위한 노력에 동참해 주세요