Aspnetcore: Renommer les composants Razor en Blazor côté serveur

Est-ce une décision approuvée? Peut-on encore voter ?

Personnellement, je suis contre le changement de nom. Je pense que Razor Components est un meilleur nom. :(

@xclusd C'est un forum ouvert, donc les commentaires sont toujours les bienvenus

Nous ferons toujours référence au modèle de composant en tant que composants Razor (c'est-à-dire qu'un fichier .razor sera toujours un composant Razor), mais lorsque nous parlons du modèle d'application, nous trouvons qu'il est très difficile d'avoir des noms différents. Il y a déjà pas mal d'élan derrière le nom Blazor, nous aimerions donc nous y tenir. Les noms sont bien sûr subjectifs - quel que soit le nom que nous choisissons, tout le monde ne sera pas content, mais Blazor semble nous avoir plutôt bien servi jusqu'à présent.

Je pense que c'est une bonne initiative. Il n'y a eu aucune fin de confusion sur la relation entre Razor Components et Blazor. Au point que les gens ont pensé qu'il s'agissait de frameworks différents, pas seulement de modes de rendu différents.

De plus, à mon avis, Blazor est un nom cool.

En tant que personne qui parle très fréquemment aux gens de Blazor. Razor Components n'a été que confusion. C'est déroutant en termes de: quand une application Blazor est-elle une application Razor Components, Razor Components en ce qui concerne [Razor Pages & Razor Class Libraries], et trébucher sur soi-même en disant Razor/Blazor. Cela rend également difficile l'écriture sur Blazor, le référencement difficile, je pourrais continuer.

La raison l'emporte ! Merci beaucoup pour ce changement.

Que se passe-t-il avec les extensions de fichier .razor, étant donné que les pages razor sont toujours .cshtml et les composants sont .razor, il pourrait être avantageux de l'appeler .blazor ? Ou appelez également les pages de rasoir .razor au lieu de .cshtml ?
Des trucs assez déroutants

Nous prévoyons de conserver l'extension .razor pour les composants. Les composants sont basés sur la syntaxe Razor, mais les composants sont gérés différemment par le compilateur Razor, ils ont donc besoin d'une extension de fichier différente.

Qu'en est-il du modèle hébergé par blazor ? Pour le modèle côté client, c'est le moyen le plus simple pour :

• application des en-têtes de sécurité CSP
• calculer les hachages SRI (idéalement, cela sera également nécessaire pour les actifs téléchargés directement par blazor.webassembly.js)
• compresser les actifs (au moins jusqu'à ce que les fichiers dll soient expédiés avec le type de contenu wasm qui est déjà compressé par les quelques CDN que j'ai essayés)

J'espère donc que le modèle hébergé sera toujours présent.

J'aime aussi ce renommer simplement "Blazor". ATM parler aux gens des composants Blazor et Razor est tout simplement une confusion.

Blazor est une trchnologie avec (au moins) deux modèles d'hébergement. Alors, j'aime Blazor !

Un nom pour les gouverner tous. Un Blazor avec deux modèles d'hébergement différents est certainement mieux. Cela évite beaucoup de confusion sur la route.

Je salue ce changement ! La nouvelle (ou l'ancienne) dénomination est beaucoup moins déroutante, je pense.

Je suis d'accord avec @vertonghenb que l'extension de fichier devrait également être renommée en .blazor . Cela a beaucoup plus de sens. .cshtml et .razor ont tous deux une syntaxe rasoir, mais un seul devrait avoir un code spécifique à Blazor, ce qui rendrait une extension de fichier .blazor plus précise et moins ambiguë à mon humble avis.

Commentaire court : je suis d'accord avec le changement de nom de _Razor Components_ en _Server-side Blazor_.

Réponse longue : je pense que les "composants" côté client et côté serveur devraient avoir le même nom, quel qu'il soit : Blazor, Razor Components, ASP.NET Core Components. Par exemple, React et React Native sont des technologies bien plus différentes et pourtant elles partagent le même nom.

Avantage du nom Blazor :

• C'est déjà un nom bien établi dans la communauté. En fait, cela est également compris comme une technologie permettant d'exécuter .NET dans un navigateur, ce qui n'est pas correct à 100%.
• Il peut être plus facile pour les gens d'accepter/de comprendre que Blazor peut être utilisé sans .NET côté serveur (en fait sans aucun côté serveur).

Avantage du nom de Razor Components :

• La liaison avec Razor et ASP.NET Core peut aider les gens à comprendre que la technologie bénéficiera d'un support et d'une stabilité appropriés. Bien que Blazor ait déjà attiré beaucoup d'attention, je pense qu'il s'agit d'une technologie stable.

Et en ce qui concerne l'extension, cela dépend de la façon dont la compilation Razor est extensible. Si, par exemple, à l'avenir, il y aura des pages Razore générées statiquement également avec l'extension .razor et que le compilateur peut le gérer, alors je garderais l'extension .razor . Fondamentalement, l'extension .xaml est utilisée pour les contrôles, les pages, les ressources et les objets d'application.

Je pense que cela devrait être parfaitement réalisable. Je ne sais pas quel est l'état actuel de la prise en charge du code-behind pour les composants Razor. Cependant, s'il y en a, alors code-behind définit si le composant est hérité de ComponentBase ou de toute autre chose. Et cela peut déterminer comment le fichier .razor doit être compilé. Et sans code-behind, l'héritage par défaut est ComponentBase et à l'avenir, il sera peut-être possible de modifier la classe de base par défaut.

Cependant, si les futurs objets Razor devaient avoir une extension différente, alors .blazor pour les composants Blazor serait une bien meilleure option.

Je me réjouis beaucoup de ce changement ! Le nom « composants Razor » était toujours un peu déroutant car l'on s'attendait à ce qu'il s'agisse d'une chose purement côté serveur, comme tout ce que fait Razor. On s'attendait donc à ce que les composants Razor soient, un peu comme les contrôles utilisateur dans WPF, un moyen de composer des composants personnalisés à l'aide d'une syntaxe Razor au lieu de code (comme le permettent les assistants de balise).

En le renommant, cette confusion est supprimée et nous avons en fait la possibilité de finir par proposer des composants Razor composables côté serveur à un moment donné.

En ce qui concerne l'extension .razor , comme d'autres, je pense qu'il serait plus logique d'utiliser .blazor place. D'après ce que je comprends, ces fichiers peuvent contenir du code qui n'est viable que dans un contexte Blazor, car la logique est profondément couplée au composant. Je ne suppose pas que cela sera possible de réutiliser dans un contexte non Blazor. De plus, si les composants Blazor côté client finiront par utiliser la même chose, je pense qu'utiliser .blazor cohérente est une meilleure idée pour identifier les composants Blazor (qui peuvent ensuite être utilisés côté serveur ou côté client) .

Je sais que @poke et @duracellko ont tous deux mentionné le terme composants blazor en passant, mais j'aime vraiment ça comme nom. Qu'en est-il des __Blazor Components__ au lieu de __Blazor (côté serveur)__ ?

Oh. et je pense que .blazor pour le nom de l'extension est aussi une bonne idée.

@myty Je pense que conceptuellement, les composants étaient toujours des "composants Blazor" (c'est-à-dire que vous créez des composants avec Blazor). « Blazor (côté serveur) » et « Blazor (côté client) » sont les deux modèles d'hébergement différents dans lesquels vous pouvez utiliser et exécuter les mêmes (je pense?) composants Blazor. Vous utiliseriez donc à la fois des « composants Blazor » pour décrire que vous créez un composant et « Blazor côté serveur » pour décrire comment vous exécutez les composants Blazor.

@myty Je pense que conceptuellement, les composants étaient toujours des "composants Blazor" (c'est-à-dire que vous créez des composants avec Blazor). « Blazor (côté serveur) » et « Blazor (côté client) » sont les deux modèles d'hébergement différents dans lesquels vous pouvez utiliser et exécuter les mêmes (je pense?) composants Blazor. Vous utiliseriez donc à la fois des « composants Blazor » pour décrire que vous créez un composant et « Blazor côté serveur » pour décrire comment vous exécutez les composants Blazor.

Le fait qu'il s'agisse toujours de composants Blazor est ce qui m'a convaincu du nom. Dites-le comme il est et ça a l'air cool aussi. :)

...mais, je vois aussi la confusion entre côté serveur et côté client. Il est difficile de raconter l'histoire sans les appeler spécifiquement.

Oui! Enfin :) Blazor est le vrai nom.

flambez-vous même?

Oui

Pour moi Blazor = WASM.

Donc 'Razor Components' (SignarR !) est quelque chose de complètement différent. Expliquer la différence est assez simple : Blazor est WASM.

A MON HUMBLE AVIS.

C'est certainement la bonne décision. Même après l'introduction du nouveau terme "Razor Components", mes collègues et moi l'appelons toujours Blazor côté serveur. Je préfère aussi l'extension .blazor ou quelque chose comme .component. Les vues dans MVC utilisent également la syntaxe razor, donc .razor apporte une confusion supplémentaire.

Je pense que le demi-tour pour renommer Razor Components en Blazor est bon.

Je pense que l'extension du composant ne devrait pas être .razor car il est déroutant d'avoir 2 extensions différentes représentant des fichiers rasoir. ( .cshtml et .razor )

Je pense que les extensions .blazor ou .component seraient une meilleure alternative que .razor .

Merci d'avoir refait ce nom en Blazor Server-Side . Je suis soulagé d'être tout à fait honnête. J'ai eu un petit lolwut? moment où j'ai entendu pour la première fois le nom changer pour Razor Components .

Personnellement, je pense que le mot Razor est assez surchargé :

• Le rasoir
• Vues de rasoir
• Pages de rasoir
• Contrôleurs Razor Page
• Modèles de pages de rasoir
• Bibliothèques de classe Razor
• Razor Vues partielles
• Composants de la vue rasoir
• :new: Razor Components :confused: //confusing much yet?
• Prochaine fonctionnalité de la famille Razor : // just kidding :)

Nous avons déjà rendu la tâche difficile à quelqu'un de nouveau qui essaie de naviguer dans toutes ces choses Razor tout en essayant de comprendre chaque cas d'utilisation.

Non seulement ressentir de l'empathie pour les débutants, mais imaginez essayer d'expliquer et de maintenir une utilisation terminologique « correcte » au sein de grandes équipes lors de la description et de la coordination (comment/quand/quoi) à utiliser.

Blazor est un bon nom puisque nous en sommes déjà venus à nous associer à ses cas d'utilisation. Yo, même Razor Sockets aurait été un meilleur nom que Razor Components . :des lunettes de soleil:

Aussi, je pense que renommer .razor en .blazor est une bonne idée.

Nommer est difficile.
Gardez les choses simples.

-Brian :)

Avoir un intérêt pour Razor Components parce qu'il joue bien dans mon projet m'a amené ici.
Je comprends de quoi nous parlons, mais quelqu'un qui vient de commencer peut être confus de ce qu'il y a sous le capot, à cause du nom.
Si l'objectif est d'expédier des composants Razor juste en remplacement temporaire du prochain Blazor, je ne voudrais pas que son nom change.

@Mitiko Server-side Blazor ne sera pas affecté par les décisions concernant Blazor côté client (basé sur WebAssembly). En supposant que ce dernier soit publié à un moment donné, vous pourrez toujours utiliser Blazor côté serveur. Les deux modèles d'application pourront en fait partager certaines choses, il est donc plus logique de les aligner également sur leur nom.

C'est pourquoi c'est finalement déroutant. Quand vous avez une logique qui ne se soucie pas de l'endroit où elle est hébergée, comment s'appelle-t-elle ? Ensuite, le framework change comme par magie les noms en fonction du "shell" que vous utilisez. Cela n'a pas de sens d'avoir deux noms. Au point de @poke voir la vidéo ci-dessous: @Mitiko

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

Qu'en est-il du modèle hébergé par blazor ?

@ghidello Il reste tel

Je suis heureux de voir cela, comme vous l'avez dit - Le nom a une signification et un élan derrière lui et pour moi, cela signifie que les deux modèles vont de l'avant avec un fort soutien.

OMI, vous devez également nommer le nom du modèle de composant pour faire référence à Blazor, même si vous utilisez la syntaxe/le moteur Razor. Cela en ferait simplement une solution à guichet unique plus cohérente, en termes de nommage.

Qu'en est-il de l'espace de noms des composants ? Il devrait également être renommé.

Et les fichiers .razor doivent être .blazor car ils sont liés à la technologie Blazor. Sinon, ils devraient également être utilisés pour Razor Mvc commun.

Encore un peu confus en ce qui concerne les composants:

Donc, si je construis une bibliothèque de composants, qui fonctionne à la fois avec Blazor côté serveur et côté client, dois-je faire référence aux composants en tant que « composants Blazor » ou « composants Razor » ?

@egil Sur la base de ce que Dan Roth a dit ci-dessus, un composant sera toujours connu sous le nom de composant Razor.

Nous ferons toujours référence au modèle de composant en tant que composants Razor (c'est-à-dire qu'un fichier .razor sera toujours un composant Razor)

Ajout de mon vote d'approbation à ce changement.

À mon avis, un RazorComponent est un composant C# écrit à l'aide de la syntaxe Razor et du code C#. Nous pourrions utiliser RazorComponents dans un large éventail de projets, y compris Blectron (comme dans la démo StorageExplorer), les générateurs HTML (par exemple pour la génération de corps d'e-mail de la même manière que RazorGenerator le fait pour .cshtml Contenu à Blazor .

En revanche, Blazor est le framework d'application qui utilise RazorComponents sur le client, en utilisant deux modèles d'hébergement différents (WebAssembly et côté serveur).

J'ai ajouté un diagramme qui montre comment je le vois .. commentaires bienvenus

Blazor (côté client avec WASM) et Blazor (côté serveur avec .NET Core) sonne bien !

Razor Components pour les interfaces utilisateur des deux, avec Blazor comme framework pour les applications, quel que soit le modèle d'hébergement. Simple, propre et comme dirait l'un de mes comédiens préférés... GIT R DONE !

Blazor côté client et côté serveur sonne vraiment bien.
Et pour les débutants, il est plus facile de comprendre les différences entre côté client et côté serveur.

Comme d'autres l'ont dit, il y a des raisons impérieuses de considérer .blazor (et le nom "Blazor component"). Pourrait-on partager plus de raisons de conserver .razor (et son nom "Razor component") ?

C'est la justification jusqu'à ce point que j'ai pu trouver:

Nous prévoyons de conserver l'extension .razor pour les composants. Les composants sont basés sur la syntaxe Razor, mais les composants sont gérés différemment par le compilateur Razor, ils ont donc besoin d'une extension de fichier différente.

Je pense que mon point de vue est peut-être trop simpliste :

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);

Il y a plusieurs raisons pour lesquelles nous préférons conserver l'extension .razor :

• Le nom est toujours précis et descriptif. Un fichier .razor est un composant d'interface utilisateur écrit avec la syntaxe Razor.
• Réduire le taux de désabonnement. La mise à jour de l'extension de fichier nécessite une bonne coordination entre plusieurs équipes et projets. Puisque nous avons déjà fait ce travail pour .razor, nous préférerions ne pas le refaire à moins qu'il n'y ait une très bonne raison de le faire.
• Isolez le cadre des changements de nom de produit ou de stratégie. En gardant le nom du modèle de composant un peu plus générique, nous espérons réduire l'impact de tout changement de nom potentiel ou de tout changement dans la direction du projet à l'avenir.

@ danroth27 Ce qui me dérange, c'est que la syntaxe Razor se trouve à la fois dans les fichiers .cshtml et .razor. Je pense qu'il y aura confusion pour quelle extension est pour quelle vue Razor Page/Component/MVC.

Les deux autres points sont assez justes.

@danroth27

Le nom est toujours précis et descriptif. Un fichier .razor est un composant d'interface utilisateur écrit avec la syntaxe Razor.

Ce qui me dérange à propos de cet argument, c'est qu'un fichier .razor contient des éléments tels que des gestionnaires d'événements, des méthodes de cycle de vie ou des liaisons de variables. Ces concepts sont très spécifiques à Blazor et ne fonctionneront pas en dehors de celui-ci. Ainsi, bien qu'il s'agisse de la syntaxe Razor, c'est une version très spécifique de celle-ci qui permet à la logique côté client d'être exécutée.

Ces choses ne fonctionneront pas pour les "composants Razor" purement côté serveur et rendus par le serveur, ce qui pourrait être une chose hypothétique à l'avenir (puisque, par exemple, les fragments de rendu fonctionneraient également très bien sur le serveur).

Nous verrouillons donc l'extension de fichier .razor et le nom « composant Razor » pour une version spécifique de Razor qui ne fonctionnera que pour les composants avec un comportement côté client intégré.

@danroth27 Presque tout le monde (y compris moi) le veut .blazor au lieu de .razor alors pourquoi voulez-vous vous en tenir à .razor individuellement. Y a-t-il des défis techniques pour changer cela? ou juste c'est vous et votre préférence d'équipe ?

Merci.

Comme @ danroth27 a mentionné la coordination avec plusieurs équipes, je peux penser à l'équipe VS, l'équipe de l'équipe Razor, cela pourrait représenter une grosse partie du travail pour laquelle chaque équipe a des priorités différentes sur les tâches.

Je peux voir l'extension .razor s'il s'agit d'une chose plus générique qui décrit tout type de composants écrits dans Razor, comme la façon dont .xaml est utilisé à la fois pour les ressources et les contrôles dans le monde du bureau.

Supposons que, si possible à l'avenir, vous puissiez utiliser des contrôles natifs UWP / xaml créés à l'aide de rasoir, pas de html via des électrons mais purement natifs, car le style impératif de construction de contrôles du rasoir pourrait être une alternative convaincante pour .xaml's manière déclarative actuelle de faire les choses (en particulier le support de razor pour les flux de contrôle C#).

C'est un exemple théorique cependant, à ce stade, vous pourriez dire qu'il utilise des composants Razor mais n'est pas dans un contexte Blazor mais plutôt dans un contexte natif comme React Native où les choses peuvent différer, comme les liaisons d'événements étant différentes, certains attributs spécifiques à Blazor ne sont pas applicables etc...

Je vois Blazor comme un framework qui utilise des composants Razor ( .razor ) comme la façon dont React en tant que framework utilise .jsx/.tsx pour la composition de composants et comme .jsx/.tsx il pourrait être possible que ce soit utilisable sur d'autres frameworks similaires comme la façon dont Vue et TKO prennent en charge .jsx/.tsx en configurant ce que le système de génération fait aux fichiers .jsx/.tsx .

Merci à tous pour vos retours sur ce problème. Le renommage des composants Razor en Blazor côté serveur est terminé !

Nous avons décidé de laisser l'extension .razor telle quelle pour les raisons énumérées ci -

Veuillez également renommer l'étiquette feature-Components en feature-Blazor.

Chers, j'utilise vs 2019, j'ai installé la dernière version de Blazor, j'ai core 3 preview 4, j'ai créé un projet Blazor, toutes les pages sont maintenant avec l'extension .razor au lieu de .cshtml, j'ai exécuté l'application, mais en me donnant Chargement... sans passer à la page Index.razor, de l'aide s'il vous plaît. Merci d'avance.

@ImadMichaelAyoub Avez-vous des messages d'erreur dans la console ? Utilisez-vous Blazor côté client ou côté serveur ?

Je dirais que ce n'est probablement pas le meilleur endroit pour cette discussion. Il serait probablement préférable de rejoindre le canal Blazor Gitter (https://gitter.im/aspnet/Blazor) et nous pourrons vous y aider.

Merci pour la réponse. J'utilise Blazor côté client. Il semble que l'application exécute le fichier index.html dans wwwroot et ne se déplace pas vers index.cshtml dans le dossier pages.

Je suis nouveau sur Razor et Blazor. C'est déroutant lorsque vous recherchez une solution en ligne, vous obtenez des tonnes de rasoirs ou de vieux trucs qui ne s'appliquent plus, ce qui ajoute encore plus de confusion. Je vote fortement pour changer le changement de nom (même en .blazor) afin que nous puissions rechercher et obtenir les dernières.

Nous prévoyons de conserver l'extension .razor pour les composants. Les composants sont basés sur la syntaxe Razor, mais les composants sont gérés différemment par le compilateur Razor, ils ont donc besoin d'une extension de fichier différente.

Cela signifie-t-il - "Il est prévu de conserver la même extension .razor.. mais, il a besoin d'une extension différente de .razor, même si ce n'est pas prévu" ?

"La grande technologie vient avec une grande confusion de nom"