Aspnetcore: Razor 구성 요소의 이름을 서버 측 Blazor로 다시 바꿉니다.

승인된 결정입니까? 우리는 여전히 투표할 수 있습니까?

저는 개인적으로 이름 변경에 반대합니다. Razor Components가 더 나은 이름이라고 생각합니다. :(

@xclud 공개 포럼이므로 피드백은 언제나 환영입니다 😃

우리는 여전히 구성 요소 모델 을 Razor 구성 요소라고 부를 것이지만(즉, .razor 파일은 여전히 ​​Razor 구성 요소임), 애플리케이션 모델 에 대해 이야기할 때 다른 이름을 갖는 것이 매우 번거롭다는 것을 알게 됩니다. Blazor라는 이름 뒤에는 이미 상당한 추진력이 있으므로 계속 사용하고 싶습니다. 이름은 물론 주관적입니다. 우리가 어떤 이름을 선택하든 모든 사람이 만족할 수는 없지만 Blazor는 지금까지 우리에게 꽤 도움이 된 것 같습니다.

나는 이것이 좋은 움직임이라고 생각한다. Razor Components와 Blazor의 관계에 대한 혼란은 끝이 없습니다. 사람들은 렌더링 방식이 다를 뿐 아니라 프레임워크도 다르다고 생각했습니다.

게다가 제 개인적인 의견으로는 Blazor가 멋진 이름입니다.

사람들에게 Blazor에 대해 자주 이야기하는 사람으로서. Razor Components는 혼란에 불과했습니다. Blazor 앱은 Razor Components 앱이고, Razor Components는 [Razor Pages & Razor Class Libraries]와 관련되어 있으며, Razor/Blazor라고 말할 때 자기 자신에 걸려 넘어지는 면에서 혼란스럽습니다. 그것은 또한 Blazor에 대한 쓰기를 어렵게 만들고 SEO를 어렵게 만듭니다. 계속할 수 있습니다.

정신력이 우세합니다! 이 변경에 대해 대단히 감사합니다.

razor 페이지는 여전히 .cshtml이고 구성 요소는 .razor이므로 .blazor라고 부르는 것이 유리할 수 있으므로 .razor 파일 확장자는 어떻게 되었습니까? 아니면 면도기 페이지를 .cshtml 대신 .razor라고 부르시겠습니까?
상당히 혼란스러운 것들

우리는 구성 요소에 대한 .razor 확장자를 유지할 계획입니다. 구성 요소는 Razor 구문을 기반으로 하지만 구성 요소는 Razor 컴파일러에서 다르게 처리되므로 다른 파일 확장명이 필요합니다.

Blazor 호스팅 템플릿은 어떻습니까? 클라이언트 측 모델의 경우 가장 쉬운 방법은 다음과 같습니다.

• CSP 보안 헤더 적용
• SRI 해시 계산(이상적으로는 blazor.webassembly.js에서 직접 다운로드한 자산에도 필요함)
• 자산 압축(적어도 dll 파일이 내가 시도한 두 개의 CDN에 의해 ​​이미 압축된 wasm 콘텐츠 유형으로 배송될 때까지)

따라서 호스팅된 템플릿이 계속 존재하기를 바랍니다.

나는 또한 이 이름을 "Blazor"로 되돌리는 것을 좋아합니다. ATM에서 사람들과 Blazor 및 Razor 구성 요소에 대해 이야기하는 것은 단순한 혼란입니다.

Blazor는 (적어도) 두 개의 호스팅 모델이 있는 trchnology입니다. 그래서 저는 블레이저가 좋아요!

그들을 모두 다스리는 하나의 이름. 두 개의 서로 다른 호스팅 모델이 있는 하나의 Blazor가 확실히 더 좋습니다. 그것은 길을 따라 많은 혼란에서 구합니다.

이 변화를 환영합니다! 새(또는 이전) 이름 지정이 훨씬 덜 혼란스럽습니다.

파일 확장명도 .blazor 로 바꿔야 한다는 .cshtml 및 .razor 에는 모두 razor 구문이 있지만, .blazor 파일 확장자를 보다 정확하고 덜 모호한 IMHO로 만드는 Blazor 특정 코드는 하나만 있어야 합니다.

짧은 의견: 이름을 _Razor Components_에서 _Server-side Blazor_로 다시 변경하는 데 동의합니다.

긴 대답: 클라이언트 측 및 서버 측 "구성 요소"는 모두 Blazor, Razor 구성 요소, ASP.NET Core 구성 요소에 관계없이 동일한 이름을 가져야 한다고 생각합니다. 예를 들어 React와 React Native는 훨씬 더 다른 기술이지만 같은 이름을 공유합니다.

Blazor 이름의 이점 :

• 이미 커뮤니티에서 잘 알려진 이름입니다. 사실 브라우저에서 .NET을 실행하는 기술로도 이해되고 있는데 100% 맞는 것은 아닙니다.
• 사람들이 Blazor를 서버 측(실제로는 서버 측 없이)에서 .NET 없이 사용할 수 있다는 것을 받아들이거나 이해하는 것이 더 쉬울 수 있습니다.

Razor 구성 요소 이름의 장점:

• Razor 및 ASP.NET Core와 연결하면 사람들이 기술이 적절한 지원과 안정성을 갖게 될 것임을 이해하는 데 도움이 될 수 있습니다. Blazor는 이미 많은 주목을 받았지만 안정적인 기술로 이해되고 있다고 생각합니다.

그리고 확장과 관련하여 Razor 컴파일을 확장할 수 있는 방법에 따라 다릅니다. 예를 들어 앞으로 .razor 확장자를 사용하여 정적 생성된 Razore 페이지가 있고 컴파일러가 이를 처리할 수 있다면 .razor 확장자를 유지하겠습니다. 기본적으로 .xaml 확장자는 컨트롤, 페이지, 리소스, 응용 프로그램 개체에 사용됩니다.

나는 이것이 완벽하게 달성 가능해야 한다고 생각합니다. Razor 구성 요소에 대한 코드 숨김을 지원하는 현재 상태가 무엇인지 모르겠습니다. 그러나 코드 숨김이 있는 경우 구성 요소가 ComponentBase 또는 다른 항목에서 상속되는지 여부를 정의합니다. 그리고 이것은 .razor 파일을 컴파일하는 방법을 결정할 수 있습니다. 그리고 코드 비하인드가 없는 기본 상속은 ComponentBase이며 향후 기본 기본 클래스를 변경할 수 있습니다.

그러나 향후 Razor 개체가 다른 확장을 가져야 하는 경우 Blazor 구성 요소에 대해 .blazor 가 훨씬 더 나은 옵션이 될 것입니다.

나는 이 변화를 매우 환영한다! "Razor 구성 요소"라는 이름은 항상 약간 혼란스러웠습니다. Razor가 수행하는 다른 모든 작업과 마찬가지로 이것이 순전히 서버 측 작업일 것이라는 기대 때문이었습니다. 따라서 Razor 구성 요소는 WPF의 사용자 컨트롤과 유사하며 코드 대신 Razor 구문을 사용하여 사용자 지정 구성 요소를 구성하는 방법입니다(예: 태그 도우미가 허용함).

이름을 바꾸면 그 혼란이 제거되고 실제로 언젠가는 서버 측 구성 가능한 Razor 구성 요소를 생각해낼 기회가 생깁니다.

.razor 확장에 관해서는 다른 사람들과 마찬가지로 .blazor 대신 사용하는 것이 더 합리적이라고 생각합니다. 내가 이해하는 바에 따르면 이러한 파일에는 Blazor 컨텍스트 내에서만 실행 가능한 코드가 포함될 수 있습니다. 그 이유는 논리가 구성 요소와 깊이 연결되어 있기 때문입니다. 이것이 비 Blazor 컨텍스트에서 재사용할 수 있다고 가정하지 않습니다. 또한 클라이언트 측 Blazor 구성 요소가 동일한 것을 사용하게 된다면 지속적으로 .blazor 를 사용하는 것이 Blazor 구성 요소를 식별하는 더 좋은 아이디어라고 생각합니다(그런 다음 서버 측 또는 클라이언트 측에서 사용할 수 있음). .

@poke 와 @duracellko 가 전달하면서 blazor 구성 요소라는 용어를 언급한 것을 알고 있지만 실제로는 이름으로 그것을 좋아합니다. __Blazor(서버 측)__ 대신 __Blazor Components__는 어떻습니까?

오. 그리고 확장명에 .blazor 도 좋은 아이디어라고 생각합니다.

@myty 개념적으로 구성 요소는 항상 "Blazor 구성 요소"(즉, Blazor로 구성 요소를 만듭니다)라고 생각합니다. "Blazor(서버 측)"와 "Blazor(클라이언트 측)"는 동일한(제 생각에는?) Blazor 구성 요소를 사용하고 실행할 수 있는 두 가지 다른 호스팅 모델입니다. 따라서 "Blazor 구성 요소"를 사용하여 구성 요소를 만들고 있음을 설명하고 "서버 측 Blazor"를 사용하여 Blazor 구성 요소를 실행하는 방법을 설명합니다.

@myty 개념적으로 구성 요소는 항상 "Blazor 구성 요소"(즉, Blazor로 구성 요소를 만듭니다)라고 생각합니다. "Blazor(서버 측)"와 "Blazor(클라이언트 측)"는 동일한(제 생각에는?) Blazor 구성 요소를 사용하고 실행할 수 있는 두 가지 다른 호스팅 모델입니다. 따라서 "Blazor 구성 요소"를 사용하여 구성 요소를 만들고 있음을 설명하고 "서버 측 Blazor"를 사용하여 Blazor 구성 요소를 실행하는 방법을 설명합니다.

항상 Blazor 구성 요소라는 사실이 저를 이름에 매료시켰습니다. 있는 그대로 말해도 멋있게 들립니다. :)

...하지만 서버 측과 클라이언트 측 사이의 혼란도 봅니다. 특별히 그들을 부르지 않고는 이야기를 하기 어렵다.

예! 드디어 :) 블레이저가 본명입니다.

너도 타니?

예

나에게 Blazor = WASM.

따라서 'Razor Components'(SignarR!)는 완전히 다른 것입니다. 차이점을 설명하는 것은 간단합니다. Blazor는 WASM입니다.

임호.

이것은 확실히 올바른 결정입니다. 새로운 "Razor 구성 요소"라는 용어가 도입된 후에도 나와 내 동료는 여전히 이를 서버 측 Blazor라고 부릅니다. 나는 또한 .blazor 확장자나 .component와 같은 것을 선호합니다. MVC의 뷰도 razor 구문을 사용하므로 .razor는 추가적인 혼란을 야기합니다.

Razor 구성 요소의 이름을 다시 Blazor로 바꾸는 유턴이 좋은 것 같아요.

면도기 파일을 나타내는 2개의 다른 확장자를 갖는 것이 혼란스럽기 때문에 구성 요소 확장자가 .razor 되어서는 안 된다고 생각합니다. ( .cshtml 및 .razor )

.blazor 또는 .component 확장이 .razor 보다 더 나은 대안이라고 생각합니다.

이 이름을 Blazor Server-Side로 다시 변경해주셔서 감사합니다. 상당히 솔직해서 안심이 됩니다. 나는 작은 lolwut을 가지고 있었다? Razor Components 로 이름이 바뀌는 것을 처음 들었을 때.

개인적으로 Razor 라는 단어는 충분히 오버로드되었다고 생각합니다.

• 면도칼
• 면도날
• 면도기 페이지
• Razor 페이지 컨트롤러
• Razor 페이지 모델
• Razor 클래스 라이브러리
• 면도기 부분 보기
• Razor View 구성 요소
• :신규: Razor 구성 요소:혼란: //confusing much yet?
• 다음 Razor 제품군 기능: Razor 구성 요소 보기 // just kidding :)

우리는 이미 새로운 사람이 각 사용 사례를 이해하는 것과 함께 이러한 모든 Razor 기능 을 탐색하는 것을 어렵게 만들었습니다.

초보자에 대한 공감을 느낄 뿐만 아니라 대규모 팀에 대해 설명하고 사용할 때(어떻게/언제/무엇을) 조정할 때 "올바른" 용어 사용을 설명하고 유지하려고 한다고 상상해 보세요.

Blazor는 이미 사용 사례와 연관되기 때문에 좋은 이름입니다. Yo, Razor Sockets 도 Razor Components 보다 더 나은 이름이었을 것입니다. :색안경:

또한 .razor 를 .blazor 로 변경하는 것이 좋습니다.

네이밍은 어렵습니다.
일을 단순하게 유지하십시오.

-브라이언 :)

Razor 구성 요소가 내 프로젝트에서 잘 작동하기 때문에 관심을 갖고 여기까지 왔습니다.
나는 우리가 무슨 말을 하는지 이해하지만 이제 막 시작하는 사람은 이름 때문에 내부에 무엇이 있는지 혼동할 수 있습니다.
목표가 곧 출시될 Blazor의 임시 대체품으로 Razor 구성 요소를 배송하는 것이라면 이름을 변경하고 싶지 않습니다.

@Mitiko 서버 측 Blazor는 클라이언트 측 Blazor(WebAssembly 기반)에 대한 결정의 영향을 받지 않습니다. 후자가 어느 시점에 출시된다고 가정하면 서버 측 Blazor를 계속 사용할 수 있습니다. 두 응용 프로그램 모델은 실제로 특정 항목을 공유할 수 있으므로 이름과 함께 정렬하는 것이 더 합리적입니다.

이것이 궁극적으로 혼란스러운 이유입니다. 호스팅되는 위치에 상관하지 않는 논리가 있는 경우 이를 무엇이라고 합니까? 그런 다음 프레임워크는 사용하는 "쉘"에 따라 이름을 마술처럼 변경합니다. 이름이 두 개라는 것은 의미가 없습니다. @poke 의 요점은 아래 비디오를 참조하십시오: @Mitiko

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

Blazor 호스팅 템플릿은 어떻습니까?

@ghidello 그대로 유지됩니다. 따라서 독립 실행형 클라이언트 측, ASP.NET Core 호스팅 및 서버 측의 세 가지 Blazor 템플릿이 있습니다.

이렇게 보니 반갑습니다. 말씀하신 대로 이름에는 의미와 추진력이 있으며 두 모델 모두 강력한 지원을 받으며 앞으로 나아가고 있다는 의미가 담겨 있습니다.

IMO에서는 Razor 구문/엔진을 사용하는 경우에도 Blazor를 참조하도록 구성 요소 모델 이름도 지정해야 합니다. 현명한 명명으로 더 응집력 있는 원스톱 샵 솔루션이 될 것입니다.

컴포넌트 네임스페이스는 어떻습니까? 이름도 바꿔야 합니다.

그리고 .razor 파일은 Blazor 기술과 연결되어 있으므로 .blazor여야 합니다. 그렇지 않으면 일반적인 Razor Mvc에도 사용해야 합니다.

구성 요소와 관련하여 여전히 약간 혼란 스럽습니다.

따라서 서버 측 및 클라이언트 측 Blazor 모두에서 작동하는 구성 요소 라이브러리를 구축하는 경우 구성 요소를 "Blazor 구성 요소" 또는 "Razor 구성 요소"라고 합니까?

@egil 위에서 Dan Roth가 말한

우리는 여전히 구성 요소 모델을 Razor 구성 요소로 참조할 것입니다(예: .razor 파일은 여전히 ​​Razor 구성 요소임).

이 변경 사항에 찬성 투표를 추가합니다.

내가 보기에 RazorComponent 는 Razor 구문과 C# 코드를 사용하여 작성된 C# 구성 요소입니다. Blectron (StorageExplorer 데모에서와 같이), HTML 생성기(예: RazorGenerator 가 .cshtml 대해 수행하는 것과 동일한 방식으로 이메일 본문 생성용)를 비롯한 다양한 프로젝트에서 RazorComponents 를 사용할 수 있습니다 .cshtml 콘텐츠입니다. Blazor 에만 국한되지 않습니다.

대조적으로 Blazor 는 두 가지 다른 호스팅 모델(WebAssembly 및 서버 측)을 사용하여 클라이언트에서 RazorComponents 를 사용하는 애플리케이션 프레임워크입니다.

내가 보는 방법을 보여주는 다이어그램을 추가했습니다. 댓글 환영

Blazor(클라이언트 측 w/WASM) 및 Blazor(서버 측 w/.NET Core)는 훌륭합니다!

호스팅 모델에 관계없이 애플리케이션의 프레임워크로 Blazor를 사용하는 두 가지 UI용 Razor 구성 요소. 단순하고 깨끗하며 내가 가장 좋아하는 코미디언 중 한 명이 말했듯이 .... GIT R DONE!

Blazor 클라이언트와 서버 측의 소리는 정말 좋습니다.
그리고 초보자에게는 클라이언트 측과 서버 측의 차이점을 더 쉽게 이해할 수 있습니다.

다른 사람들이 말했듯이 .blazor (및 "Blazor 구성 요소" 이름)를 고려해야 하는 강력한 이유가 있습니다. .razor (및 "Razor 구성 요소" 이름)을 유지하는 더 많은 근거를 공유할 수 있습니까?

이것은 내가 찾을 수있는이 시점까지의 근거입니다.

우리는 구성 요소에 대한 .razor 확장자를 유지할 계획입니다. 구성 요소는 Razor 구문을 기반으로 하지만 구성 요소는 Razor 컴파일러에서 다르게 처리되므로 다른 파일 확장명이 필요합니다.

내 견해가 너무 단순하다고 생각합니다.

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

.razor 확장자를 유지하려는 몇 가지 이유가 있습니다.

• 이름은 여전히 ​​정확하고 설명적입니다. .razor 파일은 Razor 구문으로 작성된 UI 구성 요소입니다.
• 이탈을 줄입니다. 파일 확장자를 업데이트하려면 여러 팀과 프로젝트에서 상당한 양의 조정이 필요합니다. 우리는 이미 .razor에 대해 이 작업을 수행했으므로 정말 좋은 이유가 없는 한 다시는 이 작업을 수행하지 않는 것이 좋습니다.
• 제품 이름이나 전략 변경으로부터 프레임워크를 격리합니다. 구성 요소 모델의 이름을 좀 더 일반적으로 유지하여 잠재적인 이름 섞기 또는 향후 프로젝트 방향 변경의 영향을 줄이기를 바랍니다.

@danroth27 나를 방해하는 것은 Razor 구문이 .cshtml과 .razor 파일 모두에 있다는 것입니다. 어떤 확장이 어떤 Razor Page/Component/MVC 보기에 대한 것인지 혼란이 있을 것이라고 생각합니다.

다른 두 가지 점은 충분히 공정합니다.

@danroth27

이름은 여전히 ​​정확하고 설명적입니다. .razor 파일은 Razor 구문으로 작성된 UI 구성 요소입니다.

이 인수에서 나를 괴롭히는 것은 .razor 파일에 이벤트 처리기, 수명 주기 메서드 또는 변수 바인딩과 같은 항목이 포함되어 있다는 것입니다. 이러한 개념은 Blazor에만 해당되며 외부에서는 작동하지 않습니다. 따라서 Razor 구문이지만 클라이언트 측 논리를 실행할 수 있도록 하는 것은 매우 구체적인 특징입니다.

이러한 것들은 순전히 서버 측 및 서버 렌더링 "Razor 구성 요소"에는 작동하지 않습니다. 이는 미래에 가상의 일이 될 수 있습니다(예를 들어 렌더 조각이 서버에서도 꽤 잘 작동할 것이기 때문입니다).

따라서 클라이언트 측 동작이 포함된 구성 요소에서만 작동하는 특정 Razor 버전에 대해 파일 확장자 .razor 와 이름 "Razor 구성 요소"를 잠급니다.

@ (나를 포함) .blazor 를 대신 .razor 왜 당신이에 충실하고자하는 .razor 개별적으로. 이를 변경하는 데 기술적인 문제가 있습니까? 아니면 이것이 당신과 당신의 팀 선호 사항입니까?

감사합니다.

@danroth27 이 여러 팀과의 조정에

.xaml 가 데스크톱 세계에서 리소스와 컨트롤 모두에 사용되는 방식과 같이 Razor로 작성된 모든 종류의 구성 요소를 설명하는 보다 일반적인 것이면 .razor 확장이 적합함을 알 수 있습니다.

네이티브 사용할 수있는 미래에 가능하면 말 UWP / xaml , 면도기을하지 사용하여 작성한 컨트롤을 html 에 대한 강력한 대안이 될 수있는 컨트롤을 구성하는 면도기의 필수 스타일로, 전자를 통해하지만, 순수 네이티브 .xaml's 현재의 선언적 작업 방식(특히 C# 제어 흐름에 대한 razor의 지원).

그것은 이론적 인 예입니다. 그 시점에서 Razor 구성 요소를 사용하지만 Blazor 컨텍스트가 아니라 React Native와 같은 기본 컨텍스트에 있다고 말할 수 있습니다. 등...

나는 Blazor를 Razor Components( .razor )를 사용하는 프레임워크로 보고 있습니다. 예를 들어 React가 구성 요소 구성에 .jsx/.tsx 를 사용하고 .jsx/.tsx 와 같이 다음과 같이 가능할 수도 있습니다. Vue 및 TKO가 .jsx/.tsx 파일에 대해 빌드 시스템이 수행하는 작업을 구성하여 .jsx/.tsx 를 지원하는 방식과 같은 다른 유사한 프레임워크에서 사용할 수 있습니다.

이 문제에 대한 의견을 보내주신 모든 분들께 감사드립니다. 서버 측 Blazor로 다시 이름을 바꾸는 Razor 구성 요소가 완료되었습니다!

위에 나열된 이유로 .razor 확장자를 그대로 두기로 결정했습니다. 우리는 이 결정에 대해 다양한 피드백을 받았습니다. 모든 것을 Blazor에 대한 열망에 감사하지만 현재 확장자가 적절하다고 생각하며 파일 확장자를 휘젓는 대신 Blazor를 출시할 준비를 하는 데 노력을 집중하는 것을 선호합니다. 이 결정을 바탕으로 이 문제를 종료하고 진행하겠습니다.

레이블 feature-Components도 feature-Blazor로 이름을 바꾸십시오.

친애하는 여러분, 저는 vs 2019를 사용하고 있습니다. 저는 Blazor 마지막 ​​버전을 설치했습니다. 저는 코어 3 프리뷰 4가 있습니다. 저는 Blazor 프로젝트를 생성했습니다. 이제 모든 페이지는 .cshtml 대신 .razor 확장자를 사용합니다. 응용 프로그램을 실행했지만 저에게 로드 중... Index.razor 페이지로 이동하지 않고 도움이 필요합니다. 미리 감사드립니다.

@ImadMichaelAyoub 콘솔에 오류 메시지가 있습니까? 클라이언트 측 또는 서버 측 Blazor를 실행 중입니까?

나는 이것이 아마도 이 토론을 위한 최적의 장소가 아니라고 제안하고 싶습니다. 아마도 Blazor Gitter 채널(https://gitter.im/aspnet/Blazor)에 가입하는 것이 가장 좋을 것입니다. 그곳에서 저희가 도와드릴 수 있습니다.

답장을 보내 주셔서 감사합니다. 클라이언트 측 Blazor를 사용하고 있습니다. 응용 프로그램이 wwwroot에서 index.html 파일을 실행하고 페이지 폴더의 index.cshtml로 이동하지 않는 것 같습니다.

저는 Razor와 Blazor를 처음 사용합니다. 온라인에서 솔루션을 검색할 때 혼란스럽습니다. 더 이상 적용되지 않는 면도기나 오래된 물건을 많이 얻게 되어 혼란이 더 가중됩니다. 나는 우리가 최신 이름을 검색하고 얻을 수 있도록 새 이름(심지어 .blazor까지)으로 변경하는 데 적극 찬성합니다.

우리는 구성 요소에 대한 .razor 확장자를 유지할 계획입니다. 구성 요소는 Razor 구문을 기반으로 하지만 구성 요소는 Razor 컴파일러에서 다르게 처리되므로 다른 파일 확장명이 필요합니다.

이것은 "동일한 .razor 확장자를 유지할 계획입니다. 그러나 계획되지 않은 경우에도 .razor와 다른 확장자가 필요합니다."를 의미합니까?

"위대한 기술에는 이름의 혼란이 따른다"