8 ข้อผิดพลาดที่พบบ่อยที่สุดที่นักพัฒนาซอฟต์แวร์ Backbone.js ทำ

Backbone.js เป็นเฟรมเวิร์กที่เรียบง่ายซึ่งมีจุดมุ่งหมายเพื่อจัดเตรียมชุดโครงสร้างข้อมูลและคุณลักษณะอย่างง่ายที่คุณสามารถใช้เพื่อสร้างส่วนหน้าของเว็บแอปพลิเคชันที่มีโครงสร้าง ส่วนประกอบต่างๆ ของ Backbone.js ที่นำออกจากกล่องมีสภาพแวดล้อมที่ใช้งานง่าย ซึ่งคุณอาจคุ้นเคยอยู่แล้วเมื่อใช้งานโมเดลและมุมมองในส่วนแบ็คเอนด์ โมเดลและคอลเล็กชันใน Backbone.js นั้นเรียบง่าย แต่มาพร้อมคุณสมบัติที่มีประโยชน์มากมาย เช่น ตัวเลือกในการผสานรวมกับ REST JSON API อย่างง่ายดาย แต่ยังมีความยืดหยุ่นเพียงพอที่จะปรับให้เข้ากับการใช้งานจริงแทบทุกประเภท

ในบทช่วยสอน Backbone.js นี้ เราจะมาดูข้อผิดพลาดทั่วไปที่มักเกิดขึ้นโดยนักพัฒนาอิสระที่เริ่มเรียนรู้ Backbone.js เป็นครั้งแรกและวิธีหลีกเลี่ยง

ข้อผิดพลาด #1: ละเว้นฟังก์ชัน Arsenal ของ Backbone.js

Backbone.js อาจเป็นเฟรมเวิร์กที่เรียบง่าย แต่ (พร้อมกับ Underscore.js) มีคุณสมบัติและฟังก์ชันมากมายเหลือเฟือที่สามารถครอบคลุมความต้องการขั้นพื้นฐานและสำคัญบางอย่างที่เกิดขึ้นเมื่อพัฒนาเว็บแอปพลิเคชันสมัยใหม่ได้อย่างง่ายดาย ข้อผิดพลาดทั่วไปอย่างหนึ่งที่นักพัฒนามือใหม่มักทำคือพวกเขานำ Backbone.js มาเป็นเฟรมเวิร์กไคลเอนต์ที่เหมือน MVC อีกตัวสำหรับเว็บ แม้ว่าส่วนนี้จะพูดถึงบางสิ่งที่ชัดเจนมาก แต่เมื่อพูดถึง Backbone.js การไม่สำรวจกรอบงานอย่างละเอียดถือเป็นข้อผิดพลาดที่สำคัญอย่างยิ่ง กรอบงานอาจมีขนาดเล็ก แต่นี่คือสิ่งที่ทำให้เป็นตัวเลือกที่ยอดเยี่ยมสำหรับการสำรวจอย่างละเอียดนี้ โดยเฉพาะอย่างยิ่งซอร์สโค้ดที่มีขนาดเล็กและมีคำอธิบายประกอบที่สวยงาม

Backbone.js ให้โครงสร้างขั้นต่ำที่จำเป็นเพื่อให้เว็บแอปพลิเคชันของคุณมีโครงสร้างที่จะได้รับประโยชน์ ด้วยความสามารถในการขยายและปลั๊กอินมากมาย การเรียนรู้ Backbone.js สามารถใช้สร้างเว็บแอปพลิเคชันที่น่าทึ่งได้ ฟีเจอร์ที่ชัดเจนที่สุดของ Backbone.js แสดงให้เห็นผ่านโมเดล คอลเลกชั่น และมุมมอง ส่วนประกอบของเราเตอร์และประวัติมีกลไกที่เรียบง่ายแต่สวยงามเพื่อรองรับการกำหนดเส้นทางฝั่งไคลเอ็นต์ แม้ว่า Underscore.js จะต้องพึ่งพา Backbone.js แต่ก็ถูกรวมเข้ากับเฟรมเวิร์กได้เป็นอย่างดี เนื่องจากทั้งโมเดลและคอลเลกชั่นได้รับประโยชน์มากมายจากยูทิลิตี้อันน่าทึ่งนี้สำหรับ JavaScript และยังพร้อมให้คุณใช้งานอีกด้วย

ซอร์สโค้ดของเฟรมเวิร์กนั้นเขียนไว้อย่างดีและมีคำอธิบายประกอบ ซึ่งอาจมีคนอ่านทั้งหมดได้ในขณะดื่มกาแฟ ผู้เริ่มต้นจะได้รับประโยชน์มากมายจากการอ่านคำอธิบายประกอบที่มา เนื่องจากพวกเขาสามารถเรียนรู้มากมายเกี่ยวกับวิธีการทำงานของเฟรมเวิร์กภายใน และยังนำชุดแนวทางปฏิบัติที่ดีที่สุดมาใช้ใน JavaScript อีกด้วย

ข้อผิดพลาด #2: การปรับเปลี่ยน DOM ในการตอบสนองโดยตรงต่อเหตุการณ์ตามอำเภอใจ

สิ่งที่เรามักจะทำเมื่อเราเริ่มเรียนรู้ Backbone.js เป็นครั้งแรกคือไม่ทำสิ่งที่แนะนำโดย Backbone.js ตัวอย่างเช่น เรามักจะจัดการกับเหตุการณ์และดูการอัปเดตในแบบที่เราทำกับ jQuery บนเว็บไซต์ทั่วไป Backbone.js มีวัตถุประสงค์เพื่อให้เว็บแอปพลิเคชันของคุณมีโครงสร้างที่เข้มงวดผ่านการแยกข้อกังวลอย่างเหมาะสม สิ่งที่เรามักจะทำกับ Backbone.js คือการอัปเดตมุมมองเพื่อตอบสนองต่อเหตุการณ์ DOM โดยพลการ:

 var AudioPlayerControls = Backbone.View.extend({ events: { 'click .btn-play, .btn-pause': function(event) { $(event.target).toggleClass('btn-play btn-pause') } }, // ... })

นี่คือสิ่งที่ควรหลีกเลี่ยงในทุกกรณี อาจเป็นไปได้ที่จะสร้างตัวอย่างที่คลุมเครือซึ่งอาจสมเหตุสมผล แต่ในกรณีส่วนใหญ่ มีวิธีที่ดีกว่านี้มาก อันที่จริง วิธีหนึ่งที่ฉันอาจยกตัวอย่างได้คือการใช้โมเดลเพื่อติดตามสถานะของเครื่องเล่นเสียง และใช้ข้อมูลสถานะนั้นเพื่อแสดงปุ่ม (หรือเฉพาะเจาะจงมากกว่านี้ชื่อคลาส):

 var AudioPlayerControls = Backbone.View.extend({ events: { 'click .btn-play, .btn-pause': function(event) { this.model.set('playing', !this.model.get('playing')) } }, initialize: function() { this.listenTo(this.model, 'change', this.render) this.render() }, // ... })

 <button class=”btn btn-<%- playing ? 'pause' : 'play' %>”></button>

อาจมีบางสถานการณ์ที่ไม่ค่อยเกิดขึ้นที่การจัดการ DOM จากตัวจัดการเหตุการณ์โดยตรงจะสมเหตุสมผล แต่ต้นทุนที่เกี่ยวข้องกับการจัดการการจัดการ DOM ที่ซับซ้อนจากตัวจัดการเหตุการณ์นั้นแทบจะไม่คุ้มค่าเลย นี่คือสิ่งที่ Backbone.js มุ่งหวังที่จะแก้ไข การใช้ Backbone.js เพื่อทำสิ่งนี้ถือเป็นความผิดพลาด

ข้อผิดพลาด #3: การประเมินต้นทุนการแสดงผลต่ำไป

เนื่องจาก Backbone.js ทำให้ง่ายต่อการเรนเดอร์และเรนเดอร์ DOM อีกครั้งตามต้องการหรือเพื่อตอบสนองต่อเหตุการณ์ เรามักจะมองข้ามผลกระทบที่เกิดขึ้นกับประสิทธิภาพโดยรวมของเว็บแอปพลิเคชัน มีหลายวิธีที่เราสามารถลงเอยด้วยวิธีการเรนเดอร์ในมุมมองของเรา บ่อยครั้งสิ่งนี้อาจดูเหมือนไม่มากนัก เนื่องจากเว็บเบราว์เซอร์สมัยใหม่กำลังกลายเป็นซอฟต์แวร์ที่มีประสิทธิภาพสูง แต่เมื่อเว็บแอปพลิเคชันเติบโตขึ้น และปริมาณข้อมูลที่เกี่ยวข้องก็เพิ่มขึ้น ประสิทธิภาพการทำงานที่ลดลงก็ชัดเจนขึ้นเรื่อยๆ

เราสามารถเห็นสิ่งนี้ในการดำเนินการผ่านตัวอย่างที่ประดิษฐ์ขึ้นโดยที่เราเริ่มต้นด้วยคอลเล็กชันโมเดลขนาดเล็กและแสดงผลเป็นมุมมองรายการ:

 var AudioPlayerPlaylist = Backbone.View.extend({ template: _.template('<ul> <% _.each(musics, function(m) { %> <li><%- m.title %></li> <% }) %> </ul>'), initialize: function() { this.listenTo(this.collection, 'add', this.render) }, // ... })

ในตัวอย่าง Backbone.js นี้ เรากำลังแสดงผลใหม่ทุกครั้งที่มีการเพิ่มโมเดลลงในคอลเล็กชัน สิ่งนี้จะทำงานได้ดี อย่างไรก็ตาม เนื่องจากเหตุการณ์ "เพิ่ม" เริ่มทำงานทุกครั้งที่มีการเพิ่มโมเดลลงในรายการ ลองนึกภาพการดึงรายการโมเดลจำนวนมากจากเซิร์ฟเวอร์ วิธีการเรนเดอร์จะถูกเรียกใช้หลายครั้งติดต่อกัน หนึ่งครั้งสำหรับทุกโมเดลในการตอบกลับจากเซิร์ฟเวอร์ โมเดลขนาดใหญ่เพียงพอจะทำให้แอปพลิเคชันของคุณติดขัดและทำลายประสบการณ์การใช้งานของผู้ใช้ บางครั้งการตอบสนองเพียงเล็กน้อยก็เพียงพอแล้ว ขึ้นอยู่กับความซับซ้อนของมุมมองที่กำลังแสดงผล

วิธีแก้ปัญหาที่รวดเร็วมากคืออย่าเรียกวิธีการเรนเดอร์สำหรับทุกรุ่นที่เพิ่มเข้ามา ในสถานการณ์เช่นนี้ โมเดลจะถูกเพิ่มในชุดงาน และคุณสามารถทำอะไรบางอย่างเพื่อทำให้วิธีการเรนเดอร์เริ่มทำงานก็ต่อเมื่อมีการเรียกใช้งานเท่านั้น แต่จะไม่เรียกซ้ำภายในระยะเวลาที่กำหนด Underscore.js การพึ่งพาของ Backbone.js มาพร้อมกับฟังก์ชันยูทิลิตี้ที่สะดวกสำหรับสิ่งนี้: “_.debounce” สิ่งที่คุณต้องทำคือเปลี่ยนบรรทัด JavaScript ที่ผูกเหตุการณ์ด้วยสิ่งนี้:

 this.listenTo(this.collection, 'add', _.debounce(_.bind(this.render), 128))

สิ่งนี้จะทำให้การเรียกกลับของเหตุการณ์เริ่มทำงานทุกครั้งที่เกิดเหตุการณ์ "เพิ่ม" อย่างไรก็ตาม จะรอ 128 มิลลิวินาทีจากเหตุการณ์สุดท้ายก่อนที่จะเรียกใช้เมธอดการเรนเดอร์จริง

ในกรณีส่วนใหญ่ การดำเนินการนี้จะถือเป็นวิธีแก้ปัญหาแบบรวดเร็ว อันที่จริง มีวิธีที่เหมาะสมกว่าในการหลีกเลี่ยงการแสดงภาพแบบฟาดฟัน นักพัฒนาที่อยู่เบื้องหลัง Trello เคยเขียนบล็อกโพสต์ที่พูดคุยเกี่ยวกับประสบการณ์และแนวทางในการปรับปรุงประสิทธิภาพการเรนเดอร์ขณะใช้ Backbone.js

ข้อผิดพลาด #4: การปล่อยให้ผู้ฟังเหตุการณ์ถูกผูกมัดเกินกว่าการใช้งาน

การปล่อยให้ตัวฟังเหตุการณ์ที่ไม่ได้ใช้งานถูกผูกไว้อาจเป็นสิ่งที่สามารถเกิดขึ้นได้ ไม่ว่าคุณจะใช้เฟรมเวิร์ก JavaScript ใด หรือคุณใช้อย่างใดอย่างหนึ่งเลย แม้ว่า Backbone.js จะทำให้หลีกเลี่ยงปัญหานี้ได้ง่าย แต่ก็ยังเป็นความผิดพลาดอย่างแน่นอนที่จะปล่อยให้ช่องโหว่ที่อาจเกิดการรั่วไหลของหน่วยความจำได้ง่ายในเว็บแอปพลิเคชันของคุณ ส่วนประกอบ "เหตุการณ์" ของ Backbone.js เป็นการใช้งานที่ค่อนข้างเรียบร้อย ช่วยให้ออบเจ็กต์ JavaScript สามารถใช้คุณลักษณะตามเหตุการณ์ได้อย่างง่ายดาย เนื่องจากจำนวนการดูมักเกิดขึ้นที่กิจกรรมส่วนใหญ่ของเรา จึงเป็นเรื่องง่ายที่จะทำผิดพลาดที่นั่น:

 var AudioPlayerControl = Backbone.View.extend({ initialize: function() { this.model.on('change', _.bind(this.render, this)) // ... }, // ... })

เส้นผูกเหตุการณ์ในตัวอย่างโค้ดนี้ไม่แตกต่างจากตัวอย่างแรกมากนัก ทั้งหมดที่เราทำที่นี่คือเราได้เปลี่ยน “this.listenTo(this.model, …)” เป็น “this.model.on(…)” เนื่องจากเราคุ้นเคยกับการเรียก ".on()" มากสำหรับการเชื่อมโยงเหตุการณ์จากประสบการณ์ของเรากับเฟรมเวิร์กและไลบรารี JavaScript อื่นๆ เมื่อเราเริ่มใช้ Backbone.js เรามักจะใช้การเรียก ".on()" เพื่อผูก เหตุการณ์ สิ่งนี้น่าจะใช้ได้ เฉพาะในกรณีที่เราสนใจที่จะเรียก “.off()” เพื่อยกเลิกการเชื่อมโยงตัวจัดการเหตุการณ์เมื่อไม่จำเป็นอีกต่อไป แต่เราไม่ค่อยทำอย่างนั้น และมันกลายเป็นที่มาของหน่วยความจำรั่ว

Backbone.js เสนอวิธีง่ายๆ ในการแก้ปัญหานี้ โดยใช้วิธีการ “object.listenTo()” ซึ่งจะช่วยให้วัตถุที่คุณเรียกใช้ "listenTo()" สามารถติดตามเหตุการณ์ที่กำลังฟังอยู่ และยังทำให้ง่ายต่อการยกเลิกการเชื่อมโยงเหตุการณ์ทั้งหมดพร้อมกัน ตัวอย่างเช่น มุมมองจะหยุดฟังเหตุการณ์ที่ผูกไว้ทั้งหมดโดยอัตโนมัติทันทีที่คุณเรียกใช้ "remove()"

ข้อผิดพลาด #5: การสร้างมุมมองเสาหิน

หากคุณลองคิดดู ความเรียบง่ายของ Backbone.js ให้ความยืดหยุ่นอย่างมากกับวิธีที่คุณต้องการออกแบบส่วนหน้าของเว็บแอปพลิเคชันของคุณ ด้วยโมเดล คอลเลกชั่น และมุมมองที่เป็นส่วนประกอบสำคัญของส่วนประกอบของคุณ คุณจึงต้องรักษาให้น้ำหนักเบาและเฉพาะเจาะจงที่สุดเท่าที่จะทำได้ บ่อยครั้ง มุมมองที่กลายเป็นส่วนที่หนักที่สุดของเว็บแอปพลิเคชันของคุณในแง่ของโค้ด แต่มันสำคัญมากที่คุณจะไม่จบลงด้วยการสร้างมุมมองเสาหินขนาดยักษ์ที่พยายามทำทุกอย่างที่แอปพลิเคชันของคุณมีให้ แทนที่จะสร้างมุมมอง “AudioPlayer” ขนาดยักษ์ที่มีตรรกะทั้งหมดอัดแน่นอยู่ในนั้น ให้แยกออกเป็นมุมมองเชิงตรรกะจำนวนหนึ่ง เช่น มุมมองสำหรับเพลย์ลิสต์ มุมมองสำหรับตัวควบคุม มุมมองสำหรับวิชวลไลเซอร์ และอื่นๆ คุณต้องการให้ความละเอียดที่ละเอียดเพียงใดนั้นขึ้นอยู่กับแอปพลิเคชันที่คุณพยายามสร้าง

นั่นเป็นเพราะว่าด้วยมุมมองที่ละเอียด ซึ่งแต่ละมุมมองทำสิ่งที่เฉพาะเจาะจงและถูกต้อง การพัฒนาเว็บแอปพลิเคชันด้วย Backbone.js กลายเป็นเรื่องง่าย รหัสของคุณควรสามารถบำรุงรักษาได้มากกว่านี้และง่ายต่อการขยายหรือแก้ไขในอนาคต จากนั้นก็มีอีกขั้นหนึ่งที่คุณต้องทำมากเกินไป มุมมอง Backbone.js ได้รับการออกแบบมาเพื่อให้สะดวกสำหรับคุณในการทำงานกับโมเดลหรือคอลเล็กชัน และอาจใช้เป็นคำแนะนำว่าคุณควรจัดโครงสร้างแอปพลิเคชันของคุณอย่างไร Ian Storm Taylor แบ่งปันแนวคิดอันมีค่าในบล็อกของเขาซึ่งคุณควรจำไว้ในขณะที่ใช้มุมมอง

ข้อผิดพลาด #6: ไม่ทราบว่า Backbone.js สามารถปรับให้เข้ากับ Non-RESTful API ได้

Backbone.js ทำงานร่วมกับ RESTful API ที่ใช้ JSON ได้ตั้งแต่แกะกล่อง ทั้งหมดที่คุณต้องการสำหรับสิ่งนั้นคือ jQuery (หรือสิ่งที่จะแทนที่แบบดรอปอิน เช่น Zepto) อย่างไรก็ตาม Backbone.js สามารถขยายได้อย่างมาก อันที่จริง Backbone.js สามารถปรับใช้ API ประเภทอื่นและรูปแบบการเข้ารหัสประเภทอื่นได้

ส่วนประกอบของ Backbone.js ที่เกี่ยวข้องกับการโต้ตอบของ front-end กับบริการ back-end คือ "Sync" คอมโพเนนต์นี้แสดงแอตทริบิวต์จำนวนหนึ่งซึ่งคุณสามารถแทนที่ได้อย่างง่ายดายเพื่อปรับแต่งวิธีการโต้ตอบของ Backbone.js กับปลายทาง API ที่จริงแล้ว ยังสามารถแทนที่กลไกการซิงค์เริ่มต้นด้วยสิ่งที่ไม่ธรรมดาอย่างที่ควรจะเป็น เช่น การใช้ localStorage เพื่อรักษาข้อมูล แทนที่จะเป็นบริการแบ็คเอนด์

มีปลั๊กอินมากมายที่ช่วยให้ปรับแต่งพฤติกรรมการซิงค์ของ Backbone.js ได้อย่างง่ายดาย ตัวอย่างเช่น ปลั๊กอินที่เรียกว่า Backbone.dualStorage ช่วยให้คุณใช้ทั้งบริการแบ็คเอนด์และ localStorage เพื่อรักษาข้อมูล เมื่อแอปพลิเคชันของคุณออฟไลน์ ปลั๊กอินจะใช้ localStorage เพื่อให้บริการคำขอจากข้อมูลที่แคชไว้ และติดตามการเปลี่ยนแปลงที่คุณอาจซิงโครไนซ์กับเซิร์ฟเวอร์ในภายหลังเมื่อคุณออนไลน์

แม้ว่า Backbone.js จะใช้ Backbone.js กับส่วนแบ็คเอนด์ที่ออกแบบมาให้มี RESTful และเข้ากันได้กับใช้งานง่ายกว่า แต่ก็ไม่ได้หมายความว่า Backbone.js ทั้งหมดจะใช้งานได้ ด้วยการเปลี่ยนแปลงบางอย่างในกลไกการซิงค์เริ่มต้นของ Backbone.js คุณสามารถปรับให้เข้ากับ API บริการแบ็คเอนด์และรูปแบบการเข้ารหัสที่หลากหลาย

เป็นมูลค่าการกล่าวขวัญว่าส่วนอื่นๆ ของ Backbone.js ยังมีความยืดหยุ่นและเป็นทางเลือก ตัวอย่างเช่น คุณไม่จำเป็นต้องใช้เอ็นจิ้นการสร้างเทมเพลตเริ่มต้นซึ่งมาพร้อมกับ Underscore.js คุณไม่จำเป็นต้องใช้องค์ประกอบ view ของ Backbone.js ด้วยซ้ำ และสามารถแทนที่ด้วยอย่างอื่นได้ทั้งหมดหากต้องการ

ข้อผิดพลาด #7: การจัดเก็บข้อมูลบน Views แทนที่จะเป็นใน Models

ข้อผิดพลาดประการหนึ่งที่เรามักจะทำในฐานะผู้เริ่มต้นเรียนรู้ Backbone.js คือการจัดเก็บข้อมูลบนมุมมองโดยตรงเป็นแอตทริบิวต์ ข้อมูลนี้อาจอยู่ที่นั่นเพื่อติดตามสถานะบางส่วนหรือการเลือกผู้ใช้บางส่วน นี่คือสิ่งที่ควรหลีกเลี่ยง

 var AudioPlayerVisualizer = Backbone.View.extend({ events: { 'click .btn-color': function(event) { this.colorHex = $(event.target).data('color-hex') this.render() } }, // ... })

คุณสามารถสร้างโมเดลและคอลเลกชั่นเพิ่มเติมได้เสมอโดยไม่ต้องใช้ปลายทาง สิ่งเหล่านี้สามารถช่วยให้คุณจัดเก็บข้อมูลที่ไม่จำเป็นต้องคงอยู่ในส่วนหลัง หรืออาจเป็นข้อมูลชั่วคราว การจัดเก็บในรูปแบบต่างๆ ช่วยให้คุณได้รับประโยชน์จากการรับฟังการเปลี่ยนแปลง มุมมองที่เกี่ยวข้อง หรือแม้แต่มุมมองหลายมุมมอง สามารถสังเกตแบบจำลองเหล่านี้และแสดงผลซ้ำตามความจำเป็น

ลองนึกภาพถ้าคุณเก็บตัวแปรการติดตามสถานะไว้ในมุมมองและต้องเรียกวิธีการแสดงทุกครั้งที่คุณเปลี่ยนแปลง การพลาดเมธอดการเรนเดอร์นี้เพียงครั้งเดียวอาจทำให้แอปพลิเคชันของคุณเสีย ในแง่ของสิ่งที่ผู้ใช้ประสบบนหน้าจอ ยิ่งไปกว่านั้น ด้วยมุมมองเล็กๆ คุณอาจต้องซิงโครไนซ์ตัวแปรสถานะเหล่านี้กับอ็อบเจ็กต์หลายมุมมอง จากนั้นต้องเรียกใช้เมธอดการเรนเดอร์ด้วย

ข้อผิดพลาด #8: การใช้ jQuery “.on()” แทนการมอบหมายเหตุการณ์

Backbone.js มีวิธีที่ยอดเยี่ยมในการจัดการเหตุการณ์ DOM ในความคิดของฉัน ไม่ใช้ก็มีข้อเสียมากมาย ฟังก์ชันการเชื่อมโยงเหตุการณ์ “.on()” ของ jQuery สามารถรู้สึกสะดวก แต่มักจะกลายเป็นเรื่องยุ่งยากในระยะยาว ตัวอย่างเช่น เมื่อองค์ประกอบถูกแยกออกจาก DOM แล้ว jQuery จะลดตัวจัดการเหตุการณ์ทั้งหมดที่เชื่อมโยงกับองค์ประกอบโดยใช้ ".on()" โดยอัตโนมัติ ซึ่งหมายความว่าเหตุการณ์ DOM ใดๆ ที่คุณพยายามผูกจากภายในมุมมองจะต้องได้รับการรีบาวด์ หากคุณถอดองค์ประกอบรูทออกจาก DOM และแนบกลับเข้าไปใหม่

 var AudioPlayerControls = Backbone.View.extend({ events: { 'click .btn-play, .btn-pause': function() { /* ... */ }, 'click .btn-prev': function() { /* ... */ }, 'click .btn-next': function() { /* ... */ }, 'click .btn-shuffle': function() { /* ... */ }, 'click .btn-repeat': function() { /* ... */ } }, // ... })

เมื่อองค์ประกอบที่สอดคล้องกับมุมมองนี้ถูกแนบอีกครั้งกับ DOM สิ่งที่คุณต้องทำคือเรียก “delegateEvents()” บนมุมมองเพื่อผูกเหตุการณ์ทั้งหมดเหล่านี้

โปรดทราบว่าสิ่งสำคัญคือต้องเข้าใจว่าเหตุการณ์เหล่านี้เชื่อมโยงกันอย่างไร แทนที่จะผูกเหตุการณ์กับองค์ประกอบที่ระบุโดยตัวเลือก Backbone.js จะผูกตัวจัดการเหตุการณ์กับองค์ประกอบรากของมุมมอง วิธีนี้ใช้ได้ดีในเกือบทุกกรณี และที่จริงแล้วได้ผลดีกว่าสำหรับความต้องการส่วนใหญ่ของเรา การเปลี่ยนหรือแทนที่องค์ประกอบย่อยในทรีย่อย DOM ของมุมมองไม่ต้องการ Backbone.js ในการผูกแต่ละเหตุการณ์อีกครั้งในองค์ประกอบใหม่ ผู้ฟังที่มีอยู่ก็ทำงานต่อไป

อย่างไรก็ตาม สิ่งนี้จะป้องกันไม่ให้มีการฟังเหตุการณ์บางอย่าง ตัวอย่างหนึ่งคือที่ที่คุณอาจต้องการฟังเหตุการณ์การเลื่อนบน "หน้าต่าง" หรือองค์ประกอบลูกเลื่อนได้ ในกรณีขององค์ประกอบย่อย คุณสามารถสร้างมุมมองย่อยสำหรับองค์ประกอบนั้นและจัดการเหตุการณ์ที่นั่น

บทสรุป

Backbone.js เป็นเฟรมเวิร์กที่มีขนาดกะทัดรัดแต่สามารถขยายได้ เป็นตัวเลือกที่ยอดเยี่ยมสำหรับเว็บแอปพลิเคชันที่ต้องการความยืดหยุ่นอย่างมากในเบื้องหลัง Backbone.js ต่างจากเฟรมเวิร์กอย่าง Angular.js และ Ember.js ที่คอยบอกวิธีทำสิ่งที่คุณต้องการเสมอ Backbone.js ถอยกลับ ให้ชุดเครื่องมือที่ทรงพลัง และให้คุณตัดสินใจว่าจะใช้อย่างไร พวกเขา. ฉันหวังว่าบทช่วยสอน Backbone.js สำหรับผู้เริ่มต้นจะช่วยคุณหลีกเลี่ยงข้อผิดพลาดทั่วไปในการพัฒนาและสร้างบางสิ่งที่น่าทึ่งด้วย