Bit Pantas Logik Bersyarat: Keperluan & Kes Tepi

Kami membangunkan kemahiran untuk membaca dan menulis keadaan logik dari semasa ke semasa, dan ciri bahasa baharu boleh memberikan kami penyelesaian baharu. Tetapi tidak semua penyelesaian adalah sama. Mari kita lihat contoh sekilas.

Persediaan

Katakanlah kami mempunyai harta yang mungkin wujud di berbilang tempat dan kami ingin mengutamakan contoh bersarang. Berikut adalah beberapa penyelesaian yang mungkin:

// Option A: Ternary
const setting = config.user ? config.user.setting : config.setting;

// Option B: Optional Chaining and Nullish Coalescing
const setting = config.user?.setting ?? config.setting;

// Option C: Destructuring and Nullish Coalescing
const { setting } = config.user ?? config;

Lihat Perbezaan

Ini kelihatan agak serupa dari segi fungsi, tetapi terdapat perbezaan yang ketara. Bergantung pada keperluan perniagaan atau reka bentuk data kami, sesetengah daripada ini mungkin menyebabkan pepijat.

Lihat tiga pilihan dan lihat sama ada anda boleh mengenal pasti senario berbeza yang hasilnya akan berbeza. Apakah andaian yang kami buat dengan setiap versi?

Analisis Operator

Mula-mula, pertimbangkan pengendali khusus yang sedang bermain.

• Ternary - menggunakan semakan benar untuk menentukan ungkapan yang digunakan.
• Perantaian Pilihan - mengembalikan tidak ditentukan jika objek itu batal tetapi tidak jika ia hanya palsu.
• Nullish Coalescing - menggunakan ungkapan kedua jika yang pertama nullish.

Bukan Nullish

Pengendali ternary menonjol, di sini. Untuk kebanyakan tujuan praktikal ia akan berkelakuan dengan cara yang sama apabila kita bercakap tentang objek. Perbezaan bergantung kepada nilai yang kita jangkakan apabila keadaan tidak berfungsi.

Objek yang tidak ditetapkan biasanya tidak ditentukan atau batal. Tetapi jika projek kami menggunakan palsu atau 'Bukan objek, lagi!', andaian yang dibuat dengan ternary boleh menghasilkan hasil yang tidak diingini. Ini adalah kes tepi yang agak tidak mungkin.

Memahami Niat

Jika kita mengabaikan senario "bukan objek" yang tidak mungkin, Pilihan A dan C pada asasnya adalah sama.

1. Jika config.user wujud, dapatkan config.user.setting.
2. Jika tidak, dapatkan config.setting.

Pilihan B melakukan sesuatu yang berbeza.

1. Jika config.user.setting wujud, gunakannya.
2. Jika tidak, dapatkan config.setting.

Perbezaannya adalah kecil tetapi bercakap terus kepada keperluan atau keputusan reka bentuk teknikal: Adakah kita kembali kepada tetapan konfigurasi jika pengguna tiada, atau hanya jika tetapan pengguna tiada?

Kedua-duanya adalah kemungkinan yang sah, tetapi jika kita membuat andaian yang salah, kita mungkin tidak mendapat apa-apa apabila kita menjangkakan lalai, atau sesuatu apabila kita tidak mengharapkan apa-apa.

Kesimpulan

Tiada "jawapan yang betul" di sini selain bertanya apa matlamatnya. Kami memerlukan lebih banyak konteks. Meminta untuk menjelaskan soalan ini mungkin kelihatan membingungkan kepada ahli projek, tetapi butiran kecil ini boleh membuat pepijat yang sangat halus jika kami tidak mempunyai penjajaran pada jangkaan.

Mungkin terdapat jawapan yang tepat untuk projek ini atau untuk keseluruhan syarikat. Kami mungkin menggunakan beberapa pilihan dalam satu projek; satu untuk memberi tumpuan kepada nilai; satu lagi untuk memberi tumpuan kepada struktur. Mungkin tiada siapa yang menganggap perbezaan ini. Mungkin pasukan itu berfikir mereka sejajar sedangkan mereka tidak.

Anda tidak akan tahu jika anda tidak bertanya.

Atas ialah kandungan terperinci Bit Pantas Logik Bersyarat: Keperluan & Kes Tepi. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!