Vscode-ng-language-service: Tata bahasa textmate untuk ekspresi template

Saya tidak yakin bahwa kita memerlukan dua tata bahasa terpisah untuk tanda kutip tunggal dan ganda. Saya kira kasus di mana ini penting adalah jika seseorang menggunakan tanda kutip tunggal di dalam atribut itu sendiri yang dibatasi oleh tanda kutip tunggal (dan secara simetris untuk tanda kutip ganda), meskipun saya bertanya-tanya seberapa umum pola ini -- jika tidak terlalu umum atau tidak berdampak signifikan pada stabilitas tata bahasa, mungkin tidak sebanding dengan biaya pemeliharaan dua tata bahasa yang terputus-putus. Saya tidak menentang kompilasi tata bahasa dari definisi TypeScript jika cara untuk maju adalah dengan dua tata bahasa. Bagaimana menurut anda?

Jika kita mendefinisikan satu tata bahasa yang dapat disematkan yang mengenali string yang dikutip ganda dan tunggal, maka dalam banyak kasus apa yang _harus_ menjadi kutipan akhir untuk pengikatan atribut akan dikenali sebagai kutipan pembuka untuk string baru dalam ekspresi template. Titik kegagalan umum yang saya lihat dalam pengujian PoC saya adalah dengan ekspresi ternary:

<fa-icon [icon]="isLocked ? 'lock' : 'lock-open'"></fa-icon>

Kondisi akhir tata bahasa JS untuk ekspresi ternary terlihat seperti ini: (?=$|[;,})\]]) , jadi tanpa merangkum ternary dalam parens atau mengakhirinya dengan titik koma, tata bahasanya rusak.

Namun, kasus khusus ini sebenarnya _tidak_ gagal sekarang dengan tata bahasa JS lengkap, tetapi dengan subset pilihan ceri saya, jadi ini pasti efek samping dari mengecualikan beberapa pola lain yang menurut saya tidak relevan dengan templat ekspresi. Jadi mungkin saja merancang tata bahasa ekspresi templat dengan hati-hati dari awal alih-alih menyalin dan menempel sembarangan dari tata bahasa JS dapat menghindari masalah seperti ini -- tetapi itu jauh lebih banyak pekerjaan. :)

Ada juga opsi ketiga. Cara saya mendesain PoC saya adalah dengan mendefinisikan sintaks ekspresi sebagai bahasa terpisah untuk disematkan ke dalam tata bahasa templat, seperti tata bahasa JS yang sedang disematkan sekarang. Jika kita membangun pola ekspresi ini secara langsung ke dalam tata bahasa template, kita berpotensi menghindari seluruh masalah dengan hanya secara selektif menyertakan kumpulan pola tertentu di dalam nilai atribut tertentu. Ini juga akan lebih akurat dengan cara kerja Angular, karena interpolasi dan jenis ikatan yang berbeda mengizinkan jenis ekspresi yang berbeda.

Saya setuju dengan Anda, kita harus menjaga definisi yang terpisah. Saya pikir itu dikompilasi
definisi akan lebih disukai di sini.

Pada Rabu, 22 Januari 2020 pukul 21:45 Danny McGee [email protected]
menulis:

Saya tidak yakin bahwa kita memerlukan dua tata bahasa terpisah untuk tunggal dan ganda
kutipan. Saya kira kasus di mana ini penting adalah jika seseorang menggunakan lajang
tanda kutip di dalam atribut itu sendiri dibatasi oleh tanda kutip tunggal (dan
simetris untuk tanda kutip ganda), meskipun saya bertanya-tanya seberapa umum pola ini
adalah -- jika tidak terlalu umum atau tidak berdampak signifikan terhadap
stabilitas tata bahasa, mungkin tidak sebanding dengan biaya pemeliharaan dua
tata bahasa yang terputus-putus. Saya tidak menentang kompilasi tata bahasa dari TypeScript
definisi jika cara untuk bergerak maju adalah dengan dua tata bahasa. Apa yang kamu
memikirkan?

Jika kita mendefinisikan satu tata bahasa yang dapat disematkan yang mengenali ganda dan
string yang dikutip tunggal, maka dalam banyak kasus apa yang seharusnya menjadi kutipan akhir
untuk atribut yang mengikat malah akan dikenali sebagai kutipan pembuka
untuk string baru dalam ekspresi template. Titik kegagalan umum I
terlihat dalam pengujian PoC saya adalah dengan ekspresi ternary:

Kondisi akhir tata bahasa JS untuk ekspresi ternary terlihat seperti ini:
(?=$|[;,})]]), jadi tanpa merangkum ternary di parens atau berakhir
dengan titik koma, tata bahasanya rusak.

Namun, kasus khusus ini sebenarnya tidak gagal sekarang dengan
tata bahasa JS lengkap, tetapi dengan subset pilihan ceri saya, jadi ini pasti ada
menjadi efek samping dari mengecualikan beberapa pola lain yang menurut saya bukan
relevan dengan ekspresi template. Jadi mungkin saja dengan hati-hati
mendesain tata bahasa ekspresi template dari awal, bukan
menyalin dan menempel secara sembarangan dari tata bahasa JS dapat menghindari masalah
seperti ini -- tapi itu jauh lebih banyak pekerjaan. :)

Ada juga opsi ketiga. Cara saya mendesain PoC saya adalah dengan mendefinisikan
sintaks ekspresi sebagai bahasa terpisah untuk disematkan ke dalam
tata bahasa template, seperti tata bahasa JS yang sedang disematkan sekarang. Jika kita
alih-alih membangun pola ekspresi ini langsung ke tata bahasa template,
kita berpotensi menghindari seluruh masalah dengan hanya secara selektif memasukkan
set pola tertentu di dalam nilai atribut tertentu. Ini juga akan
lebih akurat dengan cara kerja Angular, karena interpolasi dan
jenis ikatan yang berbeda mengizinkan jenis ekspresi yang berbeda.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/angular/vscode-ng-language-service/issues/571?email_source=notifications&email_token=AE6GL6U5LJQCDMLHSGFUQ73Q7EVIZA5CNFSM4KKQUDJKYY3PNVWWK3TUL52HS4DFVREXG45WQ2JKZLON5WWQ2JKTLNOR5WSQ2JKTLN5WS
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AE6GL6XJSTNHDNSBMZ3FBKTQ7EVIZANCNFSM4KKQUDJA
.

@ayazhafiz "Kami menyematkan subset tata bahasa JavaScript kami sendiri alih-alih tata bahasa JS lengkap, terbatas hanya pada sintaks yang benar-benar valid di templat Angular"

Saya telah melakukan ini dengan tata bahasa saya, dan saya dapat mengonfirmasi bahwa itu mengurangi banyak tata bahasa JS itu sendiri. Lihat angular-expressions.json5

@dannymcgee Ada sesuatu dalam pola ekspresi dalam tata bahasa JS itu sendiri, yang menyebabkannya putus dengan titik koma yang hilang.

Saya telah memulung tata bahasa JS yang dikurangi di masa lalu dan menambahkan perbaikan yang hilang agar sesuai dengan kebutuhan ekspresi sudut.

Kami memiliki dua versi tata bahasa itu, satu yang mengenali tanda kutip tunggal sebagai kondisi akhir, dan satu lagi yang mengenali tanda kutip ganda

Saya bertanya-tanya seberapa umum pola ini [...]

Spesifikasi mengatakan kutip ganda (atribut = "nilai"), kutip tunggal (atribut = 'nilai'), tidak dikutip - jika tidak ada karakter spasi dalam nilai atribut (atribut = nilai) dan kosong (atribut) semuanya valid.

Tapi menurut saya pribadi itu terlihat jelek dan sulit dibaca.

Apakah ada cara saya bisa membantu kalian?

Apakah ada cara saya bisa membantu kalian?

@ghaschel Jika Anda ingin mengoordinasikan dan membantu membuka PR untuk mendapatkan tata bahasa ekspresi, itu akan luar biasa. Mungkin kita bisa membagi tugas di antara kita bertiga? Dan karena Anda telah melakukan pekerjaan mengekstrak pola yang relevan dari tata bahasa JS, jika kami dapat merujuk kembali ke repo Anda, itu akan membuat segalanya berjalan lebih cepat dan lancar.

Apakah salah satu dari Anda tahu apakah mungkin (atau yang lebih penting, masuk akal) untuk membuat tata bahasa yang tidak lepas dari pola awal/akhir yang termasuk di dalamnya?

Bantuan apa pun akan diterima dan sangat dihargai. Saya pikir kita bisa melanjutkan dan mulai dengan penambahan tambahan ke tata bahasa JSON untuk ekspresi template, atau refactor definisi TypeScript, atau keduanya.

Apakah salah satu dari Anda tahu apakah mungkin (atau yang lebih penting, masuk akal) untuk membuat tata bahasa yang tidak lepas dari pola awal/akhir yang termasuk di dalamnya?

Maaf, saya tidak yakin apakah saya mengerti apa yang Anda maksud? Saya hanya pernah membuat tata bahasa pengganti langsung, tidak pernah mencoba hal injectionSelector yang kami lakukan di sini, jika itu yang Anda maksud.

Apakah salah satu dari Anda tahu apakah mungkin (atau yang lebih penting, masuk akal) untuk membuat tata bahasa yang tidak lepas dari pola awal/akhir yang termasuk di dalamnya?

Saya tidak yakin saya mengerti apa yang Anda maksud. Ada dua cara untuk mencocokkan pola. Pencocokan persis, dan kecocokan awal/akhir dengan pencocokan ruang lingkup tertentu di dalamnya. Apakah ini terkait dengan apa yang Anda pikirkan?

Apakah ada cara saya bisa membantu kalian?

@ghaschel Jika Anda ingin mengoordinasikan dan membantu membuka PR untuk mendapatkan tata bahasa ekspresi, itu akan luar biasa. Mungkin kita bisa membagi tugas di antara kita bertiga? Dan karena Anda telah melakukan pekerjaan mengekstrak pola yang relevan dari tata bahasa JS, jika kami dapat merujuk kembali ke repo Anda, itu akan membuat segalanya berjalan lebih cepat dan lancar.

Aku kecewa dengan itu. Saya hanya tidak yakin ke repositori apa yang harus dikomit dan teknologi apa yang akan kita gunakan... Apakah ada keuntungan nyata dalam menggunakan TypeScript daripada yaml/json5?

Saya pernah mengalami masalah yang dijelaskan dalam tata bahasa saya di https://github.com/angular/vscode-ng-language-service/issues/575
Saya pikir tata bahasa JS yang dikurangi/diadaptasi yang saya peroleh akan menyelesaikan masalah ini

Yang saya maksud adalah tata bahasa yang tidak pernah cocok di luar pola yang disertakan. Banyak masalah yang kami lihat adalah karena sintaks JS keluar dari cakupan yang disertakan, mencoba mencocokkan pola melewati asumsi- mengakhiri kecocokan induknya, karena tata bahasa mencoba menyelesaikan pencocokan JS terlebih dahulu sebelum menutup induknya. Bagaimanapun, ini adalah pemahaman saya -- mohon koreksi saya jika saya salah.

Saya hanya tidak yakin ke repositori apa yang harus saya komit

Semua definisi untuk sintaks dan pengujiannya harus tersedia di folder syntaxes/ di root repositori ini. Beri tahu saya jika Anda memiliki pertanyaan. Saya pikir tindakan terbaik adalah memulai dengan hanya menambahkan definisi JSON untuk tata bahasa ekspresi templat dengan cara yang sama seperti yang sudah dilakukan (file baru). Saya akan mulai pada akhir pekan ini; maafkan saya, saya sangat sibuk minggu ini.

dan teknologi apa yang akan kita gunakan... Apakah ada keuntungan nyata dalam menggunakan TypeScript daripada yaml/json5?

Menurut saya, kelebihan definisi TS berkaitan dengan komentar Danny yang disebutkan di pembukaan edisi ini; kita akhirnya harus mendukung tata bahasa terpisah untuk atribut yang dibatasi oleh tanda kutip tunggal dan ganda. Akan lebih mudah untuk menggunakan repositori umum sebanyak mungkin, yang untuk itu kita memerlukan beberapa jenis bahasa skrip. Saya tidak akrab dengan JSON5; apakah itu memberikan sesuatu yang serupa? Bagaimanapun, ini bukan pemblokir. Saya pikir tujuannya pertama-tama adalah untuk memberikan stabilitas tata bahasa (memperbaiki masalah yang menggantung rendah untuk apa yang dilaporkan setiap hari), dan kita dapat menambahkan teknologi tata bahasa ganda/switch secara bersamaan.

@ayazhafiz Yang saya maksud adalah tata bahasa yang tidak pernah cocok di luar pola yang disertakan. Banyak masalah yang kami lihat adalah karena sintaks JS keluar dari cakupan yang disertakan, mencoba mencocokkan pola melewati kecocokan akhir yang diasumsikan dari induknya, karena tata bahasa mencoba menyelesaikan pencocokan JS terlebih dahulu sebelum menutup induknya. Bagaimanapun, ini adalah pemahaman saya -- mohon koreksi saya jika saya salah.

Ah, oke. Ya, baik atau buruk ini adalah perilaku default untuk tata bahasa TextMate yang disematkan. Pada dasarnya tanggung jawab tata bahasa induk untuk menentukan kondisi akhir untuk pola yang disematkan. Masalahnya seperti yang saya pahami adalah bahwa jika tata bahasa yang disematkan masuk ke status multi-barisnya sendiri (yaitu yang dibatasi oleh pola "mulai"/"akhir" alih-alih kecocokan pola sederhana), pengurai tata bahasa tidak akan mencari induk kondisi akhir tata bahasa sampai setelah ditemukan kondisi akhir status tata bahasa yang disematkan saat ini.

Dari apa yang saya tahu, alasan utama mengapa ini menjadi masalah dengan templat Angular adalah karena ada ekspresi templat Angular yang valid yang tidak diuraikan dengan benar oleh tata bahasa JS (mis., pipa dikenali sebagai operator bitwise dan as local-val sintaks diuraikan sebagai typecast). Masalah itu tidak perlu diperbaiki dengan memaksa tata bahasa yang disematkan untuk juga memeriksa kondisi akhir status induk — masalah itu juga bisa diperbaiki dengan hanya memastikan bahwa tata bahasa yang disematkan adalah pencocokan pola yang benar sesuai dengan aturan ekspresi templat Angular sintaks alih-alih JavaScript. Sepertinya itulah yang dilakukan @ghaschel dengan tata bahasanya.

Pendekatan itu tidak akan memperbaiki masalah beberapa sintaks _invalid_ yang melanggar penyorotan sintaks (seperti membuka kurung kurawal dalam ekspresi dan tidak pernah menutupnya lagi), tetapi saya tidak tahu seberapa khawatir kita benar-benar perlu tentang itu.

@ghaschel Apakah ada keuntungan nyata dalam menggunakan TypeScript daripada yaml/json5?

Keuntungan terbesar IMO adalah tidak harus menggandakan karakter dalam pola regex dan mendapatkan penyorotan sintaks untuk ekspresi itu sendiri (cakupan tata bahasa TypeScript untuk ekspresi reguler cukup bagus, jadi saya telah mengonfigurasi tema saya untuk memanfaatkannya). Tapi ini adalah langkah build ekstra dan ketergantungan dev tambahan dan itu tidak terlalu penting bagi saya, jadi saya akan dengan senang hati melanjutkan dengan JSON biasa selama file tetap kecil.

@dannymcgee itu juga bisa diperbaiki dengan hanya memastikan bahwa tata bahasa yang disematkan adalah pencocokan pola yang benar sesuai dengan aturan sintaks ekspresi templat Angular alih-alih JavaScript. Sepertinya itulah yang dilakukan @ghaschel dengan tata bahasanya.

Itulah tepatnya yang telah saya lakukan dengan tata bahasa saya. Itu dan menambahkan beberapa kecocokan ekstra seperti dukungan rantai opsional.

@ayazhafiz Saya pikir keuntungan dari definisi TS berkaitan dengan komentar Danny yang disebutkan dalam pembukaan masalah ini; kita akhirnya harus mendukung tata bahasa terpisah untuk atribut yang dibatasi oleh tanda kutip tunggal dan ganda. Akan lebih mudah untuk menggunakan repositori umum sebanyak mungkin, yang untuk itu kita memerlukan beberapa jenis bahasa skrip. Saya tidak akrab dengan JSON5; apakah itu memberikan sesuatu yang serupa? Bagaimanapun, ini bukan pemblokir. Saya pikir tujuannya pertama-tama adalah untuk memberikan stabilitas tata bahasa (memperbaiki masalah yang menggantung rendah untuk apa yang dilaporkan setiap hari), dan kita dapat menambahkan teknologi tata bahasa ganda/switch secara bersamaan.

JSON5 tidak menyediakan skrip seperti itu, ini pada dasarnya adalah JSON yang lebih permisif. Satu-satunya keuntungan dibandingkan JSON biasa adalah memiliki banyak repositori yang dibagi berdasarkan folder/subfolder dan file yang akan digabungkan menjadi satu json per folder utama. Sejauh yang saya pahami, kami akan membuat beberapa file tata bahasa JSON dan memasukkannya ke dalam bahasa utama. Saya pikir sesuatu yang lebih dinamis seperti TypeScript akan menjadi yang ideal, kalau begitu.

Keuntungan terbesar IMO adalah tidak harus menggandakan karakter dalam pola regex dan mendapatkan penyorotan sintaks untuk ekspresi itu sendiri (cakupan tata bahasa TypeScript untuk ekspresi reguler cukup bagus, jadi saya telah mengonfigurasi tema saya untuk memanfaatkannya). Tapi ini adalah langkah build ekstra dan ketergantungan dev tambahan dan itu tidak terlalu penting bagi saya, jadi saya akan dengan senang hati melanjutkan dengan JSON biasa selama file tetap kecil.

Saya tidak percaya JSON murni akan menjadi pilihan yang baik bagi kami karena tata bahasa ekspresi itu sendiri sudah luas, Tidak ada masalah bekerja dengan TypeScript untuk saya dan saya baik-baik saja dengan langkah build tambahan.
Apakah sesuatu seperti contoh yang Anda tambahkan di PoC Anda akan kami gunakan?

Saya tidak percaya JSON murni akan menjadi pilihan yang baik bagi kami karena tata bahasa ekspresi itu sendiri sudah luas, Tidak ada masalah bekerja dengan TypeScript untuk saya dan saya baik-baik saja dengan langkah build tambahan.
Apakah sesuatu seperti contoh yang Anda tambahkan di PoC Anda akan kami gunakan?

Ya, itu akan menjadi rencananya. Saya harus dapat melanjutkan dan membuka PR malam ini untuk memperbaiki tata bahasa yang ada untuk menggunakan sistem itu, dan dari sana kita dapat mulai menambahkan tata bahasa ekspresi templat kustom.

Apakah Anda berdua keberatan jika saya menggunakan tata bahasa Anda yang ada untuk memulai tata bahasa ekspresi template?

Apakah Anda berdua keberatan jika saya menggunakan tata bahasa Anda yang ada untuk memulai tata bahasa ekspresi template?

Saya tidak keberatan, tetapi Anda pasti ingin menggunakan versi @ghaschel karena versi saya salah :)

Saya dapat membuat PR dengan tata bahasa saya segera setelah #581 digabungkan. =]

Saya mulai mengerjakan porting tata bahasa saya ke format @dannymcgee yang diperkenalkan di #581.

Oke keren. Saya memutuskan untuk menunda sejak komentar Anda. Bersemangat untuk melihatnya; beri tahu saya jika kami dapat membantu.

: Guilherme Haschel [email protected]
авлено: еда, аря 29, 2020 5:29 AM
ому: angular/vscode-ng-language-service
опия: hafiz; Menyebutkan
Contoh: Re: [angular/vscode-ng-language-service] Tata bahasa teks untuk ekspresi templat (#571)

Saya mulai mengerjakan porting tata bahasa saya ke format @dannymcgee https://github.com/dannymcgee yang diperkenalkan di #581 https://github.com/angular/vscode-ng-language-service/pull/581 .

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, melihatnya di GitHub https://github.com/angular/vscode-ng-language-service/issues/571?email_source=notifications&email_token=AE6GL6W2NQHGIAM35CO2CODRAGAC5A5CNFSM4KKQUDJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKHFXSY#issuecomment-579754955 , atau berhenti berlangganan https: // github. com/notifications/unsubscribe-auth/AE6GL6SLH3QEY3NHNVUUPXLRAGAC5ANCNFSM4KKQUDJA .

Ini akan baik-baik saja ... Ada beberapa regex yang harus saya tulis ulang karena tampaknya kompiler tsc tidak melihatnya sebagai valid.

Saya pikir kita dapat mengharapkan ekspresi berfungsi penuh paling banyak pada hari Jumat.

Senang mendengarnya! Jangan ragu untuk mengirimkan PR tambahan saat Anda pergi, jika Anda mau.

@ghaschel Ini akan baik-baik saja ... Ada beberapa regex yang harus saya tulis ulang karena tampaknya kompiler tsc tidak melihatnya sebagai valid.

Oof, itu menyakitkan, maaf tentang itu! Dalam kasus tersebut, mungkin lebih mudah untuk menyimpan pola dalam format string daripada memfaktorkannya kembali ke regex literal, kecuali jika ada cara kita dapat memperbarui fungsi build untuk menanganinya. Apa masalah spesifik yang Anda lihat?

@ghaschel apa

@ayazhafiz Maafkan aku menghilang seperti ini. Memiliki sisa minggu yang sangat berat di tempat kerja, akhir dari sebuah proyek, harus bekerja di akhir pekan.

Ini berjalan dengan baik. Saya akan menyelesaikan ini pada akhir hari.

Tidak ada kekhawatiran sama sekali, saya benar-benar mengerti. Tidak usah buru-buru! Hanya memeriksa. Saya melihat PR Anda sekarang juga.

Baru saja menambahkan komit lain untuk memperbaiki tes snapshot. Saya harus membuat ulang template dan file snapshot template sebaris.
Beri tahu saya jika ada yang salah dengan permintaan tarik saya.

Akan melakukan. Saya akan melihat nanti hari ini. Saya juga sangat sibuk di tempat kerja))

Masalah ini telah dikunci secara otomatis karena tidak ada aktivitas.
Silakan ajukan masalah baru jika Anda mengalami masalah serupa atau terkait.

Baca lebih lanjut tentang kebijakan penguncian percakapan otomatis kami.

_{_Tindakan ini telah dilakukan secara otomatis oleh bot._}