Tujuannya adalah untuk dengan mudah menangkap kesalahan ketik dan membantu penemuan semua kemungkinan peristiwa yang dikirim oleh suatu komponen. Lagi pula, tidak ada alasan mengapa input (alat peraga) dapat memiliki kontrak yang kuat tetapi output (peristiwa) tidak. Bahkan, ini bahkan lebih penting daripada untuk props, karena pengiriman dapat terjadi di mana saja dalam file, sedangkan props biasanya tersusun rapi di bagian atas.
Saat ini saya dapat mengetik on:qoidfoqidjoiqsjd
baik.
Flex, yang juga memiliki kompilernya menggunakan anotasi khusus untuk ini: https://github.com/Apache/flex-sdk/blob/master/frameworks/projects/mx/src/mx/core/Container.as#L97
Mungkin kita bisa mengadakan konvensi khusus yang dipesan seperti export type Events = {name: 'eventA', data: number} | ...
Membawa TSdoc di tooltip sisi konsumen akan menjadi lapisan gula pada kue.
Alasan mengapa ini tidak dapat diimplementasikan dengan mudah adalah karena jauh lebih sulit untuk mengumpulkan semua kemungkinan acara daripada mengumpulkan alat peraga. Itu juga alasan mengapa pelengkapan otomatis tidak berfungsi karena ini untuk alat peraga.
Melihat di bawah tenda, props diimplementasikan melalui props jsx. Acara bukan karena keterbatasan mengumpulkannya. Jika pengguna secara eksplisit mengetiknya, ini dapat diubah. Kami tidak dapat menandai acara yang dikirim sebagai "ini tidak sesuai dengan definisi" karena tantangan yang disebutkan.
Memiliki antarmuka yang dipesan kemungkinan merupakan jalan ke depan. Kami telah memikirkan hal ini sebelumnya dalam konteks alat peraga generik. Nama antarmuka yang dicadangkan dapat berupa ComponentEvents
, ComponentProps
, ComponentSlots
dan ComponentDef
untuk mengetik ketiganya.
Terkait #304
Mendapatkan pelengkapan otomatis dengan on:<event>
harus dilakukan secara berbeda karena kami menggunakan JSX untuk mendapatkan pelengkapan otomatis ini. Untuk mendapatkan pelengkapan otomatis "di luar kotak", kita perlu memiliki on:<event>
sebagai bagian dari props. Tapi ini tidak mungkin karena JSX tidak mengizinkan karakter seperti :
dalam props.
Masalah lain adalah bahwa kita entah bagaimana perlu mengonversi definisi tipe peristiwa untuk menambahkan on:
, yang tidak dapat dilakukan dengan TypeScript saat ini ( masalah TS terkait ).
Dua solusi muncul dari kendala ini:
__on__<eventName>: ..
dan kami akan di server bahasa kemudian mengganti __on__
dengan on:
selama pelengkapan otomatis. Ini terasa kurang optimal dan rapuh.Mendapatkan kesalahan " on:XXX
tidak ada" dengan mudah dimungkinkan setelah #386 digabungkan melalui variasi definisi metode $on
tidak jatuh kembali ke CustomEvent<any>
jika pengguna mengetikkan acara mereka secara eksplisit .
Setelah https://github.com/sveltejs/svelte/pull/5260 dirilis, kami dapat mencoba memperbarui svelte2tsx
sehingga ia mencari createEventDispatcher
, terlihat apakah ia memiliki anotasi jenis, dan jika ya, gunakan itu untuk mendapatkan tipe yang tepat.
Sekarang Anda dapat memanfaatkan pengetikan createEventDispatcher
diperkenalkan di Svelte 3.25.0. Jika kamu melakukan
const dispatch = createEventDispatcher<{foo: string; bar: boolean}>();
Anda mendapatkan pengetikan yang kuat untuk dispatch
di dalam komponen, dan jika Anda mendengarkan acara foo
/ bar
, Anda akan mendapatkan pengetikan yang kuat:
on:foo={e => ... // <- e is of type CustomEvent<string>
Anda juga akan mendapatkan pelengkapan otomatis yang jauh lebih baik untuk acara sekarang. Namun perhatikan bahwa Anda masih diperbolehkan untuk mendengarkan acara lain, jadi ketik keamanan dalam arti "hanya dengarkan acara yang ditentukan melalui createEventDispatcher
" masih hanya dimungkinkan melalui antarmuka ComponentEvents
. Tetapi kami berencana untuk menyediakan sesuatu (mungkin atribut tag skrip) yang akan membuat acara menjadi ketat.
Dokumen terkait: https://github.com/sveltejs/language-tools/blob/master/docs/preprocessors/typescript.md#typing -component-events
@dummdidumm
Adakah ide mengapa beberapa acara mendengarkan untuk createEventDispatcher
tidak menerima jenisnya?
Contoh:
// Component Foo
const dispatchFoo = createEventDispatcher<{foo: string; bar: boolean}>();
const dispatchBar = createEventDispatcher<{bar: string; baz: string}>();
// Component Bar
// e is CustomEvent<any>
on:foo="{(e) => handleFoo(e.detail.bar)}"
// e is CustomEvent<{baz: string}>
on:bar="{(e) => handleBar(e.detail.bar)}"
Kompiler TypeScript menangkap ini seperti yang diharapkan.
Mengubah urutan menghasilkan hasil yang berbeda.
jika perintah createEventDispatcher
berubah, maka compiler TypeScript tidak menangkap kesalahan.
Tampaknya hanya createEventDispatcher
menghasilkan tipe untuk pendengar.
// Component Foo
const dispatchBar = createEventDispatcher<{bar: string; baz: string}>();
const dispatchFoo = createEventDispatcher<{foo: string; bar: boolean}>();
// Component Bar
// e is CustomEvent<{bar: boolean}>
on:foo="{(e) => handleFoo(e.detail.bar)}"
// e is CustomEvent<any>
on:bar="{(e) => handleBar(e.detail.bar)}"
Kompiler TypeScript tidak menangkap kesalahan karena tipenya sekarang CustomEvent<any>
.
Komentar yang paling membantu
Sekarang Anda dapat memanfaatkan pengetikan
createEventDispatcher
diperkenalkan di Svelte 3.25.0. Jika kamu melakukanAnda mendapatkan pengetikan yang kuat untuk
dispatch
di dalam komponen, dan jika Anda mendengarkan acarafoo
/bar
, Anda akan mendapatkan pengetikan yang kuat:Anda juga akan mendapatkan pelengkapan otomatis yang jauh lebih baik untuk acara sekarang. Namun perhatikan bahwa Anda masih diperbolehkan untuk mendengarkan acara lain, jadi ketik keamanan dalam arti "hanya dengarkan acara yang ditentukan melalui
createEventDispatcher
" masih hanya dimungkinkan melalui antarmukaComponentEvents
. Tetapi kami berencana untuk menyediakan sesuatu (mungkin atribut tag skrip) yang akan membuat acara menjadi ketat.Dokumen terkait: https://github.com/sveltejs/language-tools/blob/master/docs/preprocessors/typescript.md#typing -component-events