ในช่วงปีที่ผ่านมา ทีม Polymer ใช้เวลาอย่างมากในการสอนวิธีสร้างองค์ประกอบของตัวเองให้กับนักพัฒนาซอฟต์แวร์ การทำเช่นนี้นำไปสู่ระบบนิเวศที่เติบโตอย่างรวดเร็ว โดยมีองค์ประกอบแกนและกระดาษของ Polymer รวมถึงองค์ประกอบที่เป็นอิฐที่ทีม Mozilla สร้างขึ้น
เมื่อนักพัฒนาซอฟต์แวร์คุ้นเคยกับการสร้างองค์ประกอบของตนเองมากขึ้นและเริ่มคิดเกี่ยวกับการสร้างแอปพลิเคชัน ก็จะมีคำถามดังนี้
- คุณควรจัดโครงสร้าง UI ของแอปพลิเคชันอย่างไร
- คุณจะเปลี่ยนผ่านสถานะต่างๆ อย่างไร
- กลยุทธ์ในการปรับปรุงประสิทธิภาพมีอะไรบ้าง
- และคุณควรมอบประสบการณ์การใช้งานออฟไลน์อย่างไร
ในงาน Chrome Dev Summit ผมได้พยายามตอบคำถามเหล่านี้ด้วยการสร้างแอปพลิเคชันรายชื่อติดต่อขนาดเล็ก และวิเคราะห์ขั้นตอนที่ใช้ในการสร้างแอปพลิเคชันดังกล่าว ข้อมูลที่ฉันได้มีดังนี้
โครงสร้าง
การแยกแอปพลิเคชันออกเป็นส่วนต่างๆ ที่สามารถนำมารวมกันและนำมาใช้ใหม่ได้ถือเป็นกลุ่มผู้ใช้หลักของคอมโพเนนต์ของเว็บ องค์ประกอบแกน* และกระดาษ* ของ Polymer ช่วยให้เริ่มต้นได้ง่ายด้วยชิ้นส่วนเล็กๆ เช่น core-toolbar และ paper-icon-button...
...และด้วยพลังของการจัดวางองค์ประกอบ ให้รวมองค์ประกอบเหล่านั้นเข้ากับองค์ประกอบหลายๆ อย่างเพื่อสร้างโครงสร้างการประยุกต์ใช้
เมื่อมีโครงสร้างทั่วไปแล้ว คุณก็สามารถใช้รูปแบบ CSS ของตนเองเพื่อเปลี่ยนรูปแบบให้ประสบการณ์การใช้งานที่เฉพาะตัวสำหรับแบรนด์ของคุณ ข้อดีของการทำเช่นนี้โดยใช้คอมโพเนนต์คือ ช่วยให้คุณสร้างประสบการณ์ที่แตกต่างกันอย่างมาก ในขณะเดียวกันก็ใช้ประโยชน์จากพื้นฐานการสร้างแอปเดียวกันได้ การวางโครงสร้างไว้จะช่วยให้คุณเริ่มคิดเกี่ยวกับเนื้อหาได้
องค์ประกอบหนึ่งที่เหมาะสมอย่างยิ่งสำหรับการจัดการเนื้อหาจำนวนมากก็คือ core-list
core-list เชื่อมต่อกับแหล่งข้อมูลได้ (โดยพื้นฐานแล้วจะเป็นอาร์เรย์ของออบเจ็กต์) และสําหรับแต่ละรายการในอาร์เรย์ก็จะประทับอินสแตนซ์เทมเพลต ภายในเทมเพลตนี้ คุณใช้ประโยชน์จากระบบการเชื่อมโยงข้อมูลของ Polymer เพื่อต่อสายเนื้อหาได้อย่างรวดเร็ว
การเปลี่ยนฉาก
ด้วยส่วนต่างๆ ของแอปที่ออกแบบและนำมาใช้ งานถัดไปคือการหาวิธีไปยังส่วนต่างๆ ของแอป
แม้ว่าจะยังเป็นองค์ประกอบทดลอง core-animated-pages แต่ก็มีระบบภาพเคลื่อนไหวที่เสียบปลั๊กได้ซึ่งใช้เพื่อเปลี่ยนไปมาระหว่างสถานะต่างๆ ในแอปพลิเคชันของคุณได้
แต่ภาพเคลื่อนไหวเป็นเพียงครึ่งหนึ่งของจิ๊กซอว์เท่านั้น แอปพลิเคชันจำเป็นต้องรวมภาพเคลื่อนไหวเหล่านั้นเข้ากับเราเตอร์เพื่อจัดการ URL อย่างเหมาะสม
ในโลกของการกำหนดเส้นทางคอมโพเนนต์เว็บมี 2 ประเภท คือ บังคับและประกาศ การรวม core-animated-pages กับแนวทางใดวิธีการหนึ่งอาจใช้งานได้ ทั้งนี้ขึ้นอยู่กับความต้องการของโปรเจ็กต์
เราเตอร์ที่จำเป็น (เช่น Flatiron's Director) จะคอยฟังเส้นทางที่ตรงกัน จากนั้นแจ้งให้ core-animated-pages อัปเดตรายการที่เลือกไว้
ซึ่งจะเป็นประโยชน์หากคุณต้องทำงานบางอย่างหลังจากเส้นทางที่ตรงกันและก่อนที่จะมีการเปลี่ยนส่วนถัดไป
ในทางตรงกันข้าม เราเตอร์ประกาศ (เช่น app-router) สามารถรวมการกำหนดเส้นทางและ core-animated-pages เป็นองค์ประกอบเดียวได้ จึงช่วยให้การจัดการทั้ง 2 อย่างมีประสิทธิภาพยิ่งขึ้น
หากต้องการการควบคุมที่ละเอียดยิ่งขึ้น คุณสามารถดูไลบรารีอย่างเช่น การหาเส้นทางเพิ่มเติม ซึ่งสามารถใช้ร่วมกับ core-animated-pages โดยใช้การเชื่อมโยงข้อมูล และอาจทำให้คุณได้รับประโยชน์จากทั้งสองโลก
การแสดง
เมื่อแอปพลิเคชันของคุณเริ่มก่อตัวขึ้นแล้ว คุณจะต้องคอยจับตาดูจุดคอขวดด้านประสิทธิภาพ โดยเฉพาะสิ่งที่เกี่ยวกับเครือข่าย เนื่องจากมักจะเป็นส่วนที่ช้าที่สุดของเว็บแอปพลิเคชันบนอุปกรณ์เคลื่อนที่
ชัยชนะด้านประสิทธิภาพอย่างง่ายได้มาจากการโหลด Polyfill ของ Web Components อย่างมีเงื่อนไข
ไม่มีเหตุผลที่จะก่อให้เกิดค่าใช้จ่ายทั้งหมด หากแพลตฟอร์มมีการรองรับอย่างเต็มรูปแบบอยู่แล้ว นอกจากนี้ ในที่เก็บ webcomponents.js ใหม่ทุกเวอร์ชัน polyfills ยังถูกแยกออกเป็นไฟล์เดี่ยวๆ อีกด้วย วิธีนี้มีประโยชน์หากคุณต้องการโหลดชุดย่อยของ 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>
นอกจากนี้ ยังได้รับประโยชน์จากเครือข่ายจากการเรียกใช้การนำเข้า HTML ทั้งหมดผ่านเครื่องมืออย่าง Vulcanize
Vulcanize จะเชื่อมต่อการนำเข้าของคุณไปยังแพ็กเกจเดียว ซึ่งช่วยลดจำนวนคำขอ HTTP ที่แอปสร้างได้อย่างมาก
ออฟไลน์
แต่การสร้างแอปที่มีประสิทธิภาพไม่ได้แก้ปัญหาที่ยุ่งยากสำหรับผู้ใช้ที่มีการเชื่อมต่อน้อยหรือไม่มีเลย กล่าวคือ หากแอปของคุณไม่ทำงานแบบออฟไลน์ ก็แสดงว่าไม่ใช่แอปบนอุปกรณ์เคลื่อนที่จริงๆ วันนี้คุณสามารถใช้แคชของแอปพลิเคชันที่ไม่เหมาะสมอย่างมากเพื่อจัดเก็บทรัพยากรแบบออฟไลน์ แต่เมื่อมองไปถึงอนาคต โปรแกรมทำงานของบริการน่าจะช่วยให้การพัฒนาการทำงานออฟไลน์ดีขึ้นในไม่ช้า
Jake Archibald เพิ่งเผยแพร่ตำราอาหารที่น่าทึ่งเกี่ยวกับรูปแบบของโปรแกรมทำงานของบริการ แต่ฉันจะขอแนะนำวิธีเริ่มต้นคร่าวๆ ให้คุณดังนี้
การติดตั้ง Service Worker นั้นทำได้ง่าย สร้างไฟล์ worker.js และลงทะเบียนเมื่อแอปพลิเคชันเริ่มทำงาน
คุณควรระบุตำแหน่ง worker.js ในรูทของแอปพลิเคชัน ซึ่งจะทำให้แอปสกัดกั้นคำขอจากเส้นทางต่างๆ ในแอปได้
ในตัวแฮนเดิลการติดตั้งของผู้ปฏิบัติงาน ฉันแคชทรัพยากรต่างๆ บนเรือ (รวมถึงข้อมูลที่ขับเคลื่อนแอป)
การดำเนินการนี้ช่วยให้แอปของฉันมอบประสบการณ์การใช้งานสำรองแก่ผู้ใช้ได้เป็นอย่างน้อยในกรณีที่เข้าถึงแอปแบบออฟไลน์
ต่อไป!
คอมโพเนนต์เว็บเป็นส่วนเพิ่มเติมสำคัญของแพลตฟอร์มเว็บและยังคงอยู่ในช่วงเริ่มต้น เมื่อมีการเปลี่ยนไปใช้เบราว์เซอร์อื่นๆ มากขึ้น เราซึ่งเป็นชุมชนนักพัฒนาซอฟต์แวร์จะต้องเป็นผู้คิดหาแนวทางปฏิบัติที่ดีที่สุดในการกำหนดโครงสร้างแอปพลิเคชันของเรา วิธีแก้ปัญหาข้างต้นเป็นจุดเริ่มต้นให้กับเรา แต่ยังมีอะไรอีกมากมายให้เรียนรู้ ต่อไปเพื่อสร้างแอปที่ดีขึ้น