การใช้ ng-src กับ src


89

บทช่วยสอนนี้แสดงให้เห็นถึงการใช้คำสั่งngSrcแทนsrc:

<ul class="phones">
    <li ng-repeat="phone in phones" class="thumbnail">
        <img ng-src="{{phone.imageUrl}}">
    </li>
</ul>

พวกเขาขอให้:

แทนที่คำสั่ง ng-src ด้วยแอตทริบิวต์ src เก่าธรรมดา
การใช้เครื่องมือเช่น Firebug หรือ Web Inspector ของ Chrome หรือการตรวจสอบบันทึกการเข้าถึงเว็บเซิร์ฟเวอร์ยืนยันว่าแอปส่งคำขอโดยไม่เกี่ยวข้องไปยัง/app/%7B%7Bphone.imageUrl%7D%7D (หรือ / app / {{phone) .imageUrl}} )

ฉันทำเช่นนั้นและให้ผลลัพธ์ที่ถูกต้อง:

<li class="thumbnail ng-scope" ng-repeat="phone in phones">
    <img src="img/phones/motorola-xoom.0.jpg">
</li>

มีเหตุผลว่าทำไม?


คำตอบ:


108
<img ng-src="{{phone.imageUrl}}"> 

สิ่งนี้ทำให้คุณได้ผลลัพธ์ที่คาดหวังเนื่องจากphone.imageUrlถูกประเมินและแทนที่ด้วยค่าหลังจากโหลดเชิงมุมแล้ว

<img src="{{phone.imageUrl}}">

แต่ด้วยเหตุนี้เบราว์เซอร์จึงพยายามโหลดภาพที่มีชื่อ{{phone.imageUrl}}ซึ่งส่งผลให้คำขอล้มเหลว คุณสามารถตรวจสอบสิ่งนี้ได้ในคอนโซลของเบราว์เซอร์ของคุณ


ฉันคิดว่าจริงๆแล้วจะพยายามโหลดรูปภาพแบบ src = "" แทนที่จะเป็น {{phone.imageUrl}} แทน
Jeff Ling

2
@JeffLing ไม่จริงมันคือ `` {{phone.imageUrl}} 'ตามที่บทแนะนำระบุ ฉันไม่เข้าใจว่าเบราว์เซอร์ส่งคำขอ http ครั้งแรกก่อนที่ angularjs จะเริ่มทำงาน ตอนนี้ฉันเข้าใจแล้ว
Majid Laissi

สวัสดีฉันคิดว่านี่เป็นวิธีแก้ปัญหาที่ไม่ดีเพราะฉันทำแบบนี้มาระยะหนึ่งแล้วและพบว่าวิธีนี้ใช้ไม่ได้กับเบราว์เซอร์ IE รุ่นเก่าดังนั้นคำแนะนำของฉันคือใช้ ng-src
imal hasaranga perera

ขณะนี้ฉันมีปัญหาในการกรอก ng-src ผ่านคำสั่งและใช้ $ element.attr ('ng-src', this.imageSrc); .... คิดว่าทำไม? ค่ารูปภาพถูกต้องฉันเดาว่าควรใช้ขอบเขต $ ใช้หรือสรุปในภายหลัง ... แต่ไม่รู้ว่าที่ไหน ...
มิกกี้

127

จากเอกสารเชิงมุม

วิธีเขียนรถ:

<img src="http://www.gravatar.com/avatar/{{hash}}"/>

วิธีเขียนที่ถูกต้อง:

<img ng-src="http://www.gravatar.com/avatar/{{hash}}"/>

ทำไม? เนื่องจากในการโหลดหน้าก่อนการบูตเชิงมุมและการสร้างตัวควบคุมเบราว์เซอร์จะพยายามโหลดอิมเมจจากhttp://www.gravatar.com/avatar/{{hash}}และมันจะล้มเหลว จากนั้นเมื่อเริ่มต้นเชิงมุมแล้วจะเข้าใจว่า{{hash}}จะต้องถูกแทนที่ด้วย say logo.pngตอนนี้แอตทริบิวต์ src เปลี่ยนไปhttp://www.gravatar.com/avatar/logo.pngและโหลดรูปภาพได้อย่างถูกต้อง ปัญหาคือมี 2 คำขอดำเนินการและคำขอแรกล้มเหลว

ในการแก้ปัญหานี้เราควรใช้ng-srcซึ่งเป็นคำสั่งเชิงมุมและเชิงมุมจะแทนที่ng-srcค่าเป็นแอตทริบิวต์ src หลังจากโหลดเชิงมุมและตัวควบคุมอย่างเต็มที่แล้วและในเวลานั้น{{hash}}จะถูกแทนที่ด้วยค่าขอบเขตที่ถูกต้องแล้ว


17

สิ่งsrc="{{phone.imageUrl}}"นี้ไม่จำเป็นและสร้างคำขอพิเศษโดยเบราว์เซอร์ เบราว์เซอร์จะทำการGETร้องขออย่างน้อย 2 ครั้งเพื่อพยายามโหลดภาพนั้น:

  1. ก่อนที่นิพจน์จะได้รับการประเมิน {{phone.imageUrl}}
  2. หลังจากประเมินนิพจน์แล้ว img/phones/motorola-xoom.0.jpg

คุณควรใช้ng-srcคำสั่งเสมอเมื่อจัดการกับนิพจน์เชิงมุม <img ng-src="{{phone.imageUrl}}">ให้ผลลัพธ์ที่คาดหวังของคำขอเดียว


หมายเหตุด้านข้างใช้เช่นเดียวกันng-hrefดังนั้นคุณจะไม่ได้รับลิงก์ที่เสียหายจนกว่าวงจรการย่อยแรกจะเข้ามา


0

จริงๆแล้วมันสมเหตุสมผล 100% เพราะ HTML ได้รับการประมวลผลตามลำดับและเมื่อหน้า HTML นี้ถูกประมวลผลทีละบรรทัดตามเวลาที่เข้าสู่รูปภาพนี้เส้นและการประมวลผลรูปภาพของเราphone.imageUrlยังไม่ได้กำหนด

และในความเป็นจริง Angular JS ยังไม่ได้ประมวลผล HTML กลุ่มนี้และยังไม่ได้มองหาตัวยึดตำแหน่งเหล่านี้และแทนที่นิพจน์เหล่านี้ด้วยค่า ดังนั้นสิ่งที่เกิดขึ้นคือเบราว์เซอร์ได้รับบรรทัดนี้และพยายามดึงภาพนี้ที่ URL นี้

และแน่นอนว่านี่เป็น URL ปลอมหากยังคงมีหนวดและวงเล็บปีกกาอยู่ด้วยดังนั้นจึงให้ 404 แก่คุณ แต่เมื่อแน่นอนว่า Angular ดูแลสิ่งนี้มันจะแทนที่ URL นี้เป็น URL ที่เหมาะสมและจากนั้น เรายังคงเห็นรูปภาพ แต่ข้อความแสดงข้อผิดพลาด 404 ยังคงอยู่ในคอนโซลของเรา

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

วิธีหนึ่งในการทำเช่นนี้คือการใส่ Angular แอตทริบิวต์ที่นี่แทนที่จะเป็น HTML มาตรฐาน ng-srcและแอตทริบิวต์เชิงมุมเป็นเพียง ดังนั้นถ้าเราบอกว่าตอนนี้ย้อนกลับไปคุณจะเห็นว่าไม่มีข้อผิดพลาดอีกต่อไปเพราะดึงภาพได้ก็ต่อเมื่อ Angular ได้รับ HTML นี้และแปลนิพจน์ทั้งหมดเป็นค่า

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.