Jadi sudut 8 keluar, itu termasuk pratinjau Ivy, dukungan untuk pekerja layanan, pemuatan diferensial, dan beberapa sentuhan akhir lainnya.
Manfred Steyer menjelaskan perubahan paling penting dalam rilis terbaru.
Seperti yang direncanakan, tidak ada kejutan: memperbarui kerangka kerja dan CLI dapat dilakukan dengan menggunakan pembaruan, dan fitur-fitur baru adalah tambahan yang bagus untuk moto "evolusi bukannya revolusi".
Dalam artikel ini, penulis berbicara tentang fitur-fitur baru yang paling penting dari Angular 8 dan Angular CLI 8. Contoh-contoh yang digunakan dalam artikel ini dapat ditemukan di
GitHub .
Di bawah potongan:
- Pertama kali melihat Ivy
- Pekerja web
- Pemuatan diferensial
- Modul pemuatan malas
- Perubahan Kritis di ViewChild dan ContentChild
- Fitur Baru ngUpgrade
Pertama kali melihat Ivy
Berita besar berikutnya yang ditunggu komunitas Angular adalah Ivy, kompiler baru, dan juga mesin rendering baru. Ivy dapat menghasilkan bundel yang jauh lebih kecil, kompilasi tambahan, dan juga merupakan dasar untuk inovasi masa depan di Angular.
Karena banyak bagian dasar Angular telah diubah, tim Angular telah memberikan perhatian khusus pada kompatibilitas dengan versi sebelumnya: setelah meningkatkan ke Ivy, aplikasi yang ada harus bekerja dengan cara yang sama seperti sebelumnya. Paling-paling, Anda akan mendapatkan bundel yang jauh lebih kecil. Ini bukan halangan, karena lebih dari 600 aplikasi di Google secara resmi didasarkan pada Angular - angka sebenarnya dikabarkan jauh lebih tinggi.
Dengan Angular 8, versi awal Ivy tersedia untuk pengujian. Tujuan dari versi ini adalah untuk mendapatkan umpan balik cepat. Oleh karena itu, tim sudut merekomendasikan untuk tidak menggunakan Ivy di prod sekarang, tetapi terus menggunakan mesin tampilan klasik (Gbr. 1)
Berkat pemuatan diferensial (seperti yang terlihat di bawah), ukuran bundel dapat dioptimalkan sekarang.
Menurut Brad Green, CTO dari tim Angular di Google, di ngconf 2019, Ivy akan secara signifikan meningkatkan ukuran paket dalam mode kompatibilitas dikombinasikan dengan pemuatan diferensial. Dengan demikian, pemberani sudah dapat menguji API Ivy di masa depan. Mode ini, khususnya, memiliki potensi besar untuk optimasi. API masih ditandai pribadi. Melihat kelas dan fungsinya, Anda dapat mengatakan: mereka mulai dengan simbol khusus ɵ.
Jika Anda sudah ingin mencoba Ivy, Anda dapat membuat proyek baru dengan sakelar enable-ivy:
ng new ivy-project --enable-ivy
Kunci ini memberitahu CLI untuk menyimpan entri berikut di konfigurasi tsconfig.app.json:
"angularCompilerOptions": { "enableIvy": true }
Entri ini juga dapat ditambahkan secara manual setelah memutakhirkan ke versi 8, untuk menguji aplikasi yang ada menggunakan Ivy.
Untuk menjalankan aplikasi dalam mode debug, disarankan untuk menggunakan AOT:
ng serve --aot
Selain itu, Anda harus memperhatikan ukuran aplikasi yang dibuat menggunakan ng build. Dengan sudut 9, Ivy harus diaktifkan secara default. Sampai saat itu, tim Angular berencana untuk terus bekerja untuk memastikan kompatibilitas dengan versi yang lebih lama.
Pekerja web
JavaScript adalah utas tunggal berdasarkan definisi. Karena itu, tugas yang memakan waktu, seperti kueri data, biasanya dilakukan secara tidak serempak. Tidak perlu dikatakan, ini tidak membantu dalam perhitungan yang rumit. Mereka terutama menjadi lebih umum dengan solusi JavaScript yang luas, jadi kami mendukung pekerja web di hampir semua browser web. Ini adalah skrip yang diluncurkan oleh browser di utas terpisah. Komunikasi dengan streaming di tab browser dilakukan melalui pesan.
Meskipun pekerja web tidak terkait dengan Angular, mereka harus diperhitungkan saat membangun. Tujuannya adalah untuk menyediakan satu paket untuk setiap pekerja web. Tugas ini telah diselesaikan oleh CLI baru.
Untuk menunjukkan fitur baru, saya akan menunjukkan JavaScript implementasi dari apa yang disebut "
masalah n queens ." Idenya adalah menempatkan satu ratu dalam satu baris di papan catur, tanpa dapat saling mengancam. baris, kolom atau diagonal yang sama tidak boleh menjadi ratu lain.
Algoritma untuk menghitung semua solusi yang mungkin pada papan catur dianggap kompleks secara komputasi. Meskipun perhitungan untuk papan catur delapan baris dan delapan kolom cukup cepat, komputer konvensional telah mencapai batas dengan papan 12 x 12. Solusi untuk papan 27 x 27 adalah catatan saat ini. Untuk tugas ini, superkomputer Rusia digunakan.
Untuk menerjemahkan perhitungan ini ke latar belakang, pertama-tama kita harus membuat pekerja web menggunakan CLI:
ng generate worker n-queens
Instruksi ini membuat file tidak hanya untuk karyawan, tetapi juga untuk file konfigurasi yang diperlukan untuk proses pembuatan dan entri dalam file yang ada. Jika folder yang sama berisi komponen dengan nama yang sama dengan ekstensi file .component.ts yang umum, CLI juga akan menambahkan kode untuk berinteraksi dengan pekerja web.
Pekerja itu sendiri terdiri dari pendengar untuk acara tersebut:
import nQueens from './n-queens'; addEventListener('message', ({ data }) => { const result = nQueens(data.count); postMessage(result, undefined); });
Acara dijalankan ketika utas mengirim pesan ke pekerja. Parameter berisi informasi yang dikirim dari arus utama. Dalam hal ini, dibatasi oleh properti hitungan, yang menentukan ukuran papan catur. Setelah mengevaluasi fungsi nQueens, yang dihilangkan di sini, eventListener mengirim hasilnya kembali ke utas utama melalui postMessage. Dengan demikian, browser menampilkan peristiwa pesan.
Kelas Worker digunakan dalam komponen using untuk berinteraksi dengan skrip pekerja:
const count = parseInt(this.count, 10); const worker = new Worker('../logic/n-queens.worker', { type: 'module'
Komponen mengirimkan pesan dengan ukuran papan catur yang diinginkan kepada pekerja melalui postMessage dan dengan demikian memulai perhitungan di sana. Ini menerima hasilnya melalui acara pesan.
Di masa depan, CLI menangani perakitan skrip pekerja yang benar. Compiler TypeScript mengenali mereka di akhir .worker.ts, yang terdaftar di tsconfig.worker.json yang dibuat oleh perintah
ng menghasilkan pekerja . Untuk memastikan bahwa CLI tidak mempengaruhi file-file ini lagi ketika membangun aplikasi utama,
ng menghasilkan pekerja menempatkan templat file yang sama di bagian mengecualikan tsconfig.app.json.
Implementasi penuh ada dalam proyek dengan contoh-contoh penulis. Sebagai perbandingan, contoh tugas N queens dapat diselesaikan baik di utas utama maupun di pekerja web. Ketika Anda mencoba memecahkan masalah untuk papan catur 12 x 12, misalnya, Anda akan melihat bahwa UI hang dalam kasus pertama, sedangkan perhitungan latar belakang dengan pekerja web tidak akan mengurangi kinerja.
Pemuatan diferensial
Sampai sekarang, sudah biasa untuk mengkompilasi aplikasi ke dalam ES 5 lama yang baik, karena versi "JavaScript ayah kami" ini bekerja hampir di mana-mana. Ini berarti bahwa IE11 dan perayap web Google dapat mengeksekusi kode ini.
Namun, ES 2015 yang baru dan versi selanjutnya lebih efisien: mereka memungkinkan Anda untuk membuat paket yang lebih ringkas dan peramban juga dapat menafsirkannya dengan lebih efisien. Karena sebelumnya sudah biasa untuk kembali ke ES 5 sebagai penyebut yang paling tidak umum, browser modern, sayangnya, tidak dapat mengambil keuntungan dari versi bahasa yang baru.
Sekarang sudah berakhir: dimulai dengan versi 8, CLI memiliki fitur yang disebut pembebanan diferensial. Idenya adalah untuk menyediakan dua kelompok paket: satu berdasarkan ECMAScript 5 dan dirancang untuk browser yang lebih lama, yang lain berdasarkan pada versi baru ECMAScript, seperti ECMAScript 2015, dan menyediakan browser modern dengan manfaat yang disebutkan sebelumnya.
Anda tidak perlu melakukan banyak pekerjaan untuk mengaktifkan pemuatan diferensial: yang diperlukan hanyalah mengatur batas atas dan bawah dari versi ECMAScript yang didukung. Batas atas ditunjukkan dalam tsconfig.json sebagai berikut:
"target": "es2015"
Batas bawah didefinisikan dalam file daftar browser. File ini termasuk browser yang akan didukung sesuai dengan kriteria tertentu, seperti pangsa pasar, misalnya. Mereka dapat disimpan, misalnya, dalam file daftar browser, yang dibuat CLI di root proyek ketika membuat proyek baru:
> 0.5%
last 2 versions
Firefox ESR
not dead
IE 9-11
Dalam hal ini, daftar browser menyertakan browser ES 5 dengan entri IE 9-11. Dengan demikian, CLI mendefinisikan ambang yang lebih rendah sebagai versi ini. Ketika CLI menerima perintah ng build, proses build akan berjalan untuk kedua versi:
Kerugian dari proses ini adalah ini: waktu yang dibutuhkan untuk perakitan berlipat ganda.
Browser sekarang dapat memutuskan versi paket mana yang akan diunduh. Untuk melakukan ini, mereka mendapatkan tautan ke skrip dalam add-on index.html: mereka yang menunjuk ke paket ECMAScript 5 menerima penambahan nomodule. Dengan demikian, browser dengan dukungan ECMAScript dan, karenanya, dukungan ECMAScript 2015+ tidak akan mengabaikan skrip ini. Di sisi lain, paket ECMAScript 2015+ diimplementasikan oleh CLI dengan type = "module". Dengan demikian, browser lama akan mengabaikan skrip ini:
<script src="main-es2015.js" type="module"></script> <script src="main-es5.js" nomodule></script>
Tidak seperti ng build, perintah CLI lainnya hanya menggunakan (!) Batas atas dukungan ES. Dalam kasus kami, ini adalah ECMAScript 2015. Ini terjadi, termasuk untuk alasan efisiensi: selama debugging dan pengujian, pengembang biasanya ingin melihat hasilnya sesegera mungkin, tanpa menunggu build kedua.
Modul pemuatan malas
Sejak hari-hari pertama, router sudut mendukung pemuatan yang malas. Sampai sekarang, ini telah dicapai dengan definisi ajaib dari modul yang dapat dimuat:
{ path: 'lazy', loadChildren: () => './lazy/lazy.module#LayzModule' }
Nilai sebelum # menjelaskan jalur yang mengarah ke file implementasi modul; nilai setelah berarti kelas yang terkandung di dalamnya. Gaya uraian ini berfungsi di Angular 8, tetapi telah usang sehubungan dengan impor dinamis ECMAScript:
{ path: 'lazy', loadChildren: () => import('./lazy/lazy.module').then(m => m.LazyModule) }
Opsi rekam baru masih berisi nama file sebagai nilai ajaib. Namun, karena impor didukung oleh banyak IDE, nilai yang tidak valid akan segera mengembalikan kesalahan.
Perubahan Kritis di ViewChild dan ContentChild
Ada perubahan kritis untuk penggunaan ViewChild dan ContentChild, yang, sayangnya, di masa lalu tidak selalu berhasil diprediksi. Jika dalam versi sebelumnya mereka digunakan oleh komponen untuk kueri elemen yang tidak di dalam arahan struktural, seperti ngIf atau ngFor, hasil kueri sudah tersedia di ngOnInit. Kalau tidak, kita bisa mengaksesnya tidak lebih awal dari ngAfterViewInit (atau ngAfterContentInit untuk ContentChild). Untuk elemen yang dimuat ke DOM nanti karena pengikatan data, kode program harus ngAfterViewChecked atau, karenanya, ngAfterContentChecked.
Karena perilaku ini membingungkan, komponen sekarang harus menunjukkan kapan resolusi harus terjadi:
@ViewChild('info', { static: false }) paragraph: ElementRef;
Jika flag statis benar, Angular akan mencoba menemukan elemen ketika komponen diinisialisasi. Ini hanya berfungsi jika mereka tidak berada dalam arahan struktural. Saat menggunakan statis: false, resolusi dilakukan setelah menginisialisasi atau memperbarui tampilan.
ng pembaruan akan mencoba untuk secara otomatis memasukkan nilai yang benar, jika ini tidak mungkin, itu akan menambahkan komentar dengan TODO.
Perubahan ini tidak akan memengaruhi kueri dengan dekorator ViewChildren dan ContentChildren. Mereka selalu memiliki perilaku dinamis, dalam istilah baru dalam arti statis: salah.
Fitur Baru ngUpgrade
Sejauh ini, salah satu masalah dengan AngularJS 1.X dan Angular digabung dengan ngUpgrade adalah bahwa router dari kedua kerangka kerja bersaing karena URL. Hal ini menyebabkan sulitnya menjelaskan efek samping. Untuk menghindari hal ini, kemampuan untuk menggunakan layanan lokasi URL tunggal di kedua versi ditambahkan.
Untuk melakukan ini, tim Angular memperluas kemampuan layanan lokasi Angular dan dengan demikian memberikan pengganti $ lokasi di AngularJS.
Karena alasan ini, metode onUrlChange baru telah ditambahkan ke layanan lokasi untuk melacak perubahan URL:
export class AppComponent { constructor(loc: Location, pLoc: PlatformLocation) { loc.onUrlChange((url) => console.debug('url change', url)); console.debug('hostname: ', pLoc.hostname); } }
Layanan PlatformLocation menawarkan akses tambahan ke bagian-bagian tertentu dari URL. Penjelasan terperinci tentang bagaimana penggantian $ lokasi berdasarkan itu digunakan untuk kerangka kerja integrasi yang lebih baik dapat ditemukan di
sini . Selain itu, Anda sekarang dapat menemukan solusi pemuatan malas AngularJS, yang didasarkan pada impor ECMAScript dinamis yang disebutkan sebelumnya.
Kesimpulan
Sekali lagi, tim Angular menepati janji mereka: transisi ke versi baru Angular sederhana dan tidak termasuk perubahan besar. Sebaliknya, beberapa sudut dihaluskan, membuat bekerja dengan kerangka SPA Google menjadi lebih nyaman. Pemuatan diferensial memberikan peluang untuk pengoptimalan ukuran paket lebih lanjut jika browser lama tidak didukung atau didukung oleh paket terpisah. Dukungan untuk pekerja Web menunjukkan bahwa tugas intensif komputasi menemukan cara mereka untuk memproses di browser. Penggemar sekarang dapat mengambil langkah pertama mereka dengan Ivy.
PS: Ini adalah terjemahan pertama saya, jadi tolong perhatikan komentar, saran dan kesalahan dalam komentar.