Bagi mereka yang, selama akhir pekan yang panjang, siap untuk tidak hanya makan barbekyu, tetapi juga membaca semua jenis teks yang diperlukan, saya telah mengumpulkan sepuluh tautan Mei dari saluran pengembang Vimbox di perusahaan Skyeng Slack. Seperti terakhir kali, koleksi terkonsentrasi di sekitar kerangka Angular dan akan menarik bagi programmer yang bekerja dengannya.
Analisis yang sangat baik dari penyaji Ivy yang akan datang: ia menguraikan secara umum mengapa dibuat dan cara kerjanya di dalam.
“Sebelum kita masuk ke detail eksekusi, saya ingin mencurahkan beberapa paragraf untuk menjawab pertanyaan yang selalu muncul di kepala saya tentang perubahan. Ini adalah pertanyaan abadi: mengapa? "
Detail tentang konsep yang disebutkan dalam artikel Incremental DOM diimplementasikan di Ivy renderer, dan perbedaannya dari Virtual DOM - dalam artikel ini .
Nah, bagi mereka yang benar-benar bosan - dokumen desain resmi untuk kompiler Ivy .
Ulasan mini lainnya oleh Ivy renderer dengan gif tentang pekerjaan deteksi perubahan / kait siklus langsung, ditunjukkan oleh struktur objek internal dan demo di mana Anda dapat merasakannya dengan tangan Anda.
Saat yang menyenangkan dari artikel:
Catatan singkat tentang mengapa takeUntil harus selalu menjadi yang terakhir.
“ Apa masalahnya?
Jika operator takeUntil terletak di depan operator yang membuat langganan baru, maka setelah menerima pemberitahuan berhenti berlangganan takeUntil operator ini tidak akan berhenti berlangganan dan akan terus bekerja. "
Membuat animasi dengan RxJS
“Setiap kali Anda menghadapi masalah di mana waktu dan asinkron memainkan peran, pemikiran reaktif ditambah dengan perpustakaan reaktif seperti RxJS akan membawa Anda ke solusi yang lebih sederhana dan lebih dapat diandalkan. Dalam dunia koneksi konstan ini, cloud, platform non-blocking dan layanan microsoft, waktu dan asinkron akan memainkan peran yang semakin penting. ”
Mengapa layak menggunakan hanya ReactiveForms dan lupakan segala macam ngModel. Secara singkat dan to the point.
"Kenapa tidak menggunakan keduanya?"
Saya punya empat alasan:
1. Perkembangan sulit.
2. Kita harus memuat keduanya, dan bundel akan menjadi lebih sedikit.
3. Kami tidak dapat memprediksi apa yang akan dipilih pengembang, sehingga akan lebih sulit untuk memproses permintaan penarikan.
4. Menurut pendapat saya, selalu masuk akal untuk mematuhi satu paradigma jika tidak ada alasan serius untuk tidak melakukannya. "
Cukup permukaan anatomi @angular/router , atau apa yang terjadi saat bernavigasi.
“Dari artikel ini, kami mempelajari apa yang dilakukan router Angular ketika pengguna menavigasi dari satu halaman ke halaman lainnya.
Anda dapat menggunakan mnemonik PRIGRAM :
Keledai
R edirect
Saya gigit
Astaga
Esolve
Seekor burung
M anage
untuk mengingat urutan langkah-langkah yang diambil oleh router Angular.
Mengetahui proses ini akan memungkinkan Anda untuk lebih memahami apa yang terjadi di balik layar, dan membantu menyembuhkan potensi masalah dengan perutean. "
Sebuah cerita tentang bagaimana perbedaan disusun dalam Angular oleh contoh penulisan sendiri.
“Perbedaan sudut mungkin adalah API yang paling sedikit diketahui; ini adalah blok yang sangat optimal yang digunakan oleh Angular sendiri di dalam kerangka kerja (ngClass, ngStyle, ngFor, dll.).
Anda pasti tidak akan menggunakannya setiap hari, tetapi mereka bisa sangat berguna dalam kondisi tertentu. Jika Anda pernah berkata pada diri sendiri: "Tidak cukup bagi saya untuk mengetahui bahwa sesuatu telah berubah, saya perlu tahu apa yang sebenarnya telah berubah," perbedaan sudut akan memberi Anda jawaban. "
Contoh sederhana tentang cara mendapatkan @angular/elements dengan cepat dengan konfigurasi webpack sederhana untuk perakitan.
"Harap dicatat bahwa kami melakukan semuanya secara manual dan dari awal .
Di masa depan itu harus menjadi, dan akan menjadi, lebih mudah. Diharapkan bahwa semuanya akan dikonfigurasikan di dalam Angular CLI, dan menciptakan sebuah perakitan elemen akan menjadi masalah satu perintah cli.
Tetapi jika Anda mendengar tentang Elemen Sudut dan ingin mencobanya - ini adalah salah satu solusi yang mungkin. Saya akan membagikan yang kedua di artikel selanjutnya . "
Deskripsi berguna tentang cara kerja ChangeDetection.OnPush , tanpa membuka kode Angular. Ini sangat berguna bagi mereka yang tidak tahu / kurang mengerti bagaimana hidup dengannya.
“Teknik ini disebut pengecekan kotor. Untuk mengetahui apakah templat perlu diperbarui, Angular perlu mengambil nilai baru, membandingkannya dengan yang lama, dan berdasarkan ini membuat keputusan untuk memperbarui.
Bayangkan aplikasi hebat dengan ribuan pengikat; jika kami membiarkan Angular menguji masing-masing selama siklus deteksi perubahan, kami akan mengalami masalah kinerja.
Bagaimana jika Anda membantu Angular dengan memberi petunjuk kepadanya kapan harus memeriksa komponen kami? "
Versi kelima Nest telah dirilis - kerangka backend seperti Node.js yang luar biasa pada naskah. Mereka membuatnya bahkan lebih abstrak (memungkinkan Anda untuk menggunakan server http, tidak hanya mengekspresikan), menyesuaikan sintaks agar sesuai dengan Angular (dekorator / modul), menyisir modul layanan mikro, menyederhanakan penggergajian adaptor dan pustaka RPC alih-alih yang default.
Yah, tradisional: datanglah ke kami untuk bekerja! Kami selalu membutuhkan orang-orang keren !