Terima kasih banyak atas laporannya @mbrodala , codepen itu sangat dihargai!

@mbrodala Terima kasih untuk codepennya.
Aku ingin tahu apakah ada kesalahpahaman di sini.

643 dan #664 memperbaiki bug yang saya laporkan di #617 , yang diilustrasikan oleh tes ini, yang menyertai #643 :

  describe('when parsing a template with tags specified followed by the same template with different tags specified', function() {
     it('returns different tokens for the latter parse', function() {
       var template = "(foo)[bar]";
       var parsedWithParens = Mustache.parse(template, ['(', ')']);
       var parsedWithBrackets = Mustache.parse(template, ['[', ']']);
       assert.notDeepEqual(parsedWithBrackets, parsedWithParens);
     });
   });

Fungsi parse di-cache hanya menggunakan template sebagai kunci cache, sehingga saat parse digunakan untuk mengurai template itu, ia akan mengembalikan token yang sama persis, bahkan jika tags yang ditentukan berbeda.

tags adalah parameter opsional, dan ketika dihilangkan, ia kembali ke mustache.tags , yang secara default ['{{', '}}'] . Kembali mustache.tags digunakan sebagai bagian dari kunci cache.

Saya rasa saya tahu apa yang terjadi sehubungan dengan perbaikan bug dan ekspektasi, dan saya akan mencoba menelusurinya, dan saya akan menggunakan codepen sebagai contoh.

v2.3.0

Mustache.parse(template, ['[[', ']]']);

Di 2.3.0, ini menginstruksikan Kumis untuk mengurai template , menggunakan ['[[', ']]'] sebagai tag. Moustache melakukannya dan mengembalikan hasil yang benar, tetapi men-cache panggilan hanya menggunakan template . Lihat baris 447-450 dari [email protected] :

    if (tokens == null)
       tokens = cache[template] = parseTemplate(template, tags);

Panggilan berikutnya dalam codepen adalah:

var output = Mustache.render(
  template,
...

render tidak mengambil parameter tags , jadi tidak meneruskannya ke parse , jadi ketika render dipanggil, parse menggunakan mustache.tags sebagai tagnya. Jadi, ketika panggilan render itu dilakukan, itu secara efektif memberi tahu parse , "Silakan parsing template dan secara implisit gunakan ['{{', '}}'] sebagai tags ." parse sebenarnya melakukan hal yang salah dan melakukan pencarian cache sepenuhnya mengabaikan tags dan mustache.tags . Itu terjadi untuk mengembalikan hasil templat yang diurai dengan [['[', ']']] , tetapi hanya karena panggilan pertama ke parse di seluruh program untuk itu template dibuat dengan ['[[', ']']] sebagai tags .

v2.3.1

Mustache.parse(template, ['[[', ']]']);

Hasil parse di-cache menggunakan template dan tags , yaitu ['[[', ']]'] sebagai cacheKey.

Panggilan berikutnya:

var output = Mustache.render(
  template,
...

render memanggil parse , melewati template tetapi menghilangkan tags . parse oleh karena itu memiliki tags kembali ke mustache.tags , yang tetap menjadi default ['{{', '}}'] . parse melakukan pencarian cache terhadap kunci cache template dan ['{{', '}}'] , dan menimbulkan kesalahan cache, seperti yang diharapkan karena parse belum dipanggil dengan kombinasi template dan tag. Oleh karena itu mem-parsing template menggunakan ['{{', '}}'] .

Saya percaya v2.3.1 menunjukkan perilaku yang benar. Jika kita mengubah codepen di https://codepen.io/mbrodala/pen/QBJoOx sedikit dan menjalankannya melawan v2.3.0:

var template = "[[item.title]] [[item.value]]";
Mustache.parse(template, ['[[', ']]']);
var output = Mustache.render(
  template,
  {
    item: {
      title: "TEST",
      value: 1
    }
  }
);
alert(output);

Outputnya adalah [[item.title]] [[item.value]] , yang tidak diharapkan.

Saya dapat melihat bagaimana perilaku di https://codepen.io/mbrodala/pen/NBEJjX mungkin mengejutkan, karena panggilan Mustache.parse dan Mustache.render tepat bersebelahan dan yang satu mungkin tidak bahkan menyadari bahwa Mustache.parse bahkan membutuhkan argumen tags . (Mengapa Mustache.parse bahkan mengambil argumen tags ? Itu tidak pernah digunakan di mana pun di mustache.js -- parse hanya default secara internal ke mustache.tags . ..)

Jika perubahan perilaku benar-benar bertentangan dengan harapan rilis perbaikan bug, maka saya tidak yakin apa yang harus dilakukan. Salah satu kemungkinannya adalah merilis versi perbaikan bug lain dengan #664 dikembalikan, yang pada dasarnya menghapus semua perilaku caching (mengingat bahwa di #643, semua pencarian cache akan terlewatkan). Kami kemudian dapat menempatkan kembali #664 ke dalam revisi besar berikutnya. Kemungkinan lain adalah menghapus semua caching dalam rilis perbaikan bug (sebagai lawan dari merilis mustache.js dengan caching non-fungsional), dan kemudian mengembalikan semua caching di revisi besar berikutnya. Opsi pertama mungkin memiliki risiko lebih kecil (jumlah perubahan kode paling sedikit) tetapi opsi terakhir mungkin lebih "benar". @phillipj pikiran?

Terima kasih banyak atas penelitian terperinci yang sepenuhnya masuk akal dari POV saya.

Saya tidak keberatan tentang perubahan sama sekali tetapi mengingat bahwa tidak mungkin untuk meneruskan tags ke Mustache.render() untuk memastikan cache hit dan Mustache.parse() diiklankan ke cache template (tidak disebutkan tags di sini) Saya ingin tahu apakah ini benar-benar harus dikembalikan.

Jika kita berasumsi bahwa seseorang memanggil Mustache.parse dengan set khusus tags , kita juga dapat mengasumsikan bahwa template menggunakan pembatas ini (BTW, "tag" vs "pembatas" seharusnya dibersihkan juga). Setelah itu, kita dapat mengasumsikan bahwa panggilan ke Mustache.render diharapkan berfungsi, tidak peduli bagaimana dan jika template yang diberikan sudah di-cache dan bagaimana itu dikompilasi jika itu masalahnya. Saat ini ini tidak dijamin jika tags kustom digunakan.

@mbrodala Ya itu masuk akal, meskipun Mustache.parse(template, ['[[', ']]']); diikuti oleh Mustache.parse(template, ['((', '))']); memberikan hasil yang sama persis akan tetap tidak terduga.

Berikut ini adalah solusi/kompromi manusia jerami ("manusia jerami" karena saya tidak menyukainya tetapi perlu dilakukan brainstorming). Kita dapat memiliki parse cache terhadap template saja dan template dengan tag. Ketika parse dipanggil dengan tags ditentukan, maka ia melakukan pencarian terhadap template dan tags . Ketika kita memanggil render , yang memanggil parse tanpa tags , maka kita melakukan pencarian terhadap template saja. Pikiran?

Kedengarannya tidak aktif dan pada dasarnya adalah tetapi akan memperbaiki masalah ini sambil menjaga perbaikan tetap utuh. Oke dari POV saya.

@mbrodala adalah masalah inti yang tidak dapat Anda berikan tags ke render ? Kita juga bisa menambahkan parameter tags ke render .

@petrkoutnysw Apakah ini kira-kira masalah yang Anda alami juga?

Setidaknya ada inkonsistensi antara parse() dan render() . Kami bahkan tidak akan menggunakan parse() jika kami dapat meneruskan tag khusus ke render() . Dan sekarang dengan caching yang tepat, ini menjadi lebih jelas.

+1 untuk menambahkan parameter tag ke render() untuk menghilangkan banyak kebingungan -- kami juga mendapat sedikit perubahan ini dan tautan b/w parse dan render selalu tampak sedikit lebih ajaib daripada yang diperlukan.

Oke, jadi bagaimana kalau kita menonaktifkan caching dalam rilis perbaikan bug, untuk memperbaiki masalah langsung dan mematuhi versi semantik, dan memperkenalkannya kembali dan tags dalam metode render di rilis besar berikutnya? (Sekali lagi, saya bukan penggemar berat solusi straw-man yang saya usulkan.)

Terima kasih banyak untuk penelusuran menyeluruh itu @raymond-lam!

Saya condong ke rilis perbaikan bug yang disarankan, terutama karena kekhawatiran dan proyek semver di mana perubahan perilaku ini tidak terduga dan karenanya dapat menyebabkan malapetaka dalam proyek di alam liar.

Memperkenalkan kembali perilaku caching lagi dalam rilis besar berikutnya yang direncanakan, kami dapat menyertakan instruksi migrasi dalam catatan rilis.

@phillipj Saya telah mengeluarkan permintaan tarik #670 yang mengembalikan #643 dan #664. Daripada menonaktifkan caching bersama-sama, demi mitigasi risiko, cukup kembali ke perilaku v2.3.0 (dalam rilis perbaikan bug) tampaknya paling aman untuk tanggungan pada Moustache v2.xx Saya akan mengeluarkan permintaan tarik lain untuk diperkenalkan kembali dalam rilis utama.

@phillipj #671 memperkenalkan kembali perbaikan caching, untuk menunggu rilis utama.

Membuat masalah #672 untuk mengatasi penambahan tags ke `render.

Terima kasih banyak untuk melihat dan memperbaiki ini, kalian rock. 👍

Angkat topi untuk @raymond-lam untuk yang satu ini! Terima kasih juga kepada Anda, penting bagi kami untuk mengetahui kapan perubahan tak terduga terjadi di alam liar.

v2.3.2 telah diterbitkan