Ember.js: Rendering <button>di setiap aplikasi loop break</button>

Ya, dikonfirmasi, kami mengalami kesalahan yang sama setelah meningkatkan dari 3.2.2 ke 3.3.0

Saya agak terkejut bahwa ini rusak di 3,3, tetapi saya berharap itu rusak di 3,4 (karena fitur pemanggilan braket sudut).

Saya akan mencoba menggali untuk mengonfirmasi apakah itu terkait ...

Mengubah ke:

{{#each buttons as |text|}}
  <button>{{text}}</button>
{{/each}}

Harus menyelesaikan masalah (dengan asumsi bahwa tebakan saya RE: fitur pemanggilan braket sudut benar).

@rwjblue ya, mengubah dari button menjadi text atau btn membantu. Terima kasih atas penjelasannya.

Hanya pesan informasional: Saya memiliki masalah yang sama dengan {{#each model as | img |}}. Mengubah img menjadi "foto" mengatasi kesalahan ini. Apakah perubahan yang mengganggu ini (ember-source 3.2.2 => 3.3.0) didokumentasikan di suatu tempat?

Hanya informasi lain: masalah ini banyak menipu saya, kuncinya adalah: jangan gunakan nama tag html sebagai as bagian dari each pembantu yang menghasilkan sesuatu.

{{#each people as |p|}} {{!-- don't, because `p` is a html tag name --}}
  {{p.name}}
{{/each}}

{{#each people as |person|}} {{!-- this is fine --}}
  {{person.name}}
{{/each}}

Saya tidak yakin apakah itu akan menjadi perubahan besar, tapi saya harap tidak.

@nightire seperti yang saya tahu, kita dapat menggunakan nama tag html di as part jika tag html itu tidak digunakan di dalam blok. Saya juga berpikir itu mempengaruhi tidak hanya each tetapi setiap pembantu blok yang menghasilkan sesuatu, termasuk komponen kita sendiri.

Konfirmasikan, menghasilkan parameter blok apa pun yang akan digunakan sebagai pemanggilan braket sudut akan mengakibatkan masalah ini.

Lihat masalah berikut untuk beberapa informasi latar belakang selengkapnya:

• https://github.com/rwjblue/ember-angle-bracket-invocation-polyfill/issues/17
• https://github.com/ember-template-lint/ember-template-lint/issues/441

Perubahan ini seharusnya tidak terjadi selama 3.3, dan kami akan mencoba mencari tahu mengapa hal itu terjadi (dan memperbaikinya). Namun, kami _do_ berniat untuk mendarat sebagai bagian dari 3.4 (bersama dengan dukungan untuk linting dalam aplikasi sebagai panduan umum).

Haruskah kita mengharapkan ini ditambal di 3.3.1?

Mungkin, tetapi masih merupakan ide yang bagus untuk melakukan refactor menjauh dari pola yang saat ini rusak.

Aturan ember-template-lint no-shadowed-elements adalah cara terbaik untuk menerapkannya.

Saya juga mulai mendapatkan kesalahan: tidak dapat dijangkau dengan add-on ini di 3.3 ...

https://github.com/tedconf/ember-collapsible-panel/issues

Apakah ini dianggap sebagai perubahan yang dapat merusak? Saya juga sedikit bingung oleh RFC, apakah ini diizinkan (dan seharusnya berfungsi), atau diizinkan pada waktu pembuatan (tetapi istirahat saat run-time).

Apakah ini dianggap sebagai perubahan yang dapat merusak?

Ya, ini adalah perubahan besar dan kami sedang memperbaikinya.

Saya juga sedikit bingung oleh RFC, apakah ini diizinkan (dan seharusnya berfungsi), atau diizinkan pada waktu pembuatan (tetapi istirahat saat run-time).

Perilaku saat ini cocok dengan apa yang dinyatakan RFC (pada dasarnya bahwa parameter blok bernama button + <button></button> dalam template blok, akan menganggap bahwa parameter blok adalah komponen penutupan yang dihasilkan dan mencoba untuk membuatnya sebagai seperti itu), tetapi berdasarkan umpan balik (di sini dan dalam masalah lain) kami memutuskan bahwa hasilnya pasti sesuatu yang kami anggap sebagai perubahan yang dapat merusak.

Rencana saat ini (setelah berdiskusi dengan tim inti pada 2018-07-20) adalah:

• Pastikan semua parameter blok yang "membayangi" elemen HTML normal di dalam bloknya, terus merender elemen HTML (dan jangan berasumsi bahwa mereka harus "memanggil" komponen yang dihasilkan).
• Berikan penghentian saat skenario ini terdeteksi (dengan until: '4.0.0' )
• Pastikan linter disiapkan untuk aplikasi Ember yang baru dibuat yang akan tidak menggunakan nama parameter blok yang membingungkan (di mana parameter blok _dapat menjadi_ nama elemen HTML, dan elemen HTML tersebut dipanggil di template blok).
• Lakukan backport perbaikan ini ke Ember 3.3

Saya telah mengalami masalah yang sama selama beberapa hari terakhir juga mencoba mencari tahu apa yang sedang terjadi:

<select>
    {{#each options as |option|}} <!--I see now the issue is I named this "option" a valid html tag -->
        <option value="{{option.id}}">{{option.name}}</option>
    {{/each}}
</select>

Mengubah ke ini memperbaiki masalah juga:

<select>
    {{#each options as |opt|}} <!-- Renamed to "opt" -->
        <option value="{{opt.id}}">{{opt.name}}</option>
    {{/each}}
</select>

Buang saja ini di luar sana untuk dokumentasi lebih lanjut tentang masalah ini.

Buang saja ini di luar sana untuk dokumentasi lebih lanjut tentang masalah ini.

👍 terima kasih untuk itu (dan maaf untuk masalah ini)

@rwjblue Sebenarnya saya tidak dapat menemukan bukti aturan lint no-shadowed-elements di https://github.com/ember-template-lint/ember-template-lint/blob/master/docs/rules .md

Apakah itu ada di tempat lain?

@cafreeman tidak terdaftar di sana (meskipun seharusnya ada), tetapi aturannya ada di sini

Ah, tidak percaya aku melewatkan itu. Terima kasih!

Aturan no-shadowed-elements tidak terlalu deskriptif, berakhir di sini berpikir aturan itu adalah masalah lain hanya dengan pemformatan (dalam vscode dengan addon ember tidak ada perbedaan antara masalah pemformatan dan kesalahan, saya pikir dengan linter juga? ).

Pertanyaan saya adalah apakah ini akan memiliki kesalahan yang lebih baik di masa mendatang? Tidak semua orang akan menjalankan linter dan saya bisa membayangkan rekan kerja mengalami ini dan tidak tahu apa yang terjadi saat ada kesalahan tidak berguna.

Ya, saya sebutkan di atas bahwa kami menganggap ini bug dan benar-benar ingin
membuat ergonomi jauh lebih baik (misalnya mengeluarkan peringatan yang bermanfaat
pesan, bukan kesalahan).

Saya sebenarnya bingung mengapa ini ambigu:

{{#each options as |option|}}
  <option value={{option.value}}>{{option.label}}</option>
{{/each}}

Bukankah komponen kurung sudut perlu dipanggil dengan huruf kapital?

Bukankah komponen kurung sudut perlu dipanggil dengan huruf kapital?

Tidak, lihat bagian permintaan dinamis dari RFC untuk latar belakang.

Adakah yang bisa mereproduksi ini pada rilis stabil terbaru Ember?

@pzuraq ya, saya dapat mereproduksi kesalahan ini menggunakan 3.8.0

Hanya untuk membuat hal-hal menjadi sangat membingungkan, ini bisa terjadi (itu terjadi pada saya)
Menjalankan Ember 3.4

{{#each someArray as |item i|}}
  {{#if (gt i 0)}}
    {{fa-icon item.icon}}
  {{/if}}
{{/each}}

Meskipun saya tidak menggunakan <i> , komponen {{fa-icon}} (dari ember font awesome) membuatnya, dan ini menyebabkan kesalahan Uncaught Error: unreachable

Selain itu, ini tidak tertangkap oleh no-shadowed-elements ember-template-lint, sehingga lebih sulit untuk menemukan dan mendiagnosis :(

Saya benar-benar dapat melihat bagaimana itu akan sangat membingungkan. Secara internal ember-font-awesome memodifikasi template keluaran dan mengganti pemanggilan komponen {{fa-icon secara langsung dengan <i> yang menyebabkan kesalahan yang Anda pukul.

RE: ini tidak tertangkap oleh no-shadowed-elements , saya pikir kita dapat melakukan sedikit pekerjaan dalam transformasi AST ember-font-awesome untuk memastikan bahwa skenario khusus ini tidak ada (pada dasarnya kesalahan atau secara otomatis menulis ulang blok apa pun params bernama i saat transpiling).

@ Technn. @rwjblue Nama ikon tidak boleh dinamis di fa-icon (https://github.com/FortAwesome/ember-fontawesome/blob/master/lib/ast-transform.js#L37)

Kami memiliki dinamis fa-icon semua tempat, itu berfungsi. Cukup yakin apa yang Anda tautkan akan memiliki bara / kilau yang sudah mengubahnya menjadi string. Jika tidak, tidak ada kemungkinan kami akan menggunakan paket tersebut.

Anda juga dapat mengirim objek yang memiliki set iconName dan prefix .

Maaf - apakah nama ikon dinamis berfungsi atau tidak, itu hanya masalah dengan contoh yang saya berikan, tetapi intinya masih berlaku.

Dasar dari contoh khusus itu (menggunakan i sebagai parameter blok, dan fa-icon di blok bagian dalam) digunakan dalam jumlah tempat yang tidak sepele di seluruh basis kode saya - saya akhirnya mengganti nama semua blokir penggunaan param i hingga index untuk memastikan

Juga perlu dicatat ada dua proyek luar biasa ember font yang terjadi, tergantung pada versi FA yang Anda gunakan. Mereka mungkin memiliki perbedaan dalam apa yang mereka dukung, dll.
https://github.com/martndemus/ember-font-awesome
https://github.com/FortAwesome/ember-fontawesome

Apakah masalah ini masih dibahas? tampaknya sudah hampir setahun sejak itu dilaporkan tetapi saya menemukan

Kesalahan Tidak Tertangkap: tidak dapat dijangkau

pesan hari ini dengan kode berikut di Ember v3.4.4 (yang saya yakini adalah versi LTS saat ini).

<select>
    {{#each options as |option|}}
        <option value={{option.id}}>{{option.name}}</option>
    {{/each}}
</select>

PS Saya sejak itu mengubah kode menjadi:

<select>
    {{#each options as |opt|}}
        <option value={{opt.id}}>{{opt.name}}</option>
    {{/each}}
</select>

yang jelas berhasil.

@Caltor LTS terbaru - 3.8 https://emberjs.com/releases/

@life itu juga mengatakan 3.4 bug hingga Mei 2019.

3.4 hanya akan menerima perbaikan keamanan pada saat ini, 3.8 akan menerima perbaikan bug hingga 3.12 dipromosikan menjadi LTS

@rwjblue Jadi LTS sebenarnya berarti "kami mengabaikan bug sampai periode LTS telah berlalu"? Menarik. Saya mengira bug yang terlihat dalam periode LTS akan diperbaiki. Masih saya mengerti ini adalah proyek komunitas, dll. Dan itu bukan masalah besar untuk diselesaikan.

@Caltor https://github.com/emberjs/ember.js/issues/16826#issuecomment -405654150 ada solusi untuk kasus ini, dan solusi yang cukup jelas dan mengikuti aturan linting resmi https://github.com/ember- template-lint / ember-template-lint / blob / master / docs / rule / no-shadowed-elements.md

@Caltor - Saya minta maaf karena kami tidak memperbaikinya untuk LTS. 😩

Masalah utama di sini adalah bahwa ternyata sangat sulit untuk diperbaiki (saya telah menghabiskan beberapa jam untuk itu), dan dalam hampir semua kasus memperbarui untuk menghindari konflik membuat kode Anda lebih baik dan lebih mudah dipahami yang umumnya membuat perbaikan ini khusus bug berprioritas sedikit lebih rendah daripada yang lain yang sebenarnya memblokir orang.

@rwjblue Jangan khawatir! Jika linter mengangkatnya maka itu bagus. Ini hanya hasil dari pengkodean yang buruk.

Masalah ini juga terjadi jika hash komponen yang dihasilkan memiliki nama yang sama dengan helper, dan linter tidak memahaminya.

<AngleTable as |t|>
  <t.header />
  {{t "unreachable"}}
</AngleTable>

@BobrImperator Saya tidak yakin bahwa masalah adalah sesuatu yang mungkin diketahui sebelumnya, dan seharusnya selalu gagal karena variabel lokal selalu didahulukan daripada global. Alasan kami tidak dapat menangkapnya sebelumnya mirip dengan mengapa Anda tidak dapat melakukan lint terhadap sesuatu seperti ini di JS:

function foo() {

}

function bar(foo = 'a string') {
  foo(); // Error: foo is not a function
}

Meskipun masuk akal untuk mengasumsikan bahwa ini adalah kesalahan yang membayangi di pihak pengembang, karena sifat dinamis JS, kami tidak dapat mengetahui dengan pasti bahwa foo adalah _not_ fungsi saat diteruskan ke bar . Jika kami menggunakan bahasa yang diketik, maka kami mungkin bisa, tapi sayangnya saya rasa saat ini kami tidak bisa.

Saya agak mengungkapkan diri saya dengan buruk, saya tidak benar-benar berharap ini tertangkap sebelumnya.
Tetapi jika saya tidak salah ingat, ada kesalahan kompilasi untuk action helper ketika ditimpa.
Saya tidak ingat sintaks persisnya, tetapi seharusnya seperti ini, serupa tetapi dengan action .

<AngleTable as |action|>
  <t.header />
  {{action "unreachable"}}
</AngleTable>

ini bisa menjadi kasus yang berbeda

FYI hanya menghabiskan beberapa jam untuk debugging sampai akhirnya saya mencari di Google dan menemukan masalah ini (menggunakan opsi dan nama yang dihasilkan) jadi masih tersedia di 3.15.

Yang aneh adalah {{log option}} melaporkan nilai yang benar di dalam loop, jadi tidak pernah terpikir oleh saya bahwa nama variabel bisa menjadi masalah

di ember 3.16.6, masih terjadi di ios safari.