Aspnetcore: Cambiar el nombre de los componentes de Razor a Blazor del lado del servidor

¿Es esta una decisión aprobada? ¿Todavía podemos votar?

Personalmente, estoy en contra de cambiar el nombre. Creo que Razor Components es un nombre mejor. :(

@xclud Es un foro abierto, por lo que los comentarios siempre son bienvenidos 😃

Seguiremos haciendo referencia al modelo de componente como componentes de Razor (es decir, un archivo .razor seguirá siendo un componente de Razor), pero cuando hablamos del modelo de aplicación, nos resulta muy engorroso tener nombres diferentes. Ya hay bastante impulso detrás del nombre Blazor, así que nos gustaría mantenerlo. Los nombres son, por supuesto, subjetivos: no importa el nombre que elijamos, no todos estarán contentos, pero Blazor parece habernos servido bastante bien hasta ahora.

Creo que esta es una buena movida. No ha habido un final de confusión sobre la relación entre Razor Components y Blazor. Hasta el punto de que la gente ha pensado que son marcos diferentes, no solo diferentes formas de renderizar.

Además, en mi opinión personal, Blazor es un nombre genial.

Como alguien que habla con mucha frecuencia con la gente sobre Blazor. Razor Components no ha sido más que confusión. Es confuso en términos de: cuándo una aplicación Blazor es una aplicación Razor Components, Razor Components en lo que respecta a [Razor Pages & Razor Class Libraries] y tropezar con uno mismo al decir Razor / Blazor. También hace que escribir sobre Blazor sea difícil, SEO difícil, podría continuar.

¡La cordura prevalece! Muchas gracias por este cambio.

¿Qué sucedió con las extensiones de archivo .razor, dado que las páginas de razor siguen siendo .cshtml y los componentes son .razor, podría ser beneficioso llamarlo .blazor? ¿O llamar a las páginas de la maquinilla de afeitar también .razor en lugar de .cshtml?
Cosas bastante confusas

Planeamos mantener la extensión .razor para componentes. Los componentes se basan en la sintaxis de Razor, pero el compilador de Razor los maneja de manera diferente, por lo que necesitan una extensión de archivo diferente.

¿Qué pasa con la Blazor alojado plantilla? Para el modelo del lado del cliente, es la forma más fácil de:

• aplicando los encabezados de seguridad de CSP
• calcular los hash SRI (idealmente, esto también será necesario para los activos descargados directamente por blazor.webassembly.js)
• comprimiendo los activos (al menos hasta que los archivos dll se envíen con el tipo de contenido wasm que ya está comprimido por el par de CDN que probé)

Así que espero que la plantilla alojada todavía esté presente.

También me encanta este cambio de nombre a "Blazor". ATM hablando con la gente sobre los componentes Blazor y Razor es simplemente confusión.

Blazor es una tecnología con (al menos) dos modelos de alojamiento. Entonces, ¡me gusta Blazor!

Un nombre para gobernarlos a todos. Un Blazor con dos modelos de alojamiento diferentes es definitivamente mejor. Se salva de mucha confusión en el futuro.

¡Doy la bienvenida a este cambio! Creo que el nombre nuevo (o antiguo) es mucho menos confuso.

Estoy de acuerdo con @vertonghenb en que la extensión del archivo también debería cambiarse a .blazor . Tiene mucho más sentido. Tanto .cshtml como .razor tienen sintaxis razor, pero solo uno debe tener un código específico de Blazor que haría que una extensión de archivo .blazor más precisa y menos ambigua en mi humilde opinión.

Comentario breve: Estoy de acuerdo con cambiar el nombre de _Razor Components_ a _Server-side Blazor_.

Respuesta larga: creo que los "componentes" del lado del cliente y del lado del servidor deberían tener el mismo nombre, sea cual sea: Blazor, Razor Components, ASP.NET Core Components. Por ejemplo, React y React Native son tecnologías mucho más diferentes y, sin embargo, comparten el mismo nombre.

Ventaja del nombre Blazor:

• Ya es un nombre bien establecido en la comunidad. En realidad también se entiende como tecnología para ejecutar .NET en un navegador, eso no es 100% correcto.
• Puede ser más fácil para las personas aceptar / comprender que Blazor se puede usar sin .NET en el lado del servidor (en realidad, sin ningún lado del servidor).

Ventaja del nombre de Razor Components:

• La vinculación con Razor y ASP.NET Core puede ayudar a las personas a comprender que la tecnología tendrá el soporte y la estabilidad adecuados. Aunque como Blazor ya ha llamado mucho la atención creo que se entiende como tecnología estable.

Y con respecto a la extensión, depende de cómo la compilación de Razor sea extensible. Si, por ejemplo, en el futuro habrá páginas Razore generadas estáticamente también con la extensión .razor y el compilador puede manejarlo, entonces yo mantendría la extensión .razor . Básicamente, la extensión .xaml se usa para controles, páginas, recursos y objetos de aplicación.

Creo que esto debería ser perfectamente alcanzable. No sé cuál es el estado actual para admitir el código subyacente para los componentes de Razor. Sin embargo, si lo hay, el código subyacente define si el componente se hereda de ComponentBase o de cualquier otra cosa. Y esto puede determinar cómo se debe compilar el archivo .razor . Y sin el código subyacente, la herencia predeterminada es ComponentBase y, en el futuro, puede ser posible cambiar la clase base predeterminada.

Sin embargo, si los futuros objetos de Razor necesitarían tener una extensión diferente, entonces .blazor para los componentes de Blazor sería una opción mucho mejor.

¡Agradezco mucho este cambio! El nombre "componentes de Razor" siempre fue un poco confuso porque la expectativa era que esto fuera una cosa puramente del lado del servidor, como todo lo demás que hace Razor. Así que la expectativa era que los componentes de Razor fueran, algo así como controles de usuario en WPF, una forma de componer componentes personalizados usando una sintaxis de Razor en lugar de código (como lo permiten los ayudantes de etiquetas).

Al cambiar el nombre de esto, esa confusión se elimina, y de hecho tenemos la oportunidad de eventualmente encontrar componentes de Razor componibles del lado del servidor en algún momento.

En cuanto a la extensión .razor , como otras, creo que tendría más sentido usar .blazor lugar. Según tengo entendido, esos archivos pueden contener código que solo es viable dentro de un contexto Blazor, ya que la lógica está profundamente acoplada al componente. No asumo que esto sea posible reutilizar en un contexto que no sea Blazor. Además, si los componentes de Blazor del lado del cliente terminan usando lo mismo, creo que usar .blazor consistentemente es una mejor idea para identificar los componentes de Blazor (que luego se pueden usar en el lado del servidor o en el lado del cliente) .

Sé que @poke y @duracellko mencionaron el término componentes blazor de pasada, pero en realidad me gusta ese nombre. ¿Qué pasa con __Blazor Components__ en lugar de __Blazor (del lado del servidor) __?

Oh. y creo que .blazor para el nombre de la extensión también es una buena idea.

@myty Creo que conceptualmente, los componentes siempre fueron "componentes Blazor" (es decir, creas componentes con Blazor). “Blazor (del lado del servidor)” y “Blazor (del lado del cliente)” son los dos modelos de alojamiento diferentes en los que puede consumir y ejecutar los mismos (¿creo?) Componentes de Blazor. Por lo tanto, usaría "componentes Blazor" para describir que está creando un componente y "Blazor del lado del servidor" para describir cómo está ejecutando los componentes Blazor.

@myty Creo que conceptualmente, los componentes siempre fueron "componentes Blazor" (es decir, creas componentes con Blazor). “Blazor (del lado del servidor)” y “Blazor (del lado del cliente)” son los dos modelos de alojamiento diferentes en los que puede consumir y ejecutar los mismos (¿creo?) Componentes de Blazor. Por lo tanto, usaría "componentes Blazor" para describir que está creando un componente y "Blazor del lado del servidor" para describir cómo está ejecutando los componentes Blazor.

El hecho de que siempre fueran componentes Blazor fue lo que me convenció del nombre. Dígalo como es y suena genial también. :)

... pero también veo la confusión entre el lado del servidor y el lado del cliente. Es difícil contar la historia sin mencionarlos específicamente.

¡Sí! Finalmente :) Blazor es el verdadero nombre.

¿siquiera ardes?

sí

Para mí Blazor = WASM.

Entonces, 'Razor Components' (SignarR!) Es algo completamente diferente. Explicar la diferencia es bastante fácil: Blazor es WASM.

EN MI HUMILDE OPINIÓN.

Definitivamente esta es la decisión correcta. Incluso después de que se introdujera el nuevo término "Componentes de Razor", mis colegas y yo seguimos refiriéndonos a él como Blazor del lado del servidor. También prefiero la extensión .blazor o algo así como .component. Las vistas en MVC también usan la sintaxis de razor, por lo que .razor trae confusión adicional.

Creo que el cambio de sentido para cambiar el nombre de Razor Components a Blazor es bueno.

Creo que la extensión del componente no debería ser .razor ya que es confuso tener 2 extensiones diferentes que representen archivos de afeitar. ( .cshtml y .razor )

Creo que las extensiones .blazor o .component serían una mejor alternativa que .razor .

Gracias por hacer que este nombre vuelva a cambiar a Blazor Server-Side . Me siento aliviado de ser bastante honesto. Tuve un pequeño lolwut? momento en el que escuché por primera vez el cambio de nombre a Razor Components .

Personalmente, creo que la palabra Razor está lo suficientemente sobrecargada:

• Maquinilla de afeitar
• Vistas de Razor
• Páginas de Razor
• Controladores de página de Razor
• Modelos de página de maquinilla de afeitar
• Bibliotecas de clases de Razor
• Vistas parciales de Razor
• Componentes de Razor View
• : nuevo: Componentes de Razor: confuso: //confusing much yet?
• Siguiente característica de la familia Razor : // just kidding :)

Ya hemos hecho que sea difícil para alguien nuevo que intente navegar por todas estas cosas de Razor junto con tratar de comprender cada caso de uso.

No solo sentir empatía por los novatos, sino imaginar tratar de explicar y mantener el uso de la terminología "correcta" en equipos grandes al describir y coordinar (cómo / cuándo / qué) usar.

Blazor es un buen nombre ya que ya nos hemos asociado con sus casos de uso. Yo, incluso Razor Sockets habría sido un nombre mejor que Razor Components . :Gafas de sol:

Además, creo que cambiar el nombre de .razor a .blazor es una buena idea.

Nombrar es difícil.
Mantén las cosas simples.

-Brian :)

Tener interés en Razor Components porque funciona bien en mi proyecto me llevó a aquí.
Entiendo de lo que estamos hablando, pero alguien que recién está comenzando podría estar confundido sobre lo que hay debajo del capó, debido al nombre.
Si el objetivo es enviar componentes de Razor solo como un reemplazo temporal para el próximo Blazor, no querría que se cambiara su nombre.

@Mitiko Server-side Blazor no se verá afectado por las decisiones sobre el cliente Blazor (basado en WebAssembly). Suponiendo que este último se publique en algún momento, aún podrá usar Blazor del lado del servidor. Ambos modelos de aplicación podrán compartir ciertas cosas, por lo que tiene más sentido alinearlas con su nombre también.

Por eso es, en última instancia, confuso. Cuando tienes una lógica a la que no le importa dónde está alojada, ¿cómo se llama? Luego, el marco cambia mágicamente los nombres según el "shell" que uses. Simplemente no tiene sentido tener dos nombres. Para el punto de @poke , vea el video a continuación: @Mitiko

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

¿Qué pasa con la plantilla alojada de blazor?

@ghidello Se queda como está. Por lo tanto, habrá tres plantillas Blazor: del lado del cliente independiente, alojado en ASP.NET Core y del lado del servidor

Me alegra ver esto, como dijiste: el nombre tiene un significado y un impulso detrás de él y para mí transmite que ambos modelos están avanzando con un fuerte apoyo.

En mi opinión, también debe nombrar el nombre del modelo del componente para hacer referencia a Blazor, incluso si usa la sintaxis / motor de Razor. Simplemente lo convertiría en una solución de ventanilla única más cohesiva, en términos de nombres.

¿Qué pasa con el espacio de nombres de Componentes? También debería cambiarse el nombre.

Y los archivos .razor deben ser .blazor ya que están vinculados a la tecnología Blazor. De lo contrario, también deberían usarse para Razor Mvc común.

Todavía un poco confundido con respecto a los componentes:

Entonces, si estoy construyendo una biblioteca de componentes, que funciona tanto con el lado del servidor como con el lado del cliente Blazor, ¿me refiero a los componentes como "componentes Blazor" o "componentes Razor"?

@egil Según lo que dijo Dan Roth anteriormente, un componente seguirá siendo conocido como Componente Razor.

Seguiremos haciendo referencia al modelo de componente como componentes de Razor (es decir, un archivo .razor seguirá siendo un componente de Razor)

Añadiendo mi voto de aprobación a este cambio.

Como yo lo veo, un RazorComponent es un componente de C # escrito usando la sintaxis de Razor y el código de C #. Podríamos usar RazorComponents en una amplia gama de proyectos, incluidos Blectron (como en la demostración de StorageExplorer), generadores de HTML (por ejemplo, para la generación del cuerpo del correo electrónico de la misma manera que lo hace .cshtml contenido. No se limitan a solo Blazor .

Por el contrario, Blazor es el marco de la aplicación que usa RazorComponents en el cliente, usando dos modelos de alojamiento diferentes (WebAssembly y del lado del servidor).

Agregué un diagrama que muestra cómo lo veo ... comentarios bienvenidos

¡Blazor (del lado del cliente con WASM) y Blazor (del lado del servidor con .NET Core) suena genial!

Componentes de Razor para las IU de ambos, con Blazor como marco para las aplicaciones independientemente del modelo de alojamiento. Sencillo, limpio y como diría uno de mis comediantes favoritos ... ¡GIT R DONE!

El lado del servidor y del cliente de Blazor suena realmente bien.
Y para los principiantes, es más fácil comprender las diferencias entre el lado del cliente y el lado del servidor.

Como han dicho otros, existen razones de peso para considerar .blazor (y el nombre del "componente Blazor"). ¿Se podrían compartir más razones para mantener .razor (y su nombre de "componente Razor")?

Este es el razonamiento hasta este punto que pude encontrar:

Planeamos mantener la extensión .razor para componentes. Los componentes se basan en la sintaxis de Razor, pero el compilador de Razor los maneja de manera diferente, por lo que necesitan una extensión de archivo diferente.

Creo que mi punto de vista puede ser demasiado simplista:

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

Hay algunas razones por las que preferiríamos mantener la extensión .razor:

• El nombre sigue siendo exacto y descriptivo. Un archivo .razor es un componente de la interfaz de usuario escrito con la sintaxis de Razor.
• Reducir la rotación. La actualización de la extensión del archivo requiere una buena cantidad de coordinación entre varios equipos y proyectos. Como ya hemos hecho este trabajo para .razor, preferimos no volver a hacerlo a menos que haya una buena razón para hacerlo.
• Aísle el marco de los cambios en el nombre del producto o la estrategia. Al mantener la denominación del modelo de componente un poco más genérica, esperamos reducir el impacto de cualquier posible mezcla de nombres o cambios en la dirección del proyecto en el futuro.

@ danroth27 Lo que me molesta es que la sintaxis de Razor está en archivos .cshtml y .razor. Creo que habrá confusión sobre qué extensión es para qué vista de página / componente / MVC de Razor.

Otros dos puntos son bastante justos.

@ danroth27

El nombre sigue siendo exacto y descriptivo. Un archivo .razor es un componente de la interfaz de usuario escrito con la sintaxis de Razor.

Lo que me molesta de este argumento es que un archivo .razor contiene cosas como controladores de eventos, métodos de ciclo de vida o enlaces de variables. Estos conceptos son muy específicos de Blazor y no funcionarán fuera de él. Entonces, si bien es una sintaxis de Razor, es un sabor muy específico de la misma que permite que se ejecute la lógica del lado del cliente.

Estas cosas no funcionarán para los "componentes Razor" puramente del lado del servidor y del servidor, lo que podría ser algo hipotético en el futuro (ya que, por ejemplo, los fragmentos de procesamiento también funcionarían bastante bien en el servidor).

Por lo tanto, estamos bloqueando la extensión de archivo .razor y el nombre "Componente de Razor" para una versión específica de Razor que solo funcionará para componentes con comportamiento integrado del lado del cliente.

@ danroth27 Casi todo el mundo (incluyéndome a mí) lo quiere .blazor lugar de .razor entonces ¿por qué quiere atenerse a .razor individualmente? ¿Hay algún desafío técnico para cambiar esto? ¿O simplemente esta es tu preferencia y la de tu equipo?

Gracias.

Como @ danroth27 mencionó la coordinación con múltiples equipos, puedo pensar en el equipo VS, el equipo del equipo Razor, podría ser una gran parte del trabajo en el que cada equipo tiene diferentes prioridades en las tareas.

Puedo ver el ajuste de la extensión .razor si va a ser algo más genérico que describa cualquier tipo de componentes escritos en Razor, como la forma en que .xaml se usa tanto para recursos como para controles en el mundo del escritorio.

Supongamos que, si es posible en el futuro, podría usar controles nativos UWP / xaml creados con maquinilla de afeitar, no html través de electrones, sino puramente nativos, ya que el estilo imperativo de la maquinilla de afeitar de construir controles podría ser una alternativa convincente por .xaml's forma declarativa actual de hacer las cosas (especialmente el soporte de razor para los flujos de control de C #).

Sin embargo, ese es un ejemplo teórico, en ese momento se podría decir que usa Razor Components pero no en un contexto Blazor sino en un contexto nativo como React Native donde las cosas pueden diferir, como que los enlaces de eventos son diferentes, algunos atributos específicos de Blazor no son aplicables. etc ...

Veo Blazor como un marco que usa componentes de Razor ( .razor ) como React como marco usa .jsx/.tsx para la composición de componentes y como .jsx/.tsx podría ser posible que sea utilizable en otros marcos similares, como la forma en que Vue y TKO admiten .jsx/.tsx configurando lo que hace el sistema de compilación con los archivos .jsx/.tsx .

Gracias a todos por sus comentarios sobre este tema. ¡El cambio de nombre de los componentes de Razor a Blazor del lado del servidor está listo!

Hemos decidido dejar la extensión .razor como está por las razones mencionadas anteriormente . Hemos recibido una mezcla de comentarios sobre esta decisión. Si bien apreciamos el deseo de Blazor de todas las cosas, creemos que la extensión actual es adecuada y preferimos centrar nuestros esfuerzos en preparar Blazor para su envío en lugar de batir la extensión del archivo. Dada esta decisión, seguiré adelante y cerraré este tema.

También cambie el nombre de la etiqueta feature-Components a feature-Blazor.

Queridos, estoy usando vs 2019, he instalado la última versión de Blazor, tengo la vista previa 4 del núcleo 3, he creado un proyecto de Blazor, todas las páginas ahora tienen la extensión .razor en lugar de .cshtml, ejecuté la aplicación, pero me dio Cargando ... sin pasar a la página Index.razor, cualquier ayuda por favor. Gracias por adelantado.

@ImadMichaelAyoub ¿Tiene algún mensaje de error en la consola? ¿Está ejecutando Blazor del lado del cliente o del lado del servidor?

Sugeriría que este probablemente no sea el mejor lugar para esta discusión. Probablemente sea mejor unirse al canal Blazor Gitter (https://gitter.im/aspnet/Blazor) y podemos ayudarlo allí.

Gracias por la respuesta. Estoy usando Blazor del lado del cliente. Parece que la aplicación ejecuta el archivo index.html en wwwroot y no se mueve a index.cshtml en la carpeta de páginas.

Soy nuevo en Razor y Blazor. Es confuso cuando busca una solución en línea, obtiene toneladas de navajas o cosas viejas que ya no se aplican, lo que agrega más confusión. Voto altamente para cambiar el cambio a un nuevo nombre (incluso a .blazor) para que podamos buscar y obtener lo último.

Planeamos mantener la extensión .razor para componentes. Los componentes se basan en la sintaxis de Razor, pero el compilador de Razor los maneja de manera diferente, por lo que necesitan una extensión de archivo diferente.

¿Significa esto: "Está planeado mantener la misma extensión .razor ... pero necesita una extensión diferente a .razor, incluso si no está planeada"?

"La gran tecnología viene con una gran confusión de nombres"