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

• อย่าใช้ขอบเขตแยกต่างหากหากองค์ประกอบที่จะใช้คำสั่งใช้ ng-model
  ดูฉันจะใช้ ng-model กับขอบเขตแยกได้หรือไม่? และ
  ทำไมตัวจัดรูปแบบไม่ทำงานกับขอบเขตที่แยกได้
• หากคำสั่งไม่ได้แก้ไขคุณสมบัติขอบเขต / โมเดลอย่าสร้างขอบเขตใหม่
• แยกขอบเขตดูเหมือนว่าจะทำงานได้ดีถ้าคำสั่งนั้นห่อหุ้มชุดขององค์ประกอบ DOM ( เอกสารระบุว่า "โครงสร้าง DOM ที่ซับซ้อน") และคำสั่งจะถูกใช้เป็นองค์ประกอบหรือไม่มีคำสั่งอื่นในองค์ประกอบเดียวกัน

ฉันทราบว่าการใช้คำสั่งที่มีขอบเขตแยกบนองค์ประกอบบังคับให้คำสั่งอื่น ๆ ทั้งหมดในองค์ประกอบเดียวกันนั้นใช้ขอบเขตแยก (หนึ่ง) เดียวกันดังนั้นจึงไม่ จำกัด อย่างรุนแรงเมื่อใช้ขอบเขตแยกได้หรือไม่

ฉันหวังว่าบางอย่างจากทีม Angular-UI (หรืออื่น ๆ ที่เขียนคำสั่งมากมาย) สามารถแบ่งปันประสบการณ์ของพวกเขา

โปรดอย่าเพิ่มคำตอบที่บอกว่า "ใช้ขอบเขตแยกสำหรับส่วนประกอบที่นำมาใช้ซ้ำได้"

เป็นคำถามที่ยอดเยี่ยม! ฉันชอบที่จะได้ยินสิ่งที่คนอื่นพูด แต่นี่เป็นแนวทางที่ฉันใช้

สถานที่ตั้งสูง: ขอบเขตถูกใช้เป็น "กาว" ที่เราใช้ในการสื่อสารระหว่างตัวควบคุมหลักคำสั่งและแม่แบบคำสั่ง

ขอบเขตหลัก: scope: falseดังนั้นจึงไม่มีขอบเขตใหม่เลย

ฉันไม่ได้ใช้สิ่งนี้บ่อยนัก แต่อย่างที่ @MarkRajcok กล่าวว่าหากคำสั่งไม่สามารถเข้าถึงตัวแปรขอบเขต (และไม่ได้ตั้งค่าแน่นอน!) นี่เป็นสิ่งที่ดีเท่าที่ฉันกังวล สิ่งนี้ยังเป็นประโยชน์สำหรับคำสั่งเด็กที่ใช้เฉพาะในบริบทของคำสั่งหลัก (แม้ว่าจะมีข้อยกเว้นนี้เสมอ) และไม่มีเทมเพลต โดยพื้นฐานแล้วสิ่งใดก็ตามที่มีเทมเพลตไม่ได้อยู่ในขอบเขตการแบ่งปันเพราะคุณเปิดเผยขอบเขตสำหรับการเข้าถึงและการจัดการโดยเนื้อแท้ (แต่ฉันแน่ใจว่ามีข้อยกเว้นสำหรับกฎนี้)

ตัวอย่างเช่นเมื่อเร็ว ๆ นี้ฉันได้สร้างคำสั่งที่ดึงกราฟิกแบบเวกเตอร์ (สแตติก) โดยใช้ไลบรารี SVG ฉันกำลังอยู่ระหว่างการเขียน มัน$observeเป็นคุณสมบัติสองอย่าง ( widthและheight) และใช้ในการคำนวณ แต่ไม่ได้ตั้งค่าหรืออ่านตัวแปรขอบเขตใด ๆ และไม่มีแม่แบบ นี่เป็นกรณีการใช้งานที่ดีสำหรับการไม่สร้างขอบเขตอื่น เราไม่จำเป็นต้องใช้หนึ่งดังนั้นทำไมต้องรำคาญ?

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

ขอบเขตของเด็ก: scope: true

คำสั่งที่มีขอบเขตลูกจะรับรู้บริบทและมีจุดประสงค์ที่จะโต้ตอบกับขอบเขตปัจจุบัน

เห็นได้ชัดว่าข้อได้เปรียบที่สำคัญของสิ่งนี้ในขอบเขตแยกคือผู้ใช้มีอิสระที่จะใช้การแก้ไขในคุณลักษณะใด ๆ ที่พวกเขาต้องการ; เช่นใช้class="item-type-{{item.type}}"ในคำสั่งที่มีขอบเขตแยกจะไม่ทำงานโดยค่าเริ่มต้น แต่ทำงานได้ดีในหนึ่งกับขอบเขตเด็กเพราะสิ่งที่มีการแก้ไขสามารถยังคงโดยค่าเริ่มต้นจะพบในขอบเขตผู้ปกครอง นอกจากนี้คำสั่งยังสามารถประเมินคุณลักษณะและการแสดงออกในบริบทของขอบเขตของตนเองอย่างปลอดภัยโดยไม่ต้องกังวลเกี่ยวกับมลภาวะหรือความเสียหายต่อผู้ปกครอง

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

ฉันพบว่าตัวเองใช้ขอบเขตเด็กบ่อยครั้งกว่าแยกหรือเป็นขอบเขตหลัก

แยกขอบเขต: scope: {}

ใช้สำหรับส่วนประกอบที่นำมาใช้ซ้ำได้ :-)

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

หากต้องการข้อมูลเฉพาะเพิ่มเติมสิ่งใดที่จำเป็นสำหรับฟังก์ชันการทำงานแบบสแตนด์อโลนนี้มีให้ผ่านคุณสมบัติที่ระบุซึ่งประเมินในบริบทของขอบเขตพาเรนต์ พวกเขาอาจเป็นสตริงทางเดียว ('@'), การแสดงออกทางเดียว ('&') หรือการผูกตัวแปรสองทาง ('=')

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

แนวปฏิบัติที่ดีที่สุดคือการแยกสิ่งที่ใช้เทมเพลตออกจากฟังก์ชั่น directive link และ controller ให้มากที่สุด นี่เป็นอีกจุดกำหนดค่า "API-like": ผู้ใช้ของคำสั่งสามารถแทนที่เทมเพลตได้! ฟังก์ชันการทำงานทั้งหมดยังคงเหมือนเดิมและ API ภายในก็ไม่เคยสัมผัส แต่เราสามารถยุ่งกับการออกแบบและการใช้งาน DOM ได้มากเท่าที่เราต้องการ ui / bootstrap เป็นตัวอย่างที่ดีของวิธีการทำเช่นนี้เพราะ Peter & Pawel ยอดเยี่ยม

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

ล้อมรอบด้วยฟังก์ชั่นเพิ่มเติมหรือแปลงฟังก์ชั่นอื่น ๆ อีกมากมาย แต่คำสั่งคือสิ่งที่มันมีอยู่แล้ว

ทั้งหมดที่กล่าวว่าฉันควรทราบว่ามีข้อ จำกัด บางอย่าง (เช่นคุณสมบัติ) ของขอบเขตไอโซเลทตามที่ @ProLoser พูดถึงในคำตอบของเขา ตัวอย่างเช่นในส่วนขอบเขตลูกฉันได้กล่าวถึงการแก้ไขในคุณลักษณะที่ไม่ใช่คำสั่งที่แบ่งเมื่อใช้ขอบเขต isolate (โดยค่าเริ่มต้น) ตัวอย่างเช่นผู้ใช้สามารถทำได้เพียงแค่ใช้class="item-type-{{$parent.item.type}}"และมันจะทำงานได้อีกครั้ง ดังนั้นหากมีเหตุผลที่น่าสนใจที่จะใช้ขอบเขตแบบแยกต่างหากบนขอบเขตของเด็ก แต่คุณเป็นห่วงเกี่ยวกับข้อ จำกัด เหล่านี้รู้ว่าคุณสามารถแก้ไขได้ทั้งหมดหากคุณต้องการ

สรุป

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

ฉันต้องการที่จะเริ่มต้นความคิดของฉันออกมา แต่เมื่อฉันคิดถึงสิ่งต่าง ๆ เพิ่มเติมฉันจะอัปเดตสิ่งนี้ แต่อึศักดิ์สิทธิ์ - นี่เป็นเวลานานสำหรับคำตอบ SO ...

PS: วงสัมผัสทั้งหมด แต่เนื่องจากเรากำลังพูดถึงขอบเขตฉันชอบพูดว่า "prototypical" ในขณะที่คนอื่นชอบ "prototypal" ซึ่งดูเหมือนว่าจะแม่นยำมากขึ้น แต่เพิ่งปิดลิ้นไม่ดีเลย :-)

นโยบายและประสบการณ์ส่วนตัวของฉัน:

แยกได้: กล่องทรายส่วนตัว

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

เด็ก: ส่วนย่อยของเนื้อหา

ฉันต้องการสร้างวิธีขอบเขตและตัวแปรที่ผู้ใช้สามารถเข้าถึงได้ แต่ไม่เกี่ยวข้องกับขอบเขตโดยรอบ (พี่น้องและผู้ปกครอง) นอกบริบทของคำสั่งของฉัน ฉันยังต้องการให้ข้อมูลขอบเขตผู้ปกครองทั้งหมดลดลงอย่างโปร่งใส

ไม่มี: คำสั่งที่ง่ายและอ่านได้อย่างเดียว

ฉันไม่ต้องการยุ่งกับวิธีขอบเขตหรือตัวแปร ฉันอาจทำสิ่งที่ไม่เกี่ยวข้องกับขอบเขต (เช่นการแสดงปลั๊กอิน jQuery แบบธรรมดาการตรวจสอบความถูกต้อง ฯลฯ )

หมายเหตุ

• คุณไม่ควรปล่อยให้ ngModel หรือสิ่งอื่น ๆ ส่งผลกระทบต่อการตัดสินใจของคุณโดยตรง คุณสามารถหลีกเลี่ยงพฤติกรรมแปลก ๆ โดยทำสิ่งต่าง ๆ เช่นng-model=$parent.myVal(เด็ก) หรือngModel: '='(แยก)
• Isolate + transcludeจะคืนค่าการทำงานปกติทั้งหมดให้กับคำสั่งพี่น้องและกลับไปที่ขอบเขตพาเรนต์ดังนั้นอย่าปล่อยให้สิ่งนั้นมีผลต่อการตัดสินใจของคุณ
• อย่ายุ่งกับขอบเขตเพราะไม่มีใครเหมือนใส่ข้อมูลลงในขอบเขตสำหรับครึ่งล่างของ DOM แต่ไม่ใช่ครึ่งบนที่ทำให้รู้สึก 0
• ให้ความสนใจกับลำดับความสำคัญคำสั่ง (ไม่มีตัวอย่างที่เป็นรูปธรรมของสิ่งนี้สามารถส่งผลกระทบต่อสิ่งต่าง ๆ )
• บริการ Inject หรือใช้ตัวควบคุมเพื่อสื่อสารข้ามคำสั่งกับประเภทขอบเขตใด ๆ คุณสามารถทำได้require: '^ngModel'เพื่อดูองค์ประกอบหลัก

หลังจากเขียนคำสั่งจำนวนมากฉันตัดสินใจใช้isolatedขอบเขตที่น้อยลง แม้ว่ามันจะเย็นและคุณแค็ปซูลข้อมูลและแน่ใจว่าจะไม่รั่วไหลของข้อมูลไปยังขอบเขตหลักมัน จำกัด จำนวนของคำสั่งที่คุณสามารถใช้ร่วมกันอย่างรุนแรง ดังนั้น,

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

หากคำสั่งที่คุณกำลังจะเขียนจะทำเพียงแค่การเปลี่ยนแปลงที่ไม่ต้องการสภาวะภายในขอบเขตหรือการเปลี่ยนแปลงขอบเขตอย่างชัดเจน (ส่วนใหญ่เป็นสิ่งที่ง่ายมาก); ไปไม่มีขอบเขตใหม่ (เช่นngShow, ngMouseHover, ngClick, ngRepeat)

หากคำสั่งที่คุณกำลังจะเขียนความต้องการที่จะเปลี่ยนองค์ประกอบบางอย่างอยู่ในขอบเขตของพ่อแม่ แต่ยังมีความต้องการที่จะจัดการกับบางรัฐภายในไปสำหรับขอบเขตเด็กใหม่ (เช่นngController)

อย่าลืมตรวจสอบซอร์สโค้ดสำหรับคำสั่ง: https://github.com/angular/angular.js/tree/master/src/ng/directive
มันช่วยได้อย่างมากในการคิดเกี่ยวกับพวกเขา

แค่คิดว่าฉันจะเพิ่มความเข้าใจปัจจุบันของฉันและความเกี่ยวข้องกับแนวคิด JS อื่น ๆ

ค่าเริ่มต้น (เช่นไม่ได้ประกาศหรือขอบเขต: false)

นี่คือปรัชญาเทียบเท่ากับการใช้ตัวแปรทั่วโลก คำสั่งของคุณสามารถเข้าถึงทุกอย่างในตัวควบคุมหลัก แต่ยังส่งผลกระทบต่อพวกเขาและได้รับผลกระทบในเวลาเดียวกัน

ขอบเขต:{}

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

ขอบเขต: เด็ก ๆ

นี่คือจุดกึ่งกลางระหว่างตัวแปรกลางและ passthrough อย่างชัดเจน มันคล้ายกับเชนต้นแบบของ javascript และขยายขอบเขตสำเนาพาเรนต์ให้กับคุณ หากคุณสร้างขอบเขตแบบแยกและส่งผ่านในทุกแอตทริบิวต์และฟังก์ชันของขอบเขตหลักจะเทียบเท่ากับฟังก์ชันนี้

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

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

แน่นอนว่าระหว่างคำสั่งของแองกูลาร์กับงานของทีมแองกูลาร์- UIฉันยังไม่ได้สร้างคำสั่งของตัวเองที่ทำอะไรมากมายเพื่อให้มุมมองของฉันเกี่ยวกับเรื่องนี้อาจผิดอย่างสมบูรณ์

ฉันเห็นด้วยกับอูมูร์ ในทางทฤษฎีขอบเขตที่แยกออกมานั้นยอดเยี่ยมและ "พกพา" แต่ในการสร้างแอปของฉันให้มีฟังก์ชั่นที่ไม่น่าสนใจฉันก็เจอความต้องการที่จะรวมคำสั่งต่าง ๆ (บางอันซ้อนกันภายใน HTML ของตัวเองซึ่งเป็นจุดประสงค์ของภาษาเฉพาะโดเมน

ในท้ายที่สุดมันก็แปลกเกินไปที่จะต้องผ่านค่าส่วนกลางหรือค่าที่ใช้ร่วมกันทั้งหมดลงในห่วงโซ่ที่มีคุณลักษณะหลายอย่างในแต่ละการร้องขอ DOM ของคำสั่ง (ตามที่จำเป็นกับขอบเขตการแยก) ดูเหมือนโง่ที่จะเขียนซ้ำ ๆ ทั้งหมดใน DOM และรู้สึกไม่มีประสิทธิภาพแม้ว่าวัตถุเหล่านี้จะเป็นวัตถุที่ใช้ร่วมกันก็ตาม นอกจากนี้ยังทำให้การประกาศคำสั่งยุ่งยากซับซ้อนโดยไม่จำเป็น วิธีแก้ปัญหาในการใช้ $ parent เพื่อ "เข้าถึง" และคว้าค่าจาก HTML directive ดูเหมือนว่าฟอร์มแย่มาก

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

หลังจากฝันถึงความฝันของ Domain Specific Languages ​​มานานหลายทศวรรษก่อนที่จะมีสิ่งนั้นฉันดีใจที่ AngularJS มีตัวเลือกนี้และฉันรู้ว่าเมื่อ devs ทำงานมากขึ้นในพื้นที่นี้เราจะเห็นแอพที่ยอดเยี่ยมมากที่ นอกจากนี้ยังง่ายสำหรับสถาปนิกในการเขียนขยายและตรวจแก้จุดบกพร่อง

- ดี