Ember.js: Mundur pernyataan "lebih agresif" di 3.22

Hmm, saya tidak sepenuhnya mengerti apa yang Anda maksud di sini. Kesalahan yang dilontarkan adalah pernyataan (bukan penghinaan) dan tidak dimaksudkan untuk dapat diselesaikan ...

Saya akan tutup untuk saat ini, tetapi saya senang untuk membuka kembali jika saya salah memahami sesuatu di sini...

https://github.com/emberjs/ember.js/blob/c5bbf863af7cd8f6f92a97f2b777ff857bf9a9f4/packages/%40ember/-internals/glimmer/lib/environment.ts#L65

Ini adalah penghentian yang seharusnya dijalankan, tetapi mengapa pernyataan menyebabkan kesalahan alih-alih memasang peringatan. Kesalahan menyebabkan aplikasi rusak alih-alih menampilkan peringatan untuk memfaktorkannya kembali

Tempat yang Anda tautkan adalah tempat Ember mengonfigurasi mesin rendering, menyediakan kait untuk pernyataan dan penghentian dan mesin rendering memilih mana yang akan digunakan berdasarkan skenario.

Opsi yang dikonfigurasi tersebut berubah menjadi menjalankan salah satu dari berikut ini di glimmer-vm:

• runInTrackingTransaction

• deprecateMutationsInTrackingTransaction

Bisakah Anda menjelaskan lebih lanjut mengapa menurut Anda kasus khusus ini harus menjadi penghinaan daripada pernyataan? Hal spesifik yang dilakukan di twiddle selalu dimaksudkan untuk dicegah (seperti yang dijelaskan oleh pesan kesalahan):

export default class ApplicationController extends Controller {
  <strong i="18">@tracked</strong> appName = 'Ember Twiddle';

  get name() {
    this.appName = "Test"

    if (this.appName === "Test") {
      this.appName = "test"
    }

    return this.appName
  }
}

Secara khusus, dalam hal ini Anda membaca nilai yang dilacak kemudian memperbaruinya (yang secara efektif akan menyebabkan siklus jika kami tidak mencegahnya dengan pernyataan ini).

@rwjblue Saya pikir masalahnya di sini adalah bahwa rilis kecil Ember menyebabkan aplikasi yang sebelumnya secara tidak sadar melanggar pernyataan ini sekarang diblokir dari peningkatan hingga pembaruan mundur mereka diselesaikan. Dalam kasus saya, aplikasi yang saya pertahankan diblokir dari pemutakhiran ke 3.22 karena addon yang digunakannya melanggar pernyataan ini.

Jika pernyataan mundur ini diperkenalkan sebagai peringatan alih-alih kesalahan, itu akan memberi aplikasi seperti milik saya jalur yang lebih mudah untuk tetap up-to-date karena kami akan diberi waktu untuk melacak masalah ini. Seperti saat ini, aplikasi saya harus tetap pada 3.21 sampai saya memiliki bandwidth untuk melacak di mana/mengapa itu melanggar pernyataan baru ini.

Mengapa saya pikir ini adalah bug karena ember-gestures telah berhenti bekerja dengan Ember 3.22
Mereka menggunakan fungsi ini untuk merobohkan dan berfungsi dengan versi sebelumnya.
Variabel __instance sedang dibaca dan kemudian diperbarui, jadi itu berarti tidak berfungsi lagi dan sekarang menyebabkan aplikasi rusak, meskipun itu bukan perubahan versi utama

  __teardownRecognizers: on('willDestroyElement', function() {
    let instance = this.get('__instance');
    if (instance) {
      //instance.off();
      instance.destroy();
      this.set('__instance', null);
    }
  }),

Saya pikir masalahnya di sini adalah bahwa rilis kecil Ember menyebabkan aplikasi yang sebelumnya tanpa sadar melanggar pernyataan ini sekarang diblokir dari pemutakhiran hingga pembaruan lacak baliknya diselesaikan. Dalam kasus saya, aplikasi yang saya pertahankan diblokir dari pemutakhiran ke 3.22 karena addon yang digunakannya melanggar pernyataan ini.

Ini bagus! Laporan asli tidak menunjukkan bahwa kode di twiddle pernah benar-benar berfungsi (atau alasan apa pun tentang mengapa itu kesalahan).

@kpfefferle - Dari versi apa yang Anda tingkatkan? Apa sumber mutasi yang menyebabkan pernyataan dalam kasus Anda?

Untuk lebih jelasnya, saya kebanyakan mencoba memahami apa yang dilaporkan di sini (lingkup, pola penggunaan, dll), dan saya secara khusus tidak mencoba merasionalisasi atau berdebat tentang SemVer. 😸

@rwjblue Saya memiliki dua aplikasi dengan PR Dependabot yang gagal untuk menaikkannya dari 3.21.3 ke 3.22.0. Keduanya menunjukkan pesan kesalahan serupa untuk semua tes yang gagal, seperti:

        actual: >
            [object Object]
        stack: >
            Error: Assertion Failed: You attempted to update `_errors` on `changeset:[object Object]`, but it had already been used previously in the same computation.  Attempting to update a value after using it in a computation can cause logical errors, infinite revalidation bugs, and performance issues, and is not supported.

            `_errors` was first used:

            - While rendering:
              application
                forms
                  forms.form
                    form-workflow
                      form-workflow/form
                        form-for

            Stack trace for the update:
                at setter ([...]/assets/vendor.js:56179:9)
                at EmberChangeset.set [as _errors] ([...]/assets/vendor.js:17775:7)
                at EmberChangeset.BufferedChangeset.set (webpack://__ember_auto_import__/./node_modules/validated-changeset/dist/validated-changeset.es5.js?:2674:17)
                at Object.set ([...]/assets/vendor.js:104899:22)
                at Proxy.BufferedChangeset._handleValidation (webpack://__ember_auto_import__/./node_modules/validated-changeset/dist/validated-changeset.es5.js?:2447:18)
                at Proxy.BufferedChangeset._validateKey (webpack://__ember_auto_import__/./node_modules/validated-changeset/dist/validated-changeset.es5.js?:2425:23)
                at eval (webpack://__ember_auto_import__/./node_modules/validated-changeset/dist/validated-changeset.es5.js?:2211:24)
        message: >
            Assertion Failed: You attempted to update `_errors` on `changeset:[object Object]`, but it had already been used previously in the same computation.  Attempting to update a value after using it in a computation can cause logical errors, infinite revalidation bugs, and performance issues, and is not supported.

            `_errors` was first used:

            - While rendering:
              application
                forms
                  forms.form
                    form-workflow
                      form-workflow/form
                        form-for

Ini tampaknya merupakan internal dari ember-changeset-validations yang melakukan beberapa penghitungan ulang kesalahan, tetapi saya belum memiliki bandwidth untuk menggalinya. Sementara pernyataan itu tampaknya akurat dan valid, setelah itu meledakkan test suite saya berarti saya diblokir dari memutakhirkan ke 3.22 hingga saya dapat mengetahui apa yang terjadi.

Kena kau. FWIW pesan kesalahan memang terlihat setidaknya "berguna" untuk membantu debugging.

@Yelinz - Saya tidak berpikir masalah asli yang dilaporkan (di twiddle ) berada di ranah yang sama di sini (kesalahan twiddle itu setidaknya sejak 3.16) seperti yang

Seperti yang saya katakan di komentar saya sebelumnya dari 3,21 menjadi 3,22 dan situasinya mirip dengan @kpfefferle hanya dengan addon yang berbeda. Twiddle yang saya buat hanya untuk membangkitkan kesalahan itu. Kode aktual yang menyebabkannya adalah yang saya posting sebelumnya.

2020-10-12T09:38:40.7310067Z         actual: >
2020-10-12T09:38:40.7310575Z             [object Object]
2020-10-12T09:38:40.7311080Z         stack: >
2020-10-12T09:38:40.7314024Z             Error: Assertion Failed: You attempted to update `__instance` on `<ember-caluma<strong i="7">@component</strong>:x-toggle-switch::ember726>`, but it had already been used previously in the same computation.  Attempting to update a value after using it in a computation can cause logical errors, infinite revalidation bugs, and performance issues, and is not supported.
2020-10-12T09:38:40.7315638Z             
2020-10-12T09:38:40.7316183Z             `__instance` was first used:
2020-10-12T09:38:40.7316698Z             
2020-10-12T09:38:40.7317709Z             - While rendering:
2020-10-12T09:38:40.7318285Z               application
2020-10-12T09:38:40.7318787Z                 demo
2020-10-12T09:38:40.7319293Z                   application
2020-10-12T09:38:40.7319772Z             
2020-10-12T09:38:40.7320295Z             Stack trace for the update:
2020-10-12T09:38:40.7321118Z                 at dirtyTagFor (http://localhost:7357/assets/vendor.js:74216:9)
2020-10-12T09:38:40.7322185Z                 at markObjectAsDirty (http://localhost:7357/assets/vendor.js:31365:32)
2020-10-12T09:38:40.7323337Z                 at notifyPropertyChange (http://localhost:7357/assets/vendor.js:31403:5)
2020-10-12T09:38:40.7324352Z                 at _set2 (http://localhost:7357/assets/vendor.js:32379:9)
2020-10-12T09:38:40.7325263Z                 at Class.set (http://localhost:7357/assets/vendor.js:45923:29)
2020-10-12T09:38:40.7326501Z                 at Class.__teardownRecognizers (http://localhost:7357/assets/vendor.js:165238:14)
2020-10-12T09:38:40.7327580Z                 at sendEvent (http://localhost:7357/assets/vendor.js:30998:14)

Jejak tumpukan juga kurang lebih mirip dengan miliknya

Twiddle yang saya buat hanya untuk membangkitkan kesalahan itu

Ya, tetapi ada banyak skenario di mana kesalahan itu seharusnya dibuang (dan telah dibuang sejak dilacak diperkenalkan). Hal yang perlu kita cari tahu adalah skenario _new_ apa yang sekarang sedang dilacak yang sebelumnya tidak dilacak. Saya perlu memahami pola penggunaan untuk melakukan itu.

Setelah kami mengetahui apa pola penggunaannya, kami dapat mengetahui apakah kami dapat mengubah hal-hal untuk mengeluarkan penolakan alih-alih pernyataan, tetapi saat ini kami belum memiliki reproduksi yang mewakili masalah dunia nyata yang Anda hadapi jadi saya tidak tahu apakah kita dapat memodulasi pernyataan menjadi penghentian ...

Untuk orang lain yang datang ke sini, hal yang ingin saya lihat di sini adalah reproduksi (idealnya dalam bentuk kegagalan pengujian pada beberapa repo; apakah addon atau hanya aplikasi demo yang dibuat untuk tujuan ini) yang diteruskan 3.21 dan gagal pada 3.22.

Ini adalah ujian kelulusan kami di ember 3.21
https://github.com/projectcaluma/ember-caluma/pull/1065/checks?check_run_id=1241360614

Sementara itu kode yang sama gagal pada 3.22
https://github.com/projectcaluma/ember-caluma/pull/1065/checks?check_run_id=1241408429

Masalahnya berasal dari daftar panjang dependensi yang berakhir dengan gerakan ember dan cuplikan kode yang saya posting sebelumnya

Terima kasih atas semua bantuan Anda di sini (dan untuk mendukung saya ketika saya mencoba mencari tahu apa yang sedang terjadi)!

Saya akan bekerja untuk mengeluarkan ini dalam rilis patch segera.

@rwjblue Terima kasih kepada Anda dan @pzuraq untuk _melacak_ masalah!

:wave: @rwjblue , apakah Anda masih berharap untuk merilis patch 3.22.1 dengan perbaikan ini? Saya ingin meningkatkan aplikasi kami ke 3.22, beri tahu saya jika ada yang bisa saya lakukan untuk membantu.

Kami telah menemukan ini di banyak aplikasi kami karena pola yang dibuat sekitar ember-changeset-validations . Berikut adalah contoh pola yang kami gunakan:

import Component from '@glimmer/component';
import Changeset from 'ember-changeset';
import lookupValidator from 'ember-changeset-validations';
import OrderValidations from '../validations/order';

export default class OrderFormComponent extends Component {
  constructor() {
    super(...arguments);

    let model = this.args.model;
    this.changeset = new Changeset(
      model,
      lookupValidator(OrderValidations),
      OrderValidations
    );
    this.changeset.validate();
  }
}

this.changeset.validate() memicu kegagalan pernyataan di 3.22.0.

Saya baru saja memicu rilis v3.22.1 (https://github.com/emberjs/ember.js/releases/tag/v3.22.1), harus segera dipublikasikan ke NPM (setelah CI selesai).

Apakah perbaikan ini benar-benar disertakan dalam rilis v3.22.1, atau mungkin PR terkait tidak sepenuhnya memperbaiki masalah ini? Saya melihat https://github.com/emberjs/ember.js/pull/19193 di catatan rilis, tetapi proyek saya masih menunjukkan kegagalan pengujian yang sama seperti sebelumnya

Dikonfirmasi, juga masih melihat ini di 3.22.1

Membuka kembali untuk menyelidiki kembali. Demo yang disederhanakan/minimal (melewati 3.20 dan gagal pada 3.22) akan sangat membantu.

Berikut adalah contoh sederhana yang menghasilkan kesalahan dalam 3.22.1 , tetapi berfungsi di 3.21 :

export default class ExampleComponent extends Component {
  <strong i="9">@tracked</strong> count = 0;

  constructor() {
    super(...arguments);

    this.count++; // this fails in 3.22.1
  }
}

3.21 :

3.22.1 :

Apakah ada yang salah dengan membaca dan memperbarui properti yang dilacak di konstruktor? Model mental saya adalah bahwa ini akan baik-baik saja karena propertinya lokal ke komponen, dan kami belum merender apa pun ke DOM.

Contoh di atas juga memunculkan pernyataan tentang tag baru-baru ini 3.23

@GavinJoyce adalah contoh yang Anda berikan dengan komponen Glimmer? Kami hanya bermaksud untuk memperbaiki bug ini di komponen Klasik untuk alasan kompatibilitas mundur, di komponen Glimmer dan secara umum, kami _do_ mengharapkan mutasi seperti ini gagal selama render. Secara umum, tidak mungkin untuk membaca status terlacak dengan aman dan kemudian menulis ke status terlacak selama komputasi terlacak tunggal.

Kami bermaksud untuk mencakup semua jenis mutasi ini karena pernyataan awalnya diperkuat di 3.15, tetapi konstruktor terlewatkan karena fakta bahwa VM secara internal tidak menggunakan pelacakan otomatis.

Kita dapat membungkus ini dengan deprecateMutationsInAutotrackingFrame helper sehingga ia membuang sebuah penghentian alih-alih pernyataan untuk saat ini, untuk mencegah hal ini dari kemunduran aplikasi.

Kita dapat membungkus ini dengan deprecateMutationsInAutotrackingFrame helper sehingga ia membuang sebuah penghentian alih-alih pernyataan untuk saat ini, untuk mencegah hal ini dari kemunduran aplikasi.

Ya, ini masuk akal. Itu akan membuka blokir orang untuk saat ini, tetapi kami masih memerlukan aplikasi/addon/dll untuk memperbaiki masalah mendasar (kami tidak dapat mendukung "baca lalu tulis" dalam konteks pelacakan).

adalah contoh yang Anda berikan dengan komponen Glimmer?

Ya, itu adalah komponen Glimmer.

Berikut adalah contoh masalah dunia nyata yang kami lihat yang saat ini menghalangi kami untuk meningkatkan versi: https://github.com/GavinJoyce/backdrifts/pull/5

Mutasi data model (memanggil addFragment dalam kasus ini) dalam konstruktor tentu saja merupakan anti-pola, kemungkinan besar kita harus melakukan mutasi model semacam ini ketika kita membuat model dalam rute atau dalam fase tindakan . Mengeluarkan penghentian alih-alih pernyataan akan memberi aplikasi yang mengalami masalah seperti ini beberapa waktu untuk melakukan pemfaktoran ulang ini.

Mengeluarkan penghentian alih-alih pernyataan akan memberi aplikasi yang mengalami masalah seperti ini beberapa waktu untuk melakukan pemfaktoran ulang ini.

Sangat setuju! Saya akan mencoba untuk bekerja pada pagi ini.

Terima kasih, LMK jika saya dapat membantu dengan cara apa pun

Ini akan memerlukan beberapa perubahan dalam glimmer-vm yang saya kirimkan di https://github.com/glimmerjs/glimmer-vm/pull/1205 , tetapi integrasi Ember (untuk menjadikannya penghentian) ada di https://github. com/emberjs/ember.js/pull/19282.

Baru saja mendapatkan perubahan Glimmer yang diperlukan dan saya akan mencoba merilisnya besok.

Itu sedikit lebih terlibat daripada yang saya pikirkan, karena kita harus memastikan bahwa semua tipe objek memiliki perilaku penghentian (vs pernyataan). Saya _think_ https://github.com/emberjs/ember.js/pull/19282 akhirnya siap untuk ditinjau.

Langkah selanjutnya di sini adalah melakukan backport dan menguji perubahan dari glimmer-vm dalam banyak versi yang berbeda (di mana masing-masing memiliki perubahan internal di antara mereka):

• Backport di glimmer-vm
  
  
  
  • [email protected] - master menargetkan [email protected]
  
  
  • [email protected] - beta menargetkan [email protected]
  
  
  • [email protected] - release untuk [email protected]
  
  
• Backport perubahan dari #19282
  
  
  
  • beta cabang untuk [email protected]
  
  
  • release cabang untuk [email protected]
  
  
• Rilis perubahan
  
  
  
  • [email protected]
  
  

Saya belum 100% yakin, tetapi sepertinya saya akan merilis ini di 3.23.1+ (karena 3.22 bukan lagi rilis saat ini). Adakah yang memiliki kebutuhan khusus untuk ini di 3.22 dan tidak dapat memperbarui ke 3.23?

Saya sangat senang untuk memperbarui ke 3.23.

Mungkin saya perlu kopi lagi, tetapi dengan malu-malu saya akui bahwa saya tidak sepenuhnya memahami pola yang harus kita hindari. Saya mengerti contoh di mana Anda menetapkan nilai dalam pengambil, tetapi saya tidak begitu yakin mengapa contoh Gavin buruk (bahkan jika itu agak dibuat-buat). Apakah seseorang dapat membantu mendidik saya tentang masalah ini?

Saya tidak yakin apakah masih banyak yang harus dilakukan untuk meningkatkan aplikasi kita ke 3.22 atau 3.23. Kami memiliki ratusan tes yang gagal pada 3.22, sebagian besar dari mereka tampaknya mundur dari pernyataan yang saya harap akan diperbaiki oleh perubahan Anda. Semoga kita bisa langsung melompat dari 3.21 ke 3.23.1.

Jika tidak banyak beban tambahan, mungkin akan lebih baik untuk merilis 3.22.2 juga? Ini mungkin menyelamatkan orang-orang yang mengupgrade satu versi pada satu waktu beberapa sakit kepala di masa depan.

FYI Saya melihat ini dengan uji coba ember-beta berjalan di Mesin:

Kode yang menyinggung:

<LinkToExternal @route="your-coach">{{@coachUser.firstName}}</LinkToExternal>

@jherdman pastikan Anda menggunakan kode ember-mesin terbaru, link-to-external baru-baru ini diperbarui untuk menghindari pernyataan ini (di https://github.com/ember-engines/ember-engines/pull/735).

Saya menyesal untuk mengatakan bahwa saya memang menggunakan mesin v0.8.8. Saya tidak ingin menggagalkan masalah ini, haruskah saya membuka masalah di sana?

Saya menyesal untuk mengatakan bahwa saya memang menggunakan mesin v0.8.8. Saya tidak ingin menggagalkan masalah ini, haruskah saya membuka masalah di sana?

Ya silahkan!

Mungkin saya perlu kopi lagi, tetapi dengan malu-malu saya akui bahwa saya tidak sepenuhnya memahami pola yang harus kita hindari. Saya mengerti contoh di mana Anda menetapkan nilai dalam pengambil, tetapi saya tidak begitu yakin mengapa contoh Gavin buruk (bahkan jika itu agak dibuat-buat). Apakah seseorang dapat membantu mendidik saya tentang masalah ini?

Masalah konseptual di sini adalah ketika Anda mengubah nilai terlacak yang telah dibaca/dikonsumsi dalam "bingkai pelacakan" saat ini, kami tidak dapat menjamin bahwa nilai akhir yang diberikan valid. Misalnya, bayangkan pengaturan ini:

• sesuatu di rute aplikasi Anda mengakses {{this.someService.randomTrackedProperty}}
• kemudian di suatu tempat di templat rute bersarang Anda memanggil komponen seperti <FooBar />
• di FooBar s konstruktor itu melakukan this.someService.randomTrackedProperty = "hello!"

Komponen yang bermutasi membaca sebelumnya dilacak nilai berarti bahwa setiap referensi lain untuk nilai yang sekarang tidak valid.

Dalam contoh Gavin di atas, dia menambahkan penghitung, ini berarti Anda membaca nilai yang ada dan kemudian memperbarui ke nilai baru. Saya tahu ini tampaknya tidak berbahaya karena nilainya lokal untuk komponen dan dalam contoh itu tidak ada kode lain yang memiliki akses ke versi "tidak valid" (versi awal sebelum bermutasi), tetapi pada kenyataannya tidak ada yang istimewa tentang konstruktor! . Sistem yang dilacak adalah model reaktivitas holistik, dan sebenarnya tidak ada yang khusus tentang inisialisasi komponen/pembantu/pengubah (sistem berfungsi dengan baik jika Anda tidak merender apa pun).

Pembaruan cepat di sini, 3.23.1 dirilis dengan perbaikan. Saya akan mencoba untuk menyelesaikan 3.22.x besok (mengalami masalah memetik ceri).

Oke, 3.22.2 ditandai dan akan segera dipublikasikan ke NPM.

Terima kasih telah menandai 3.22.2, saya pikir akan sangat membantu bagi kita untuk melompat ke yang pertama.

FYI, sepertinya tidak dipublikasikan ke NPM 10 jam kemudian: https://www.npmjs.com/package/ember-source/v/3.22.2

Baru saja diperbaiki, maaf tentang itu

Terima kasih banyak!