와… 이거 증말 장난 아니네요…
두어시간 하면 끝나겠지 하는 생각은 그냥 생각일뿐이었네요.
MudBlazor는 컴포넌트 자체가 blazor에 귀속된 형태다보니
이름도 MudText MudStack 으로 되어있는데…
이걸 단순히 span, div로 죄다 변경해줘야 하고 너무 손이 많이 가네요 ㄷㄷㄷ;;;
진짜 결합도 최고의 라이브러리입니다.
다신 안 쓸듯…
3 Likes
아이고 토닥토닥… 고생이 많으십니다.
Blazor 컴포넌트를 바꾸는 것이 꽤 큰 일일텐데… 다른 것이라 하면 어떤 것으로 변경하고 계시나요?
1 Like
아 그걸 안 적었네요…
Tabler로 바꾸고 있습니다! 
사용하는 것도 h1, h2, …, div, span 등등 그대로 다 쓰면서 class만 바꾸는데다
bootstrap을 기반으로 해서 커스터마이징된 디자인이 마음에 들더라고요.
순정 bootstrap을 쓰면 어디서 본 듯한 디자인인데,
tabler는 깔끔하게 튜닝된 느낌이랄까…
이것도 써보고 후기 남기겠습니다 
미리보기 웹페이지는 여기..
2 Likes
모두들 UI 라이브러리를 쓰면 처음엔 편하지만 이후에 분리할 때나 유지보수할 때 고생하더라구요. 그래서 많은 프론트엔드 개발자분들이 UI 라이브러리를 사용하되 나중에 어떻게 해야 쉽게 분리가 가능할지를 고민하시는데 이 때 headless UI pattern을 많이 적용하더라구요! Blazor에도 이러한 원리가 들어간 라이브러리가 나왔으면 좋겠습니다 
2 Likes
gpt 이용해 보시는건 어떨까요?
GPT는 어떤건가요? 검색을 해도 ChatGPT 밖에 나오질 않네요…
안그래도 정말 
고생중입니다…
Dialog까지도 연계되어 있다보니, 수정할 부분이 방대하네요;;;
암튼 뭐에 종속된다는건 상당히 무서운 것 같습니다.
한 가지 더 궁금한 점이 있습니다. 저 또한 MudBlazor를 회사 내부에서는 즐겨 쓰는 편이라 어떤 이유 때문에 전향? 하시게 되었는지 궁금하네요 ^^
1 Like
제가 디자인 커스터마이징에 대한 욕구가 커졌나봅니다…
바꾸려고하니 뭐가 잘 안되고, 마음에 안들고 그래서리…
솔직히 바꾸기로 마음 먹은게 잘한 결정인지 아직도 잘 모르겠어요 
1 Like
디자이너 퍼블리싱 해주는 시스템에
머드 쓰면 나중에 피봅니다
그럼 디자인 의존성이 큰 라이브러리는 백오피스 쪽에 써야 할것 같더군요
1 Like
길게 쓰고 있다가 지우고 다시 적고 있는데, 애초에 MudBlazor가 사용된 Blazor 소스를 Bootstrap 테마로 바꿔야 할 필요가 있다는 것 자체가 Blazor로 개발하면 안되는 웹서비스를 Blazor로 개발하고 있다는 뜻이기도 합니다.
Bootstrap 테마 + JS와 Blazor wasm + MudBlazor 모두 해본 입장에서 디자인이 중요한 경우에는 Blazor, 특히 Blazor wasm은 진짜로 생산성 떨어집니다. Bootstrap 테마 + JS에서는 소스고치고 새로고침하거나 브라우저 개발자 도구로 이리저리 막 실험하면서 만들 수 있지만 Blazor wasm의 핫리로드는 너무 느리고 부족합니다.
반대로, UI 컴포넌트가 매우 모듈화될 필요가 있으면서 복잡한 DataGrid로 가득 채워야 하는 경우 - 보통 LOB 쪽 화면이죠 - 에는 MudBlazor 상당히 괜찮다고 봅니다. 한 번 익숙해지면 기본 Blazor일 때보다 WPF나 WinForm 개발하는 느낌이 더 납니다. 솔직히 기존 오픈소스 Blazor UI 컴포넌트들이 죄다 커뮤니티 라이센스니 해서 상용화되어서 대안이 없어요.
특히 웹 개발에 익숙하지 않은 분들이 일단 시작하기에는 좋습니다. 다만, 기본 스타일을 고치려고 하기 시작하는 순간 고생이 시작되니 최소한으로 고쳐서 사용하시는 것이 정신 건강상 좋습니다. 즉, MudBlazor 데모 사이트 잘 보시고 이대로 써도 되겠다고 생각되는 경우가 아니면 MudBlazor와 Blazor 모두 피하세요~
뭐 좀 하다보니 MudBlazor나 Bootstrap이나 거기서 거기이고 MudBlazor의 기본 스타일도 CSS로 오버라이딩 좀 해주면 MudBlazor의 크고 광활한 여백이나 기본 폰트 크기도 어렵지 않게 변경이 가능하고 마치 WPF 개발하는 느낌도 좀 나고 그래서 좀 익숙해진 지금에는 나쁘지 않다고 봅니다.
하지만, 만약 새 프로젝트가 디자인이 매우 중요하고 별도의 웹 디자이너 / 퍼블리셔가 투입되는 프로젝트라면 저도 MudBlazor 사용 안 할 겁니다. 아니 애초에 Blazor wasm을 사용 안할 겁니다^^
1 Like
저는 이것 저것 해보다가 html + css 기반으로 접근했는데…
뭐가 좀 많이 귀찮네요… 아… 이래서 전문 디자이너가 있구나… 하는 탄복만 할 뿐입니다.
이것 저것 알아보다가 Fluent UI를 보고 있는데, 실무에서는 많이들 안쓰시는 것 같던데…
어떤가요?
저는 신규 프로젝트에 Radzen이랑 Mud 중 고민하다가 Radzen 쓸 예정인데… Mud 쓰는 분이 꽤 있으시네요ㅕ 혹시 Radzen은 어떤지 사용해 보신 분?
일단 저는 Blazor Server로 개발하고 있다는 점 말씀드립니다.
그리고 여러가지 주제에 걸쳐서 많은 이야기를 써주셔서 감사합니다.
저 또한 Blazor의 (핫)Reload기능은 느리고 즉각적이지 않으며, 때로는 코드 변경사항이 없다며 리로드를 거절당하는 버그에 당혹스럽기도 합니다…
물론 태생적으로, 매커니즘 자체가 Blazor는 다른 언어와 달라서 그럴수는 있겠으나, 어찌되었든 저장하고 새로고침만 해버리면(VS code에서는 새로고침도 할 필요없이) 바로 반영되는 언어도 있으니까 불편함이 느껴지는게 사실입니다.
그리고 컴포넌트들이 죄다 상용화되어 있거나, 다양하지 않다는 말씀에도 동의를 하는 편입니다ㅠㅠ
쓸만한 컴포넌트들의 선택지가 좁은 편인데, 그러다보니 커스터마이징의 러닝커브도 극복을 해야하는 편이구요…(제가 그러고 있습니다;
그리고 마지막으로 MudBlazor에 대해서 평가하신 부분에 대해서도 공감을 하는데요,
퍼블리셔가 별도로 있는 프로젝트에서는 사용 불가할듯 싶습니다.
일단 컴포넌트의 의존성이 상당히 올라가고요.
제가 변경중인 tabler의 경우에는 <div class=“foo bar” … 이런식으로 되어있는데,
tabler를 참조하지만 않으면 스타일이 적용 안되는 문제만 있을뿐, 컴파일이 불가능한 문제가 생기진 않습니다.
그렇기 때문에 MudBlazor를 사용함으로 해서 생기는 의존성과, 유지보수가 어려운 문제가 추후에 상당히 골치아파지겠다… 싶은 생각이 듭니다.
물론 모두가 한마음으로 MudBlazor를 애용하고 있으며, 팀의 방향 또한 그러하다면 최선의 선택지가 될 수도 있습니다.
뭐 이건 호불호의 문제도 크니까요… 쓰고 안 쓰고를 비난할 수가 없는 문제입니다.
다만, 범용으로 쓰기에는 무리가 있지않나… 싶은 생각이 드네요.
4 Likes