Mustache.js: Tambahkan opsi: Peringatan pada variabel yang tidak dikenal

Suka fitur ini dari kerangka kerja lain saat mengembangkan secara lokal, jadi beri +1 dari saya! Saya pikir itu penting memiliki dampak minimal atau tidak ada pada kinerja. Mungkin bahkan bisa dilakukan sambil menjaga inti apa adanya? Misalnya dengan mengganti beberapa metode internal untuk mengaktifkan perilaku semacam ini saat berkembang.

Mungkin mustache.dev.js yang dibangun menggunakan mustache.js dan fungsi menimpa yang berisi logika pemeriksaan?

Saya lebih suka kesalahan keras, sehingga, misalnya, saat menggunakan dengan Express, itu menjadi respons 500 dan bukan hanya log di suatu tempat sementara pengguna akhir melihat halaman yang dirender secara salah (berpotensi sangat salah dirender, tergantung pada bagaimana yang hilang variabel seharusnya digunakan); ini bahkan bisa lebih berguna dalam produksi daripada dalam pengembangan lokal, tergantung pada seberapa bagus 500 halaman Anda vs. seberapa buruk halaman yang salah dirender untuk fungsionalitas aplikasi Anda. Penggunaan bagian masih memungkinkan templat untuk mengabaikan variabel yang hilang bahkan dengan kesalahan besar untuk penggunaan langsung. Dan penggunaan tingkat tinggi apa pun yang perlu mencatat masalah akan mengendalikan sistem logging, jadi kita tidak perlu khawatir tentang, katakanlah, mekanisme peringatan internal Kumis yang merusak output dari pelari uji atau hal-hal seperti itu.

Saya memiliki prototipe yang berfungsi di https://github.com/ScottFreeCode/mustache.js , meskipun saya dapat menggunakan bantuan untuk mencari tahu cara menulis tes untuk itu.

Hmm, jadi menggunakan keberadaan objek sebagai if ( {{#thing}} ) akan menimbulkan kesalahan? (Saya pikir ini cukup umum)

Atau hanya rendering variabel yang sebenarnya ( {{ id }} ) yang akan menimbulkan kesalahan? Apa yang kamu pikirkan?

Sunting: fitur yang sangat keren yang akan saya beri +1 untuk diaktifkan secara default di jurusan jika itu tidak merepotkan.

Dalam pikiran saya yang pertama seharusnya merupakan kesalahan, yang kedua adalah 'peringatan'.
Untuk keduanya saya ingin tahu ada nilai yang hilang.

Meskipun dalam kasus kedua mungkin tidak rusak secara teknis, itu bisa berdampak besar pada halaman.

Juga, sebaliknya akan menyenangkan: variabel yang tidak digunakan ... Tapi itu lebih banyak dampak yang harus dibuat, saya pikir! :D

Pada 8 Nov 2016, di 14:19, David da Silva [email protected] menulis:

Hmm, jadi menggunakan keberadaan objek sebagai if ({{#thing}}) akan menimbulkan kesalahan? (Saya pikir ini cukup umum)

Atau hanya rendering variabel yang sebenarnya ({{ id }}) yang akan menimbulkan kesalahan? Apa yang kamu pikirkan?

—
Anda menerima ini karena Anda yang menulis utas.
Balas email ini secara langsung, lihat di GitHub https://github.com/janl/mustache.js/issues/599#issuecomment -259133973, atau nonaktifkan utas https://github.com/notifications/unsubscribe-auth/ AJ8FmSptdhysYrQpg1ODkIrm12A_TXcYks5q8HbbgaJpZM4J8lKe.

Dalam pikiran saya yang pertama seharusnya merupakan kesalahan, yang kedua adalah 'peringatan'.
Untuk keduanya saya ingin tahu ada nilai yang hilang.

@MatthijsZw saya melihat. Saya baru ingat Anda dapat menyimpan nilai null untuk properti, yang merupakan hal yang baik untuk dilakukan, dan oleh karena itu tidak ada pengecualian yang akan terjadi. (menyebutkan ini secara khusus untuk kasus if )

Sunting: Posisi saya saat ini adalah saya lebih suka Err pada keduanya. Saya lebih suka perilaku yang konsisten, dan Anda akan menerapkan penggunaan null untuk nilai yang hilang kosong, yang menurut saya lebih disukai.

Juga, sebaliknya akan menyenangkan: variabel yang tidak digunakan ... Tapi itu lebih banyak dampak yang harus dibuat, saya pikir! :D

Saya berpikir bahwa akan sangat keren untuk mendapatkan Skema untuk data yang diharapkan oleh templat, dan menggunakannya untuk menghasilkan kueri GraphQL ... atau yang serupa.

Pada refleksi lebih lanjut, saya pikir bagian dari masalah di sini adalah bahwa data yang hilang tidak valid _karena_ -- dan oleh karena itu _hanya jika_ -- templatenya _mengharapkan_ data tersebut. Jadi, data yang hilang yang hanya ditampilkan oleh templat selalu tidak valid oleh logika itu, tetapi mungkin saja templat di satu tempat mengharapkan data tertentu tersedia dan bercabang di atasnya sebagai semacam tanda benar/salah (jadi tidak valid jika tidak salah seperti hilang dan karena itu tidak memenuhi harapan itu), tetapi di lain mungkin berharap bahwa data mungkin atau mungkin tidak tersedia dan bercabang pada apakah itu (dalam hal ini tidak pernah tidak valid).

Dalam perspektif itu, menggunakan null untuk mengontrol ini tidak terlalu masuk akal bagi saya:

• Jika data salah -- tidak memenuhi harapan -- bagaimana kita bisa mengharapkan data yang salah untuk mengontrol perilaku template tentang penanganan data yang salah?
• Harapannya benar-benar ada dalam template.
• null bisa menjadi nilai falsey untuk cabang kebenaran yang mengharapkan data dan menganggapnya tidak valid untuk data yang hilang, tapi itu masih membuat kita perlu bercabang pada tepatnya apakah data diberikan sama sekali karena kita berharap bahwa data mungkin tidak diisi (bahkan dengan null , kecuali itu berasal dari sumber yang menggunakan null untuk data yang hilang, misalnya SQL -- dan sebenarnya, itu menunjukkan apakah akan memperlakukan null sebagai hilang atau tidak harus dapat dikonfigurasi berdasarkan sumber data).

Yang kita butuhkan adalah dua jenis cabang, untuk harapan yang berbeda pada bagian template. Yang setahu saya sangat disayangkan karena spesifikasi Kumis agnostik bahasa, sementara itu memungkinkan untuk (tetapi tidak mengamanatkan) konfigurasi apakah data yang hilang adalah kesalahan, sejauh yang saya tahu tidak memiliki apa pun untuk jenis cabang yang berbeda itu akan berbeda dalam hal ini. Hmm...

Di sisi lain, saya saat ini berpikir bahwa data asing/surplus/tidak digunakan sebenarnya bukan masalah data tidak valid, ini masalah template yang tidak valid jika tidak menggunakan data itu saat aplikasi/data/ model mengharapkannya untuk digunakan. Artinya, jika beberapa hal berpotensi dapat digunakan tetapi template dapat memutuskan apakah itu relevan, maka tidak masalah apakah template mencetak hal itu, tetapi jika beberapa hal benar-benar _perlu_ ditampilkan kepada pengguna, maka jika template tidak' t menampilkannya itu kesalahan. Sebagai semacam pembalikan, harapan terletak di luar template (dalam model?) dan ketidakabsahan gagal memenuhi harapan itu terletak pada template. Mungkin yang terbaik untuk mengatasinya secara terpisah, saya pikir.

Di atas, saya kira, pendapat yang kuat dipegang dengan lemah.

IMO menafsirkan nilai null sebagai nilai yang tidak ada adalah salah.

{ name: null }

objek itu memiliki properti name dengan nilai palsu, dan karena itu tidak boleh dianggap tidak valid dan oleh karena itu bukan alasan untuk membuang.

Pemeriksaan yang lebih tepat adalah memeriksa apakah properti yang diminta telah didefinisikan seperti yang kita lakukan di mustache.hasProperty() .

tetapi di lain mungkin mengharapkan bahwa data mungkin atau mungkin tidak tersedia dan cabang apakah itu (dalam hal ini tidak pernah tidak valid).

Apa yang saya coba sampaikan adalah bahwa, jika Anda bercabang bergantung pada kunci X (misalnya {{#X}} , data yang diberikan harus memiliki nilai untuk kunci X , baik yang benar atau nilai palsu, tapi jelas bukan undefined .

• null menyiratkan "ya, saya tahu bahwa tidak ada nilai. Saya secara eksplisit menandai bahwa tidak ada nilai".
• undefined sebagian besar menyiratkan bahwa kunci X bahkan tidak didefinisikan (jika Anda mendefinisikan kunci dengan nilai undefined Anda akan lebih baik menggunakan null ) . Dan jika kuncinya tidak ditentukan, itu karena 'malas' mendeklarasikan data (misalnya tidak menggunakan null ketika referensi objek tidak ada) atau karena kesalahan manusia (salah ketik, terpeleset, bingung)

Jadi, dalam hal ini, saya akan melihat manfaat dalam melempar Kesalahan. (mencoba bercabang pada kunci yang memiliki nilai undefined )

Di kasus lain, mencoba merender undefined atau null , tidak yakin apakah ada kasus penggunaan untuk itu. Mungkin Err yang satu itu juga.

kecuali itu berasal dari sumber yang menggunakan null untuk data yang hilang, misalnya SQL

Afaik, Filosofi Kumis bukan untuk menggunakan model apa adanya, tetapi untuk menghasilkan 'pandangan' dari mereka. Anda dapat menambahkan null s jika penyedia Anda tidak melakukannya.

Saat ini saya berpikir bahwa data asing/surplus/tidak digunakan sebenarnya bukan masalah data yang tidak valid, ini masalah template yang tidak valid jika tidak menggunakan data itu ketika aplikasi/data/model mengharapkannya digunakan

Hmm, menurut saya cukup umum untuk tidak menggunakan semua data yang disediakan. Saya melemparkan ide itu terutama untuk hal-hal yang menyenangkan, seperti pembuatan kueri GraphQL yang saya sarankan.

jika beberapa hal benar-benar perlu ditampilkan kepada pengguna, maka jika template tidak menampilkannya, itu adalah kesalahan

Tetapi siapa/apa yang memutuskan "hal-hal yang benar-benar perlu ditampilkan kepada pengguna"? Penulis template saya kira? Jika Anda memaksa orang untuk menggunakan semua data dalam tampilan, maka Anda memaksa mereka untuk membuat tampilan yang disesuaikan untuk setiap template yang ingin mereka render.

Sebagai catatan: use case saya adalah pengaturan manual tanpa percabangan.

Saya meminta 'orang lain' membuat data (acara) secara manual dan dalam hal ini saya tidak memiliki cara untuk memverifikasi bahwa mereka mengisi semua bidang atau membuat kesalahan ketik pada nama-variabel.

Template saya akan mengatakan “{{ event.name }} pada {{ event.date }}”. Dalam hal ini nilai yang hilang akan membuat halaman yang mengerikan.
Semua bidang wajib diisi, jadi menambahkan logika untuk tidak menampilkan {{ event.date }} tidak masuk akal.

Dalam hal ini variabel 'tidak digunakan' akan bagus untuk diketahui juga, untuk memeriksa ulang kesalahan ketik atau untuk item yang mereka tambahkan berpikir mereka akan 'secara ajaib' muncul di halaman :)

Saya yakin use case ini entah bagaimana melanggar ideologi Moustache, tetapi ini adalah skenario nyata.
Dan akan sangat bagus untuk kedua situasi (nilai yang hilang + nilai yang tidak digunakan) untuk menghasilkan peringatan.

Pada 9 November 2016, pukul 10:53, David da Silva [email protected] menulis:

tetapi di lain mungkin mengharapkan bahwa data mungkin atau mungkin tidak tersedia dan cabang apakah itu (dalam hal ini tidak pernah tidak valid).

Apa yang saya coba sampaikan adalah bahwa, jika Anda bercabang bergantung pada kunci X (misalnya {{#X}}, data yang diberikan harus memiliki nilai untuk kunci X, baik nilai benar atau salah, tetapi jelas tidak tidak terdefinisi.

null menyiratkan "ya, saya tahu bahwa tidak ada nilai. Saya secara eksplisit menandai bahwa tidak ada nilai".
undefined sebagian besar menyiratkan bahwa kunci X bahkan tidak ditentukan (jika Anda mendefinisikan kunci dengan nilai tidak terdefinisi, Anda akan lebih baik menggunakan nol). Dan jika kuncinya tidak ditentukan, itu karena 'malas' mendeklarasikan data (misalnya tidak menggunakan null ketika referensi objek tidak ada) atau karena kesalahan manusia (salah ketik, slip, kebingungan)
Jadi, dalam hal ini, saya akan melihat manfaat dalam melempar Kesalahan. (mencoba bercabang pada kunci yang memiliki nilai tidak terdefinisi)

Di kasus lain, mencoba merender tidak terdefinisi atau nol, tidak yakin apakah ada kasus penggunaan untuk itu. Mungkin Err yang satu itu juga.

kecuali itu berasal dari sumber yang menggunakan null untuk data yang hilang, misalnya SQL

Afaik, Filosofi Kumis bukan untuk menggunakan model apa adanya, tetapi untuk menghasilkan 'pandangan' dari mereka. Anda dapat menambahkan nol jika penyedia Anda tidak melakukannya.

Saat ini saya berpikir bahwa data asing/surplus/tidak digunakan sebenarnya bukan masalah data yang tidak valid, ini masalah template yang tidak valid jika tidak menggunakan data itu ketika aplikasi/data/model mengharapkannya digunakan

Hmm, menurut saya cukup umum untuk tidak menggunakan semua data yang disediakan. Saya melemparkan ide itu terutama untuk hal-hal yang menyenangkan, seperti pembuatan kueri GraphQL yang saya sarankan.

jika beberapa hal benar-benar perlu ditampilkan kepada pengguna, maka jika template tidak menampilkannya, itu adalah kesalahan

Tetapi siapa/apa yang memutuskan "hal-hal yang benar-benar perlu ditampilkan kepada pengguna"? Penulis template saya kira? Jika Anda memaksa orang untuk menggunakan semua data dalam tampilan, maka Anda memaksa mereka untuk membuat tampilan yang disesuaikan untuk setiap template yang ingin mereka render.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub https://github.com/janl/mustache.js/issues/599#issuecomment -259374603, atau nonaktifkan utas https://github.com/notifications/unsubscribe-auth/ AJ8FmcFicDWYjSqibyWac-Sqjg-iFetnks5q8ZgqgaJpZM4J8lKe.

Saya yakin use case ini entah bagaimana melanggar ideologi Moustache, tetapi ini adalah skenario nyata. Dan akan sangat bagus untuk kedua situasi (nilai yang hilang + nilai yang tidak digunakan) untuk menghasilkan peringatan.

Keduanya tampak layak. Ini bisa berguna untuk CI.

Saya lebih suka melihat parameter secara langsung dalam tampilan untuk debugging.

Kasus penggunaan saya sedikit berbeda: Saya menggunakan Kumis untuk mengubah template Terraform menggunakan Gulp. Variabel yang hilang dapat menyebabkan instance tidak dapat di-boot dengan benar, terutama saat mengganti string bentuk bebas. Saya datang dengan tambalan monyet cepat untuk mendapatkan fungsi ini tetapi itu hampir tidak ideal:

var mustache = require("mustache");

var errors = [];
var lookup = mustache.Context.prototype.lookup;

mustache.Context.prototype.lookup = function(name) {
    var value = lookup.bind(this)(name);

    if (value === undefined) {
        console.error("Unknown symbol", name);
        errors.push(name);
    }

    return value;
}

var render = mustache.render;

mustache.render = function(template, view, partials) {
    var result = render.bind(this)(template, view, partials);

    if (errors.length > 0) {
        throw {message: "Unknown symbols: " + errors.join(", ")};
    }

    return result;
}

Catatan:

• Itu tidak memberi Anda nomor baris atau nama simbol yang sepenuhnya memenuhi syarat
• Mungkin benar-benar tidak aman jika Anda bekerja di lingkungan multithread

Namun itu bekerja dengan baik untuk tujuan saya dan saya yakin seseorang dapat menyesuaikannya jika diperlukan.

Menggunakan kumis sebagai mesin templating dalam segala jenis lingkungan manajemen konfigurasi memerlukan kesalahan besar pada variabel yang hilang. Saya memiliki kasus penggunaan yang mirip dengan @steverukuts , mengubah dokumen penyebaran kubernetes. Variabel yang hilang selalu merupakan kesalahan dalam kasus penggunaan ini.

@stefaneg beberapa bulan setelah menulis bahwa sebenarnya saya menemukan bahwa Terraform mendukung konfigurasi yang ditulis dalam format JSON jadi sekarang saya menggunakan ini daripada menggunakan Kumis. Ini jauh lebih baik dan lebih dapat diprogram. Kami sekarang telah menghentikan penggunaan Moustache untuk ini dan itu akan dihapus dalam revisi berikutnya dari pipeline penerapan kami.

Setelah melihat dokumentasi penerapan Kubernetes, saya melihat bahwa ini adalah file YAML. Sebagian besar bahasa pemrograman memiliki pustaka yang dapat membaca dan menulis YAML, jadi saya sarankan Anda melakukan ini. Dari percobaan saya, saya belajar bahwa ketika Anda mencoba untuk memanipulasi format yang dapat dibaca mesin, Anda hampir selalu memiliki pilihan yang lebih baik daripada Kumis.

Harap dicatat: sementara saya tidak menggunakan Kumis untuk apa pun lagi, saya masih merasa bahwa ini adalah permintaan fitur yang valid.

Solusinya adalah dengan menggunakan handlebars , yang mendukung sintaks yang sama, dan juga memiliki opsi ketat yang persis seperti yang dibutuhkan dalam usecase ini.

@steverukuts Anda benar tentang format yang dapat dibaca mesin yang memanipulasi, jika Anda memiliki manipulasi yang telah ditentukan sebelumnya yang perlu Anda dukung, dan terutama jika Anda perlu memiliki beberapa kecerdasan yang terpasang di dalamnya. Untuk alat konfigurasi ujung terbuka, itu menjadi terlalu tidak fleksibel dengan sangat cepat, oleh karena itu perlu templating. Coba tulis alat yang mendukung penyisipan nilai arbitrer di tempat arbitrer dan... Anda akan segera memiliki mesin templating.

Di tempat kerja kami telah menggunakan kontemplate untuk mengonfigurasi sumber daya Kubernetes beberapa tahun terakhir. Ini pada dasarnya adalah mesin templating go, dengan beberapa fungsi praktis dari setangkai dan yang khusus dalam proyek itu. Ini telah dibuat sebagai pendekatan yang lebih ringan daripada helm misalnya.

Sehubungan dengan pembahasan di atas; itu juga akan meledak pada variabel yang tidak diketahui.

Solusinya adalah dengan menggunakan handlebars , yang mendukung sintaks yang sama, dan juga memiliki opsi ketat yang persis seperti yang dibutuhkan dalam usecase ini.

Masalah ini memaksa saya untuk menggunakan setang juga. Sayang sekali ini tidak didukung di kumis.