ในช่วงปีที่ผ่านมา ทีม Polymer ได้ใช้เวลามากมายไปกับการสอนวิธีสร้างองค์ประกอบของตนเองให้แก่นักพัฒนาซอฟต์แวร์ สิ่งนี้นำไปสู่ระบบนิเวศที่เติบโตอย่างรวดเร็ว โดยมีองค์ประกอบหลักๆ ของ Polymer Core and Paper อยู่ในตัว และองค์ประกอบ Brick ที่ทีม Mozilla สร้างขึ้น
เมื่อนักพัฒนาซอฟต์แวร์คุ้นเคยกับการสร้างองค์ประกอบของตนเองมากขึ้นและเริ่มคิดเกี่ยวกับการสร้างแอปพลิเคชัน ก็จะมีคำถามดังนี้
- คุณควรกำหนดโครงสร้าง UI ของแอปพลิเคชันอย่างไร
- คุณจะเปลี่ยนผ่านสถานะต่างๆ อย่างไร
- กลยุทธ์ใดที่ใช้ในการปรับปรุงประสิทธิภาพ
- และคุณควรมอบประสบการณ์การใช้งานออฟไลน์อย่างไร
สำหรับงาน Chrome Dev Summit ฉันได้พยายามตอบคำถามเหล่านี้โดยการสร้างแอปพลิเคชันรายชื่อติดต่อขนาดเล็ก และวิเคราะห์กระบวนการที่ใช้ในการสร้างแอปพลิเคชันดังกล่าว ผลสรุปที่ผมคิดได้มีดังนี้
โครงสร้าง
การแบ่งแอปพลิเคชันออกเป็นส่วนๆ ซึ่งนำมารวมกันและนำมาใช้ใหม่ได้ถือเป็นกลุ่มผู้ใช้หลักของคอมโพเนนต์เว็บ องค์ประกอบแกน* และกระดาษ* ของ Polymer ช่วยให้เริ่มต้นได้ง่ายด้วยองค์ประกอบเล็กๆ เช่น แถบเครื่องมือกระดาษและปุ่มไอคอนกระดาษ
และใช้พลังของการจัดองค์ประกอบ แล้วนำมารวมกันกับองค์ประกอบต่างๆ เพื่อสร้างโครงสร้างการใช้งาน
เมื่อมีนั่งร้านทั่วไปแล้ว คุณก็ใช้รูปแบบ 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
โดยใช้การเชื่อมโยงข้อมูล และอาจทำให้คุณได้ประโยชน์สูงสุดจากทั้ง 2 ฝ่าย
การแสดง
ในขณะที่แอปพลิเคชันของคุณกำลังเริ่มก่อตัวขึ้น คุณจะต้องคอยระวังเรื่องคอขวดด้านประสิทธิภาพ โดยเฉพาะสิ่งที่เกี่ยวกับเครือข่าย เนื่องจากมักจะเป็นส่วนที่ช้าที่สุดของเว็บแอปพลิเคชันบนอุปกรณ์เคลื่อนที่
ชัยชนะด้านประสิทธิภาพได้ง่ายๆ มาจากการโหลด Polyfill ของ Web Elements แบบมีเงื่อนไข
ไม่มีเหตุผลที่ทำให้เกิดค่าใช้จ่ายดังกล่าวหากแพลตฟอร์มมีการรองรับเต็มรูปแบบอยู่แล้ว นอกจากนี้ ในที่เก็บ webcomponents.js รุ่นใหม่ทุกครั้ง ระบบจะแบ่ง polyfill ออกเป็นไฟล์เดี่ยวๆ ด้วย วิธีนี้มีประโยชน์หากคุณต้องการโหลดชุดย่อยของ 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 ที่แอปสร้างขึ้นอย่างมาก
ออฟไลน์
แต่การสร้างแอปที่มีประสิทธิภาพไม่ได้แก้ปัญหาที่วุ่นวายของผู้ใช้ที่มีการเชื่อมต่อน้อยหรือไม่มีเลย กล่าวอีกนัยหนึ่งคือ หากแอปไม่ทำงานแบบออฟไลน์ ก็แปลว่าแอปไม่ใช่แอปบนอุปกรณ์เคลื่อนที่จริงๆ วันนี้คุณสามารถใช้แคชของแอปพลิเคชันที่ไม่เหมาะสมมากเพื่อทำให้ทรัพยากรของคุณออฟไลน์ แต่ในอนาคต Service Worker ควรจะทำให้การพัฒนาการทำงานออฟไลน์ดีขึ้นในไม่ช้า
Jake Archibald ได้เผยแพร่ตำราอาหารสำหรับรูปแบบ Service Worker ที่น่าทึ่งไปเมื่อเร็วๆ นี้ แต่ฉันจะแนะนำวิธีเริ่มต้นง่ายๆ ให้คุณ ดังนี้
การติดตั้ง Service Worker นั้นทำได้ง่าย สร้างไฟล์ worker.js
และลงทะเบียนเมื่อแอปพลิเคชันเริ่มทำงาน
คุณต้องหา worker.js
ในรูทของแอปพลิเคชันเพื่อให้สามารถสกัดกั้นคำขอจากเส้นทางต่างๆ ในแอปได้
ในเครื่องจัดการการติดตั้งของคนงาน ฉันจะแคชจำนวนทรัพยากรบนเรือ (รวมถึงข้อมูลที่ขับเคลื่อนแอป)
การดำเนินการนี้ช่วยให้แอปของฉันมอบประสบการณ์การใช้งานทางเลือก (หากมี) ให้ผู้ใช้เข้าถึงได้แบบออฟไลน์
ต่อไป
คอมโพเนนต์เว็บเป็นส่วนเติมเต็มที่สำคัญให้กับแพลตฟอร์มเว็บและยังคงอยู่ในช่วงเริ่มต้น เมื่อมีการใช้เบราว์เซอร์มากขึ้นเรื่อยๆ เราเองที่เป็นชุมชนนักพัฒนาซอฟต์แวร์จะต้องเป็นผู้คิดหาแนวทางปฏิบัติที่ดีที่สุดในการจัดโครงสร้างแอปพลิเคชันของเรา วิธีแก้ปัญหาข้างต้นเป็นจุดเริ่มต้นให้เรา แต่ยังมีอีกหลายสิ่งที่ต้องเรียนรู้ เดินหน้าต่อไปเพื่อสร้างแอปที่ดีขึ้น