Aspnetcore: Renomear Componentes do Razor de volta para Blazor do lado do servidor

Esta é uma decisão aprovada? Ainda podemos votar?

Pessoalmente, sou contra a mudança de nome. Eu acho que Razor Components é um nome melhor. :(

@xclud É um fórum aberto, portanto, feedback é sempre bem-vindo 😃

Ainda vamos nos referir ao modelo de componente como componentes Razor (ou seja, um arquivo .razor ainda será um componente Razor), mas quando falamos sobre o modelo de aplicativo, achamos muito complicado ter nomes diferentes. Já existe um certo impulso por trás do nome Blazor, então gostaríamos de mantê-lo. Os nomes são, obviamente, subjetivos - não importa o nome que escolhermos, nem todos ficarão felizes, mas Blazor parece ter nos servido muito bem até agora.

Acho que é uma boa jogada. A confusão sobre a relação entre Razor Components e Blazor não tem fim. A ponto de as pessoas pensarem que são estruturas diferentes, não apenas formas diferentes de renderização.

Além disso, na minha opinião pessoal, Blazor é um nome legal.

Como alguém que fala muito com as pessoas sobre o Blazor. Razor Components não tem sido nada além de confusão. É confuso em termos de: quando um aplicativo Blazor é um aplicativo Razor Components, Razor Components no que se refere a [Razor Pages & Razor Class Libraries], e tropeçar em si mesmo ao dizer Razor / Blazor. Também torna difícil escrever sobre o Blazor, SEO difícil, eu poderia continuar.

A sanidade prevalece! Muito obrigado por esta mudança.

O que aconteceu com as extensões de arquivo .razor, uma vez que as páginas do razor ainda são .cshtml e os componentes são .razor, pode ser benéfico chamá-las .blazor? Ou chamar as páginas do razor também .razor em vez de .cshtml?
Coisas muito confusas

Estamos planejando manter a extensão .razor para componentes. Os componentes são baseados na sintaxe do Razor, mas os componentes são tratados de maneira diferente pelo compilador do Razor, portanto, eles precisam de uma extensão de arquivo diferente.

E quanto ao modelo hospedado blazor? Para o modelo do lado do cliente, é a maneira mais fácil de:

• aplicando os cabeçalhos de segurança CSP
• computar os hashes SRI (idealmente, isso também será necessário para os ativos baixados diretamente por blazor.webassembly.js)
• compactar os ativos (pelo menos até que os arquivos dll sejam enviados com o tipo de conteúdo wasm, que já está compactado pelos dois CDNs que experimentei)

Portanto, espero que o modelo hospedado ainda esteja presente.

Eu também adoro essa mudança de nome para apenas "Blazor". ATM falando com as pessoas sobre os componentes do Blazor e Razor é pura confusão.

Blazor é uma tecnologia com (pelo menos) dois modelos de hospedagem. Então, eu gosto do Blazor!

Um nome para governar todos eles. Um Blazor com dois modelos de hospedagem diferentes é definitivamente melhor. Isso evita muita confusão no futuro.

Eu agradeço essa mudança! A nomenclatura nova (ou antiga) é muito menos confusa, eu me sinto.

Concordo com @vertonghenb que a extensão do arquivo também deve ser renomeada para .blazor . Faz muito mais sentido Ambos .cshtml e .razor têm sintaxe de razor, mas apenas um deve ter o código específico do Blazor, o que tornaria uma extensão de arquivo .blazor mais precisa e menos ambígua IMHO.

Comentário curto: Concordo com a alteração do nome de volta de _Componentes do Razor_ para _Blazor do lado do servidor_.

Resposta longa: acredito que os "componentes" do lado do cliente e do lado do servidor devem ter o mesmo nome, seja ele qual for: Blazor, Razor Components, ASP.NET Core Components. Por exemplo, React e React Native são tecnologias muito mais diferentes e, ainda assim, compartilham o mesmo nome.

Vantagem do nome Blazor:

• Já é um nome bem estabelecido na comunidade. Na verdade também se entende como tecnologia para rodar .NET em um navegador, que não é 100% correta.
• Pode ser mais fácil para as pessoas aceitar / entender que o Blazor pode ser usado sem .NET no lado do servidor (na verdade, sem nenhum lado do servidor).

Nome da Vantagem dos Componentes Razor:

• A vinculação com o Razor e o ASP.NET Core pode ajudar as pessoas a entender que a tecnologia terá suporte e estabilidade adequados. Embora como o Blazor já tenha recebido muita atenção, acho que é entendido como uma tecnologia estável.

E com relação à extensão, depende de como a compilação do Razor é extensível. Se, por exemplo, no futuro houver páginas do Razore geradas estáticas também com a extensão .razor e o compilador puder lidar com isso, eu manteria a extensão .razor . Basicamente, como .xaml extensão

Acho que isso deve ser perfeitamente alcançável. Não sei qual é o status atual do suporte a code-behind para componentes do Razor. No entanto, se houver, o code-behind define se o componente é herdado do ComponentBase ou de qualquer outra coisa. E isso pode determinar como .razor file deve ser compilado. E sem a herança padrão por trás do código é ComponentBase e, no futuro, pode ser possível alterar a classe base padrão.

No entanto, se futuros objetos Razor precisassem ter extensões diferentes, .blazor para componentes do Blazor seria uma opção muito melhor.

Eu agradeço muito essa mudança! O nome “Componentes do Razor” sempre foi um pouco confuso porque a expectativa era de que isso fosse uma coisa puramente do lado do servidor, como tudo o mais que o Razor faz. Portanto, a expectativa era que os componentes do Razor fossem, como controles de usuário no WPF, uma maneira de compor componentes personalizados usando uma sintaxe do Razor em vez de código (como os auxiliares de tag permitem).

Ao renomear isso, essa confusão é removida e, na verdade, temos a chance de, eventualmente, criar componentes do Razor combináveis ​​do lado do servidor em algum ponto.

Quanto à extensão .razor , como outras, acredito que faria mais sentido usar .blazor . Pelo que entendi, esses arquivos podem conter código que só é viável dentro de um contexto Blazor, já que a lógica está profundamente acoplada ao componente. Não presumo que isso será possível reutilizar em um contexto não Blazor. Além disso, se os componentes do Blazor do lado do cliente acabarem usando a mesma coisa, acho que usar .blazor consistentemente é uma ideia melhor para identificar os componentes do Blazor (que podem ser usados ​​no lado do servidor ou no cliente) .

Eu sei que @poke e @duracellko mencionaram o termo componentes blazor de passagem, mas na verdade gosto disso como um nome. E sobre __Blazor Components__ em vez de __Blazor (lado do servidor) __?

Oh. e acho que .blazor para o nome da extensão também é uma boa ideia.

@myty Acho que conceitualmente, os componentes sempre foram “componentes do Blazor” (ou seja, você cria componentes com o Blazor). “Blazor (lado do servidor)” e “Blazor (lado do cliente)” são os dois modelos de hospedagem diferentes nos quais você pode consumir e executar os mesmos (eu acho?) Componentes do Blazor. Portanto, você usaria “componentes do Blazor” para descrever que está criando um componente e “Blazor do lado do servidor” para descrever como está executando os componentes do Blazor.

@myty Acho que conceitualmente, os componentes sempre foram “componentes do Blazor” (ou seja, você cria componentes com o Blazor). “Blazor (lado do servidor)” e “Blazor (lado do cliente)” são os dois modelos de hospedagem diferentes nos quais você pode consumir e executar os mesmos (eu acho?) Componentes do Blazor. Portanto, você usaria “componentes do Blazor” para descrever que está criando um componente e “Blazor do lado do servidor” para descrever como está executando os componentes do Blazor.

O fato de que sempre foram os componentes do Blazor foi o que me convenceu o nome. Diga como é e também soa bem. :)

... mas, também vejo a confusão entre o lado do servidor e o lado do cliente. É difícil contar a história sem mencioná-los especificamente.

Sim! Finalmente :) Blazor é o nome verdadeiro.

você ainda resplandece?

sim

Para mim Blazor = WASM.

Portanto, 'Razor Components' (SignarR!) É algo completamente diferente. Explicar a diferença é bastante fácil: Blazor é WASM.

NA MINHA HUMILDE OPINIÃO.

Esta é definitivamente a decisão certa. Mesmo depois que o novo termo "Componentes do Razor" foi introduzido, eu e meus colegas ainda nos referimos a ele como Blazor do lado do servidor. Também prefiro a extensão .blazor ou algo como .component. As visualizações em MVC também usam a sintaxe razor, portanto .razor traz mais confusão.

Eu acho que a mudança de nome para renomear Componentes do Razor de volta para Blazor é uma boa.

Eu realmente acho que a extensão do componente não deve ser .razor , pois é confuso ter 2 extensões diferentes representando arquivos razor. ( .cshtml e .razor )

Acho que .blazor ou .component extensões seriam uma alternativa melhor do que .razor .

Obrigado por fazer este nome mudar de volta para Blazor Server-Side . Estou aliviado para ser honesto. Eu tive um pequeno lolwut? momento em que ouvi pela primeira vez a mudança de nome para Razor Components .

Pessoalmente, acho que a palavra Razor é sobrecarregada o suficiente:

• Navalha
• Vistas de navalha
• Razor Pages
• Controladores de página do Razor
• Modelos de página do Razor
• Bibliotecas de classes do Razor
• Vistas parciais do Razor
• Componentes do Razor View
• : novo: Componentes do Razor: confused: //confusing much yet?
• Próximo recurso da família Razor : // just kidding :)

Já tornamos difícil para alguém novo tentar navegar por todas essas coisas do Razor junto com a tentativa de entender cada caso de uso.

Não apenas sentir empatia pelos novatos, mas imagine tentar explicar e manter o uso "correto" da terminologia em grandes equipes ao descrever e coordenar (como / quando / o que) usar.

Blazor é um bom nome, pois já nos associamos a seus casos de uso. Ei, mesmo Razor Sockets seria um nome melhor do que Razor Components . :oculos escuros:

Além disso, acho que renomear .razor para .blazor é uma boa ideia.

Nomear é difícil.
Mantenha as coisas simples.

-Brian :)

Ter interesse em Componentes do Razor porque ele funciona bem no meu projeto me levou até aqui.
Eu entendo do que estamos falando, mas alguém que está apenas começando pode estar confuso com o que está por baixo do capô, por causa da nomenclatura.
Se o objetivo é enviar Componentes do Razor apenas como um substituto temporário para o Blazor que está por vir, eu não gostaria que seu nome mudasse.

O Blazor do lado do servidor @Mitiko não será afetado pelas decisões sobre o Blazor do lado do cliente (baseado no WebAssembly). Supondo que o último seja lançado em algum ponto, você ainda poderá usar o Blazor do lado do servidor. Ambos os modelos de aplicativo serão capazes de compartilhar certas coisas, então faz mais sentido alinhá-las com seus nomes também.

É por isso que é no final das contas confuso. Quando você tem uma lógica que não se importa onde está hospedada, como é chamada? Em seguida, a estrutura muda magicamente os nomes com base no "shell" que você usa. Simplesmente não faz sentido ter dois nomes. Para o ponto de @poke , veja o vídeo abaixo: @Mitiko

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

E quanto ao modelo hospedado blazor?

@ghidello Fica como está. Portanto, haverá três modelos do Blazor: do lado do cliente autônomo, do ASP.NET Core hospedado e do lado do servidor

Fico feliz em ver isso, como você disse - o nome tem um significado e um impulso por trás dele e, para mim, transmite que os dois modelos estão avançando com um forte apoio.

IMO você também deve nomear o nome do modelo do componente para se referir ao Blazor, mesmo se você usar a sintaxe / mecanismo Razor. Isso apenas o tornaria uma solução de balcão único mais coesa, em termos de nomenclatura.

E quanto ao namespace de componentes? Ele também deve ser renomeado.

E os arquivos .razor devem ser .blazor, pois estão vinculados à tecnologia Blazor. Caso contrário, eles devem ser usados ​​para o Razor Mvc comum também.

Ainda um pouco confuso em relação aos componentes:

Portanto, se estou construindo uma biblioteca de componentes, que funciona tanto com o Blazor do lado do servidor quanto do lado do cliente, me refiro aos componentes como "componentes do Blazor" ou "componentes do Razor"?

@egil Com base no que Dan Roth disse acima, um componente ainda será conhecido como Componente Razor.

Ainda vamos nos referir ao modelo de componente como componentes do Razor (ou seja, um arquivo .razor ainda será um componente do Razor)

Adicionando meu voto de aprovação a esta mudança.

A meu ver, RazorComponent é um componente C # escrito usando a sintaxe do Razor e o código C #. Poderíamos usar RazorComponents em uma ampla gama de projetos, incluindo Blectron (como na demonstração do StorageExplorer), geradores de HTML (por exemplo, para geração de corpo de e-mail da mesma forma que RazorGenerator faz para .cshtml Conteúdo de Blazor .

Por outro lado, Blazor é a estrutura do aplicativo que usa RazorComponents no cliente, usando dois modelos de hospedagem diferentes (WebAssembly e do lado do servidor).

Eu adicionei um diagrama que mostra como eu vejo isso .. comentários bem-vindos

Blazor (lado do cliente com WASM) e Blazor (lado do servidor com .NET Core) parece ótimo!

Componentes do Razor para as interfaces de usuário de ambos, com o Blazor como framework para as aplicações independentemente do modelo de hospedagem. Simples, limpo e como diria um dos meus comediantes favoritos ... GIT R FEITO!

O cliente Blazor e o lado do servidor realmente soam bem.
E para iniciantes, é mais fácil entender as diferenças entre o lado do cliente e o lado do servidor.

Como já foi dito, há razões convincentes para considerar .blazor (e o nome do "componente Blazor"). Poderia haver mais lógica por trás de manter .razor (e seu nome "Componente Razor") ser compartilhada?

Este é o raciocínio até este ponto que pude encontrar:

Estamos planejando manter a extensão .razor para componentes. Os componentes são baseados na sintaxe do Razor, mas os componentes são tratados de maneira diferente pelo compilador do Razor, portanto, eles precisam de uma extensão de arquivo diferente.

Acho que minha visão pode ser muito 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);

Existem alguns motivos pelos quais preferimos manter a extensão .razor:

• O nome ainda é preciso e descritivo. Um arquivo .razor é um componente de UI escrito com a sintaxe Razor.
• Reduza a rotatividade. Atualizar a extensão do arquivo requer uma coordenação justa entre várias equipes e projetos. Como já fizemos esse trabalho para .razor, preferimos não fazê-lo novamente, a menos que haja um bom motivo para fazê-lo.
• Isole a estrutura do nome do produto ou mudanças de estratégia. Ao manter a nomenclatura do modelo de componente um pouco mais genérica, esperamos reduzir o impacto de qualquer possível embaralhamento de nomes ou mudanças na direção do projeto no futuro.

@ danroth27 O que me perturba é que a sintaxe do Razor está nos arquivos .cshtml e .razor. Acho que haverá confusão sobre qual extensão é para qual visualização de página / componente / MVC do Razor.

Outros dois pontos são bastante justos.

@ danroth27

O nome ainda é preciso e descritivo. Um arquivo .razor é um componente de UI escrito com a sintaxe Razor.

O que me incomoda sobre esse argumento é que um arquivo .razor contém coisas como manipuladores de eventos, métodos de ciclo de vida ou associações de variáveis. Esses conceitos são muito específicos para o Blazor e não funcionarão fora dele. Portanto, embora seja uma sintaxe do Razor, é um sabor muito específico que permite que a lógica do lado do cliente seja executada.

Essas coisas não funcionarão para "componentes Razor" puramente do lado do servidor e renderizados pelo servidor, o que poderia ser uma coisa hipotética no futuro (já que, por exemplo, fragmentos de renderização funcionariam muito bem no servidor também).

Portanto, estamos bloqueando a extensão do arquivo .razor e o nome “Componente do Razor” para um tipo específico do Razor que só funcionará para componentes com comportamento do lado do cliente embutido.

@ danroth27 Quase todo mundo (inclusive eu) está querendo .blazor vez de .razor então por que você está querendo manter .razor individualmente. Existe algum desafio técnico para mudar isso? ou apenas esta é a sua preferência e sua equipe?

Obrigada.

Como @ danroth27 mencionou a coordenação com várias equipes, posso pensar em equipe VS, equipe da equipe Razor, pode ser uma grande parte do trabalho em que cada equipe tem prioridades diferentes nas tarefas.

Eu posso ver a extensão .razor adequada se for uma coisa mais genérica que descreve qualquer tipo de componente escrito no Razor como .xaml é usado para recursos e controles no mundo do desktop.

Digamos que, se possível no futuro, você pudesse usar controles nativos UWP / xaml criados com navalha, não html via elétron, mas puramente nativos, já que o estilo imperativo do barbeador de construir controles pode ser uma alternativa atraente para .xaml's maneira declarativa atual de fazer as coisas (especialmente o suporte do razor para fluxos de controle C #).

No entanto, esse é um exemplo teórico. Nesse ponto, você poderia dizer que ele usa Razor Components, mas não está em um contexto Blazor, mas em um contexto nativo como React Native onde as coisas podem diferir como ligações de eventos sendo diferentes, alguns atributos específicos do Blazor não aplicáveis etc ...

Eu vejo o Blazor como um framework que usa Razor Components ( .razor ) como React como um framework usa .jsx/.tsx para composição de componentes e como .jsx/.tsx pode ser possível que seja utilizável em outras estruturas semelhantes, como Vue e TKO suportam .jsx/.tsx configurando o que o sistema de compilação faz para os arquivos .jsx/.tsx .

Obrigado a todos por seus comentários sobre este problema. A renomeação dos Componentes do Razor de volta para o Blazor do lado do servidor está concluída!

Decidimos deixar a extensão .razor como está pelos motivos listados acima . Recebemos uma mistura de comentários sobre esta decisão. Embora apreciemos o desejo de usar o Blazor em todas as coisas, achamos que a extensão atual é adequada e preferimos concentrar nossos esforços em deixar o Blazor pronto para o envio, em vez de agitar a extensão do arquivo. Dada essa decisão, prosseguirei e encerrarei este problema.

Renomeie o rótulo feature-Components para feature-Blazor também.

Queridos, estou usando o vs 2019, instalei a última versão do Blazor, tenho o core 3 preview 4, criei um projeto do Blazor, todas as páginas agora estão com extensão .razor em vez de .cshtml, executei o aplicativo, mas me dando Carregando ... sem ir para a página Index.razor, qualquer ajuda, por favor. Desde já, obrigado.

@ImadMichaelAyoub Você tem alguma mensagem de erro no console? Você está executando o Blazor do lado do cliente ou do lado do servidor?

Eu sugeriria que este provavelmente não é o melhor lugar para esta discussão. Provavelmente seria melhor entrar no canal Blazor Gitter (https://gitter.im/aspnet/Blazor) e podemos ajudá-lo com isso.

Obrigado pela resposta. Estou usando o Blazor do lado do cliente. Parece que o aplicativo executa o arquivo index.html em wwwroot e não se move para index.cshtml na pasta de páginas.

Eu sou novo em Razor e Blazor. É confuso quando você procura uma solução online, você obtém toneladas de navalhas ou coisas antigas que não se aplicam mais, adicionando mais confusão. Eu voto fortemente para mudar para o novo nome (até mesmo para .blazor) para que possamos pesquisar e obter o mais recente.

Estamos planejando manter a extensão .razor para componentes. Os componentes são baseados na sintaxe do Razor, mas os componentes são tratados de maneira diferente pelo compilador do Razor, portanto, eles precisam de uma extensão de arquivo diferente.

Isso significa - "Está planejado para manter a mesma extensão .razor .. mas, ele precisa de uma extensão diferente de .razor, mesmo que não seja planejado"?

"Grande tecnologia vem com uma grande confusão de nomes"