Aspnetcore: Ganti nama Komponen Razor kembali ke Blazor sisi server

Dibuat pada 29 Mar 2019  ·  50Komentar  ·  Sumber: dotnet/aspnetcore

Kami awalnya memperkenalkan model hosting sisi server Blazor di Blazor 0.5.0 dan kemudian memutuskan untuk mengirimkannya dalam .NET Core 3.0. Untuk membedakan Blazor sisi klien dan sisi server, kami memutuskan untuk memberi model sisi server nama baru: Komponen Razor. Namun hal ini ternyata menimbulkan kebingungan.

Untuk mengatasi kebingungan ini kita akan kembali mengacu pada model aplikasi sebagai Blazor dengan model hosting yang berbeda. Aplikasi Blazor dapat dihosting di server di .NET Core atau di klien dengan WebAssembly. Dukungan Blazor sisi server akan dikirimkan dengan .NET Core 3.0 dan dukungan sisi klien akan datang kemudian segera setelah dukungan WebAssembly siap.

Detail implementasi:

  • Ganti nama template Razor Components di .NET Core 3.0 kembali ke “Blazor (server-side)”.
  • Ganti nama template Blazor menjadi "Blazor (sisi klien)" untuk kejelasan penuh.
  • Ganti nama services.AddRazorComponents() -> services.AddServerSideBlazor()
  • Ganti nama routes.MapComponentHub<TComponent>() -> routes.MapBlazorHub<TComponent>()
  • Ganti nama komponen.server.js kembali ke blazor.server.js dan komponen.webassembly.js kembali ke blazor.webassembly.js
  • Sejajarkan versi paket Blazor untuk menyelaraskan dengan versi .NET Core 3.0 (#8859)
  • Perbarui ikon templat "Blazor (sisi server)" agar sesuai dengan templat Blazor lainnya
Done area-blazor enhancement

Komentar yang paling membantu

Saya pikir ini adalah langkah yang bagus. Tidak ada akhir dari kebingungan tentang hubungan antara Razor Components dan Blazor. Sampai-sampai orang mengira mereka adalah kerangka kerja yang berbeda, bukan hanya cara rendering yang berbeda.

Plus, menurut saya pribadi, Blazor adalah nama yang keren.

Semua 50 komentar

Apakah ini keputusan yang disetujui? Bisakah kita tetap memilih?

Secara pribadi saya menentang mengubah nama. Saya pikir Razor Components adalah nama yang lebih baik. :(

@xclud Ini adalah forum terbuka, jadi umpan balik selalu diterima

Kami masih akan mengacu pada model komponen sebagai komponen Razor (yaitu file .razor akan tetap menjadi komponen Razor), tetapi ketika berbicara tentang model aplikasi, kami merasa sangat rumit untuk memiliki nama yang berbeda. Sudah ada sedikit momentum di balik nama Blazor jadi kami ingin tetap menggunakannya. Nama tentu saja subjektif - tidak peduli nama apa yang kami pilih, tidak semua orang akan senang, tetapi Blazor tampaknya telah melayani kami dengan cukup baik sejauh ini.

Saya pikir ini adalah langkah yang bagus. Tidak ada akhir dari kebingungan tentang hubungan antara Razor Components dan Blazor. Sampai-sampai orang mengira mereka adalah kerangka kerja yang berbeda, bukan hanya cara rendering yang berbeda.

Plus, menurut saya pribadi, Blazor adalah nama yang keren.

Sebagai seseorang yang sangat sering berbicara kepada orang-orang tentang Blazor. Komponen Razor hanyalah kebingungan. Ini membingungkan dalam hal: kapan aplikasi Blazor merupakan aplikasi Komponen Pisau Cukur, Komponen Pisau Cukur yang terkait dengan [Halaman Pisau Cukur & Perpustakaan Kelas Pisau Cukur], dan tersandung diri sendiri saat mengatakan Pisau Cukur/Blazor. Itu juga membuat menulis tentang Blazor sulit, SEO sulit, saya bisa melanjutkan.

Kewarasan menang! Terima kasih banyak atas perubahan ini.

Apa yang terjadi dengan ekstensi file .razor, karena halaman pisau cukur masih .cshtml dan komponennya .razor, mungkin lebih baik menyebutnya .blazor? Atau sebut juga halaman pisau cukur .razor bukan .cshtml?
Hal-hal yang cukup membingungkan

Kami berencana untuk mempertahankan ekstensi .razor untuk komponen. Komponen didasarkan pada sintaks Razor, tetapi komponen ditangani secara berbeda oleh compiler Razor, sehingga mereka memerlukan ekstensi file yang berbeda.

Bagaimana dengan template yang dihosting blazer? Untuk model sisi klien, ini adalah cara termudah untuk:

  • menerapkan header keamanan CSP
  • menghitung hash SRI (idealnya ini juga diperlukan untuk aset yang diunduh langsung oleh blazor.webassembly.js)
  • mengompresi aset (setidaknya sampai file dll akan dikirimkan dengan tipe konten wasm yang sudah dikompresi oleh beberapa CDN yang saya coba)

Jadi saya berharap template yang dihosting akan tetap ada.

Saya juga suka mengganti nama ini kembali menjadi "Blazor". ATM berbicara dengan orang-orang tentang komponen Blazor dan Razor hanyalah kebingungan.

Blazor adalah teknologi dengan (setidaknya) dua model hosting. Jadi, saya suka Blazor!

Satu nama untuk memerintah mereka semua. Satu Blazor dengan dua model hosting yang berbeda pasti lebih baik. Ini menyelamatkan dari banyak kebingungan di jalan.

Saya menyambut perubahan ini! Penamaan baru (atau lama) jauh lebih membingungkan yang saya rasakan.

Saya setuju dengan @vertonghenb bahwa ekstensi file juga harus diganti namanya menjadi .blazor . Itu jauh lebih masuk akal. Baik .cshtml dan .razor memiliki sintaks silet, tetapi hanya satu yang harus memiliki kode khusus Blazor yang akan membuat ekstensi file .blazor lebih tepat dan IMHO tidak terlalu ambigu.

Komentar singkat: Saya setuju dengan mengubah nama kembali dari _Razor Components_ menjadi _Server-side Blazor_.

Jawaban panjang: Saya percaya bahwa "komponen" sisi klien dan sisi server harus memiliki nama yang sama, apa pun itu: Blazor, Razor Components, ASP.NET Core Components. Misalnya React dan React Native adalah teknologi yang jauh lebih berbeda namun mereka memiliki nama yang sama.

Keuntungan dari nama Blazor:

  • Namanya sudah mapan di masyarakat. Sebenarnya itu juga dipahami sebagai teknologi untuk menjalankan .NET di browser, itu tidak 100% benar.
  • Mungkin lebih mudah bagi orang untuk menerima/memahami bahwa Blazor dapat digunakan tanpa .NET di sisi server (sebenarnya tanpa sisi server).

Keuntungan dari nama Komponen Razor:

  • Menautkan dengan Razor dan ASP.NET Core dapat membantu orang memahami bahwa teknologi akan memiliki dukungan dan stabilitas yang tepat. Meskipun Blazor telah mendapat banyak perhatian, saya pikir itu dipahami sebagai teknologi yang stabil.

Dan mengenai ekstensi itu tergantung bagaimana kompilasi Razor dapat diperluas. Jika misalnya di masa depan akan ada halaman Razore yang dihasilkan secara statis juga dengan ekstensi .razor dan kompiler dapat menanganinya, maka saya akan menyimpan ekstensi .razor . Pada dasarnya seperti ekstensi .xaml digunakan untuk kontrol, halaman, sumber daya, objek aplikasi.

Saya pikir ini harus dapat dicapai dengan sempurna. Saya tidak tahu apa status saat ini untuk mendukung kode di belakang untuk komponen Razor. Namun, jika ada maka di belakang kode mendefinisikan apakah komponen diwarisi dari ComponentBase atau yang lainnya. Dan ini dapat menentukan bagaimana file .razor harus dikompilasi. Dan tanpa kode di belakang, warisan default adalah ComponentBase dan di masa depan mungkin ada kemungkinan untuk mengubah kelas dasar default.

Namun, jika objek Razor di masa mendatang perlu memiliki ekstensi yang berbeda, maka .blazor untuk komponen Blazor akan menjadi pilihan yang jauh lebih baik.

Saya sangat menyambut perubahan ini! Nama "Komponen Razor" selalu sedikit membingungkan karena ekspektasinya adalah bahwa ini murni sisi server, seperti yang dilakukan Razor. Jadi harapannya adalah bahwa komponen Razor adalah, seperti kontrol pengguna di WPF, cara untuk membuat komponen khusus menggunakan sintaks Razor alih-alih kode (seperti yang diizinkan oleh tag helper).

Dengan mengganti nama ini, kebingungan itu akan dihapus, dan kami benar-benar memiliki kesempatan untuk akhirnya datang dengan komponen Razor yang dapat dikomposisi sisi server di beberapa titik.

Adapun ekstensi .razor , seperti yang lain, saya yakin akan lebih masuk akal untuk menggunakan .blazor sebagai gantinya. Cara saya memahaminya, file-file itu dapat berisi kode yang hanya layak dalam konteks Blazor, karena logikanya digabungkan secara mendalam ke komponen. Saya tidak berasumsi bahwa ini akan mungkin untuk digunakan kembali dalam konteks non-Blazor. Juga, jika komponen Blazor sisi klien akan berakhir menggunakan hal yang sama, saya pikir menggunakan .blazor secara konsisten adalah ide yang lebih baik untuk mengidentifikasi komponen Blazor (yang kemudian dapat digunakan baik sisi server atau sisi klien) .

Saya tahu @poke dan @duracellko sama-sama menyebut istilah komponen blazer secara sepintas, tapi sebenarnya saya suka itu sebagai nama. Bagaimana dengan __Blazor Components__ bukannya __Blazor (server-side)__?

Oh. dan saya pikir .blazor untuk nama ekstensi juga merupakan ide yang bagus.

@myty Saya pikir secara konseptual, komponen selalu "komponen Blazor" (yaitu Anda membuat komponen dengan Blazor). “Blazor (sisi server)” dan “Blazor (sisi klien)” adalah dua model hosting yang berbeda di mana Anda dapat menggunakan dan menjalankan komponen Blazor yang sama (saya pikir?). Jadi, Anda akan menggunakan "komponen Blazor" untuk menjelaskan bahwa Anda sedang membuat komponen, dan "Blazor sisi server" untuk menjelaskan bagaimana Anda menjalankan komponen Blazor.

@myty Saya pikir secara konseptual, komponen selalu "komponen Blazor" (yaitu Anda membuat komponen dengan Blazor). “Blazor (sisi server)” dan “Blazor (sisi klien)” adalah dua model hosting yang berbeda di mana Anda dapat menggunakan dan menjalankan komponen Blazor yang sama (saya pikir?). Jadi, Anda akan menggunakan "komponen Blazor" untuk menjelaskan bahwa Anda sedang membuat komponen, dan "Blazor sisi server" untuk menjelaskan bagaimana Anda menjalankan komponen Blazor.

Fakta bahwa selalu komponen Blazor itulah yang menjual saya atas nama itu. Katakan seperti itu dan kedengarannya keren juga. :)

...tapi, saya juga melihat kebingungan antara sisi server dan sisi klien. Sulit untuk menceritakan kisahnya tanpa secara khusus memanggil mereka.

Ya! Akhirnya :) Blazor adalah nama sebenarnya.

apakah kamu bahkan berkobar?

Ya

Bagi saya Blazor = WASM.

Jadi 'Razor Components' (SignarR!) adalah sesuatu yang sama sekali berbeda. Menjelaskan perbedaannya cukup mudah: WASM Blazor.

MENURUT OPINI SAYA.

Ini pasti keputusan yang tepat. Bahkan setelah istilah "Komponen Razor" baru diperkenalkan, saya dan rekan saya masih menyebutnya sebagai Blazor sisi Server. Saya juga lebih suka ekstensi .blazor atau sesuatu seperti .component. Tampilan di MVC juga menggunakan sintaks silet, jadi .razor membawa kebingungan tambahan.

Saya pikir u-turn untuk mengganti nama Razor Components kembali ke Blazor adalah hal yang bagus.

Saya pikir ekstensi komponen tidak boleh .razor karena membingungkan untuk memiliki 2 ekstensi berbeda yang mewakili file silet. ( .cshtml dan .razor )

Saya pikir ekstensi .blazor atau .component akan menjadi alternatif yang lebih baik daripada .razor .

Terima kasih telah membuat nama ini berubah kembali menjadi Blazor Server-Side . Saya lega untuk jujur. Aku punya lolwut kecil? saat pertama kali saya mendengar nama berubah menjadi Razor Components .

Secara pribadi, saya pikir kata Razor sudah cukup berlebihan:

  • Pisau cukur
  • Tampilan Pisau Cukur
  • Halaman Pisau Cukur
  • Pengontrol Halaman Pisau Cukur
  • Model Halaman Pisau Cukur
  • Perpustakaan Kelas Pisau Cukur
  • Tampilan Sebagian Razor
  • Komponen Tampilan Pisau Cukur
  • :baru: Komponen Pisau Cukur :bingung: //confusing much yet?
  • Fitur keluarga Razor berikutnya : // just kidding :)

Kami telah mempersulit seseorang yang baru mencoba menavigasi semua hal Razor ini bersama dengan mencoba memahami setiap kasus penggunaan.

Tidak hanya merasakan empati untuk pemula, tetapi bayangkan mencoba menjelaskan dan mempertahankan penggunaan terminologi yang "benar" di atas tim besar saat menjelaskan dan mengoordinasikan (bagaimana/kapan/apa) yang akan digunakan.

Blazor adalah nama yang bagus karena kami telah mengaitkannya dengan kasus penggunaannya. Yo, bahkan Razor Sockets akan menjadi nama yang lebih baik daripada Razor Components . :kacamata hitam:

Juga, saya pikir mengganti nama .razor menjadi .blazor adalah ide yang bagus.

Memberi nama itu sulit.
Jaga hal-hal sederhana.

-Brian :)

Memiliki ketertarikan pada Razor Components karena memainkan dengan baik dalam proyek saya membawa saya ke sini.
Saya mengerti apa yang kita bicarakan, tetapi seseorang yang baru memulai mungkin bingung dengan apa yang ada di balik tenda, karena penamaannya.
Jika tujuannya adalah untuk mengirimkan Razor Components hanya sebagai pengganti sementara untuk Blazor yang akan datang, saya tidak ingin namanya diubah.

@Mitiko Server-side Blazor tidak akan terpengaruh oleh keputusan seputar Blazor sisi klien (berdasarkan WebAssembly). Dengan asumsi yang terakhir akan dirilis di beberapa titik, Anda masih dapat menggunakan Blazor sisi server. Kedua model aplikasi sebenarnya akan dapat berbagi hal-hal tertentu sehingga lebih masuk akal untuk menyelaraskannya dengan nama mereka juga.

Inilah mengapa akhirnya membingungkan. Ketika Anda memiliki logika yang tidak peduli di mana itu di-host, apa namanya? Kemudian kerangka kerja secara ajaib mengubah nama berdasarkan "cangkang" yang Anda gunakan. Tidak masuk akal untuk memiliki dua nama. Untuk poin @poke lihat video di bawah ini: @Mitiko

https://www.youtube.com/watch?v=dNQ7MgPZby4

Bagaimana dengan template yang dihosting blazer?

@ghidello Tetap apa adanya. Jadi akan ada tiga templat Blazor: sisi klien yang berdiri sendiri, ASP.NET Core yang dihosting, dan sisi server

Saya senang melihat ini, Seperti yang Anda katakan - Nama memiliki arti dan momentum di baliknya dan bagi saya itu menyampaikan bahwa kedua model maju dengan dukungan yang kuat.

IMO Anda juga harus memberi nama nama model komponen untuk merujuk ke Blazor, bahkan jika Anda menggunakan sintaks/mesin Razor. Itu hanya akan menjadikannya solusi satu atap yang lebih kohesif, dari segi penamaan.

Bagaimana dengan ruang nama Komponen? Itu harus diganti namanya juga.

Dan file .razor harus .blazor karena terkait dengan teknologi Blazor. Kalau tidak, mereka harus digunakan untuk Razor Mvc umum juga.

Masih sedikit bingung dengan komponen:

Jadi, jika saya membuat pustaka komponen, yang berfungsi baik dengan sisi server dan sisi klien Blazor, apakah saya menyebut komponen sebagai "Komponen Blazor" atau "Komponen Razor"?

@egil Berdasarkan apa yang dikatakan Dan Roth di atas, sebuah komponen akan tetap dikenal sebagai Komponen Razor.

Kami masih akan mengacu pada model komponen sebagai komponen Razor (yaitu file .razor akan tetap menjadi komponen Razor)

Menambahkan suara persetujuan saya untuk perubahan ini.

Seperti yang saya lihat, RazorComponent adalah komponen C# yang ditulis menggunakan sintaks Razor dan kode C#. Kita dapat menggunakan RazorComponents dalam berbagai proyek, termasuk Blectron (seperti dalam demo StorageExplorer), generator HTML (misalnya untuk pembuatan badan email dengan cara yang sama seperti yang dilakukan RazorGenerator untuk .cshtml konten. Mereka tidak terbatas hanya pada Blazor .

Sebaliknya, Blazor adalah kerangka kerja aplikasi yang menggunakan RazorComponents pada klien, menggunakan dua model hosting yang berbeda (WebAssembly dan sisi server).

image

Saya telah menambahkan diagram yang menunjukkan bagaimana saya melihatnya.. komentar diterima

Blazor (sisi klien w/WASM) dan Blazor (sisi server w/.NET Core) terdengar hebat!

Komponen Razor untuk UI keduanya, dengan Blazor sebagai kerangka kerja untuk aplikasi terlepas dari model hosting. Sederhana, bersih, dan seperti yang dikatakan salah satu komedian favorit saya.... GIT R DONE!

Klien Blazor dan sisi server benar-benar terdengar bagus.
Dan untuk pemula, lebih mudah memahami perbedaan antara sisi klien dan sisi server.

Seperti yang dikatakan orang lain, ada alasan kuat untuk mempertimbangkan .blazor (dan nama "komponen Blazor"). Bisakah lebih banyak alasan di balik mempertahankan .razor (dan nama "Komponen Razor") dibagikan?

Inilah alasan hingga saat ini yang dapat saya temukan:

Kami berencana untuk mempertahankan ekstensi .razor untuk komponen. Komponen didasarkan pada sintaks Razor, tetapi komponen ditangani secara berbeda oleh compiler Razor, sehingga mereka memerlukan ekstensi file yang berbeda.

Saya merasa pandangan saya mungkin terlalu sederhana:

const string serverSideName = "Blazor (server-side)";
const string clientSideName = "Blazor (client-side)";

string componentModel = "Razor Components";
string ext = ".razor";

if (serverSideName.Contains("Blazor") && clientSideName.Contains("Blazor"))
{
    componentModel = "Blazor Components";
    ext = ".blazor";
} 

Console.WriteLine(componentModel);
Console.WriteLine(ext);

Ada beberapa alasan mengapa kami lebih memilih untuk mempertahankan ekstensi .razor:

  • Nama itu masih akurat dan deskriptif. File .razor adalah komponen UI yang ditulis dengan sintaks Razor.
  • Kurangi pengadukan. Memperbarui ekstensi file memerlukan koordinasi yang adil di beberapa tim dan proyek. Karena kami telah melakukan pekerjaan ini untuk .razor, kami memilih untuk tidak melakukannya lagi kecuali ada alasan yang sangat bagus untuk melakukannya.
  • Lindungi kerangka kerja dari nama produk atau perubahan strategi. Dengan menjaga penamaan model komponen sedikit lebih umum, kami berharap dapat mengurangi dampak dari kemungkinan pengacakan nama atau perubahan arah proyek di masa mendatang.

@danroth27 Yang mengganggu saya adalah sintaks Razor ada di file .cshtml dan .razor. Saya pikir akan ada kebingungan ekstensi mana untuk tampilan Halaman/Komponen/MVC Razor mana.

Dua poin lainnya cukup adil.

@danroth27

Nama itu masih akurat dan deskriptif. File .razor adalah komponen UI yang ditulis dengan sintaks Razor.

Apa yang mengganggu saya tentang argumen ini adalah bahwa file .razor berisi hal-hal seperti event handler, metode siklus hidup, atau binding variabel. Konsep-konsep ini sangat spesifik untuk Blazor dan tidak akan berfungsi di luar itu. Jadi meskipun sintaks Razor, itu adalah rasa yang sangat spesifik yang memungkinkan logika sisi klien untuk dieksekusi.

Hal-hal ini tidak akan berfungsi untuk "Komponen Razor" sisi server dan server-render murni, yang bisa menjadi hal hipotetis di masa depan (karena misalnya fragmen render akan bekerja dengan cukup baik di server juga).

Jadi kami mengunci ekstensi file .razor dan nama "Komponen Razor" untuk rasa tertentu dari Razor yang hanya akan berfungsi untuk komponen dengan perilaku sisi klien yang disematkan.

@danroth27 Hampir semua orang (termasuk saya) menginginkannya .blazor bukannya .razor lalu mengapa Anda ingin tetap menggunakan .razor individual. Apakah ada tantangan teknis untuk mengubah ini? atau hanya ini preferensi Anda dan tim Anda?

Terima kasih.

Seperti yang disebutkan @danroth27 berkoordinasi dengan banyak tim, saya dapat memikirkan, Tim VS, tim tim Razor, itu mungkin merupakan bagian besar pekerjaan yang masing-masing tim memiliki prioritas tugas yang berbeda.

Saya dapat melihat ekstensi .razor cocok jika itu akan menjadi hal yang lebih umum yang menjelaskan segala jenis komponen yang ditulis dalam Razor seperti bagaimana .xaml digunakan untuk sumber daya dan kontrol di dunia desktop.

Katakan jika memungkinkan di masa mendatang Anda dapat menggunakan kontrol asli UWP / xaml dibuat menggunakan pisau cukur, bukan html melalui elektron tetapi murni asli, karena gaya kontrol konstruksi yang sangat penting dari pisau cukur mungkin menjadi alternatif yang menarik untuk .xaml's cara deklaratif saat ini dalam melakukan sesuatu (terutama dukungan silet untuk aliran kontrol C#).

Itu adalah contoh teoretis, pada saat itu Anda dapat mengatakan bahwa ia menggunakan Komponen Razor tetapi tidak pada konteks Blazor melainkan pada konteks asli seperti React Native di mana hal-hal dapat berbeda seperti pengikatan acara menjadi berbeda, beberapa atribut khusus Blazor tidak berlaku dll...

Saya melihat Blazor sebagai kerangka kerja yang menggunakan Komponen Razor ( .razor ) seperti bagaimana Bereaksi sebagai kerangka kerja menggunakan .jsx/.tsx untuk komposisi komponen dan seperti .jsx/.tsx itu mungkin terjadi dapat digunakan pada kerangka kerja serupa lainnya seperti bagaimana Vue dan TKO mendukung .jsx/.tsx dengan mengonfigurasi apa yang dilakukan sistem pembangunan ke file .jsx/.tsx .

Terima kasih semuanya atas tanggapan Anda tentang masalah ini. Komponen Razor mengganti nama kembali ke Blazor sisi server selesai!

Kami telah memutuskan untuk membiarkan ekstensi .razor apa adanya karena alasan yang tercantum di atas . Kami memiliki campuran umpan balik tentang keputusan ini. Meskipun kami menghargai keinginan untuk Blazor semua hal, kami pikir ekstensi saat ini memadai dan kami lebih memilih untuk memfokuskan upaya kami untuk menyiapkan Blazor untuk dikirim daripada mengaduk ekstensi file. Dengan keputusan ini, saya akan melanjutkan dan menutup masalah ini.

Ganti nama label fitur-Komponen menjadi fitur-Blazor juga.

Dears, saya menggunakan vs 2019, saya telah menginstal Blazor versi terakhir, saya memiliki core 3 preview 4, saya telah membuat proyek Blazor, semua halaman sekarang dengan ekstensi .razor bukan .cshtml, saya menjalankan aplikasi, tetapi memberi saya Memuat... tanpa pindah ke halaman Index.razor, mohon bantuannya. Terima kasih sebelumnya.

@ImadMichaelAyoub Apakah Anda memiliki pesan kesalahan di konsol? Apakah Anda menjalankan Blazor sisi klien atau sisi server?

Saya akan menyarankan ini mungkin bukan tempat terbaik untuk diskusi ini. Mungkin akan lebih baik untuk bergabung dengan saluran Blazor Gitter (https://gitter.im/aspnet/Blazor) dan kami dapat membantu Anda di sana.

Terima kasih balasannya. Saya menggunakan Blazor sisi klien. Tampaknya aplikasi menjalankan file index.html di wwwroot dan tidak pindah ke index.cshtml di folder halaman.

Saya baru mengenal Razor dan Blazor. Ini membingungkan ketika mencari solusi online, Anda mendapatkan banyak pisau cukur atau barang lama yang tidak berlaku lagi, menambah lebih banyak kebingungan. Saya sangat memilih untuk mengubah nama baru (bahkan ke .blazor) sehingga kami dapat mencari dan mendapatkan yang terbaru.

Kami berencana untuk mempertahankan ekstensi .razor untuk komponen. Komponen didasarkan pada sintaks Razor, tetapi komponen ditangani secara berbeda oleh compiler Razor, sehingga mereka memerlukan ekstensi file yang berbeda.

Apakah ini berarti - "Direncanakan untuk mempertahankan ekstensi .razor yang sama.. tetapi, ia membutuhkan ekstensi yang berbeda dari .razor, meskipun tidak direncanakan" ?

"Teknologi Hebat hadir dengan kebingungan nama yang hebat"

Apakah halaman ini membantu?
0 / 5 - 0 peringkat