MudBlazor v7 Feedback #8976
Replies: 17 comments 31 replies
-
|
Really excited that we have such a precise and well written "migration" page. It looks a lot like what I would expect to find in Microsoft's documentation and is definitely the only reason that migrating is even an option at all for me considering the amount of breaking changes. Really amazing work from a lot of people <3. If I can allow myself to offer some thought and also play the devil's advocate at the same time : I am not sure what is the right answer for future breaking changes. I know Microsoft struggled a lot with the same problems and they ended up with the current .NET release format with STS between every LTS, a new "big" version once a year. I am not sure if it applies at all to MudBlazor but having matching versions with the .NET framework would definitely help. Upgrading Mud from v6.x to v8.x when also migrating .NET from 6.x to 8.x just makes sense, since that's already what we do with most packages anyway. On the other hand, waiting a year to see one's PR be published just to "follow Microsoft" would be really annoying. I felt the weight of waiting for 2 of my PR for nearly two years before they are finally here with version 7 and it sucked, specially since one of them was my first or second PR ever in this project and it wasn't the best feeling. I do like having a "preview" version like right now. I'd love to always have a |
Beta Was this translation helpful? Give feedback.
-
|
Following Microsoft doesn't work out for us as well, we abandoned that idea as it puts too much restrictions on us. |
Beta Was this translation helpful? Give feedback.
-
I understand why this can make sense for many .NET developers, but having a synchronous version with the .NET version imposes a lot of limitations on us. What if we want to release breaking changes more frequently? We would quickly fall out of sync, or we would have to increase the minor version, which might frustrate many users. There's also the situation where a new version of .NET is released, but we don't have any breaking changes. In that case, why should we increase the major version? I know that Microsoft increases the major version even if there wasn't a single line change (for libraries that do not require constant development), but I feel like this convention works well only for projects led by Microsoft, where this convention is understandable by everyone. However, I don't think it works as well for us, and it doesn't seem like many big 3rd-party libraries follow this either. Personally, I prefer to stick with Semantic Versioning (https://semver.org/), which we agreed upon with the community a while ago. Before, we had no conventions at all, and versioning had no rules, which caused a lot of confusion. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, it make sense! I was just trying to do devil's advocate and offer multiple paths. But like I mentioned it does suck to have to wait a really long time for a PR. I am not sure that we are using Semantic Versioning though since we keep having feature updates that only changes the "patch" version, which isn't Semantic Versioning : https://semver.org/#spec-item-6. v6.11.1 added something like 11 new features a couple months ago. It does look like newer Releases do it "properly" though, I hadn't realized! |
Beta Was this translation helpful? Give feedback.
-
You are right, that was a mistake on our side, and I do remember we discussed the 6.11.1 - 6.11.2 versions not following the SemVer. I'd say we are still learning 😃 |
Beta Was this translation helpful? Give feedback.
-
We tried to do that but we ended up getting lots of merge conflicts and it just wasn't manageable. So instead we'd go from v7 to v8 and to v9 within maybe a couple of months to merge a couple of breaking change PRs instead of waiting a year. It would of course mean more migration cycles but every time only a small change-set compared to the big one in v7 that lumped together breaking changes that accumulated over two years. If the majority of the community would prefer that we'd also prefer it because waiting a long time for breaking changes seriously hampers innovation for the dev team. |
Beta Was this translation helpful? Give feedback.
-
Assuming there would still be updates in between these couple months of breaking change update, Isn't that the exact same thing (git wise) as having a "main" in preview and a separate "non-preview" branch ? After a couple of months you'd still need to do a merge if I understand correctly. The only difference is in my story there was a package offered in preview as opposed to hidden for a couple months. Feel free to slap me if I misunderstand! 😄 I doubt any answer will be perfect sadly. I was thinking if the PR merged in the "stable" version are actually just small bugfixes they shouldn't be too much of a pain to merge. At work we kind of see it as the opposite : It's always an annoying play of "on which branch do I start", which very often results in most PR going to the "dev", or doing a "git rebase" on the right one afterward, like "branch out dev, PR to dev. Rebase on previous stable, PR to that one". Still no perfect answer! |
Beta Was this translation helpful? Give feedback.
-
|
We tried working on a v7 branch while keeping the v6 alive by merging it into v7 regularly but ended up having to resolve conflicts of PRs we didn't code or someone else in the team coded them. If I am the one merging and resolving I can't call any team member over to my desk and ask them how to resolve conflicts correctly and for random PR authors it is next to impossible. That's why we scrapped the concept and went back to a single dev branch. Maybe in the future we'll have less disruptive breaking changes as the library matures overall then it could probably work. |
Beta Was this translation helpful? Give feedback.
-
|
I would say it wasn't that regular, but it was manageable. However, eventually, it snowballed, mainly because v7 had some code removed, while in v6, it existed and was modified. And when you have a lot of conflicts and you are looking at this three-way comparison, you're like, "I think it's just easier to redo the PRs than fix the conflicts.", we still could do it if we really wanted, but can't be bothered. That's why the PRs that were already in v7 were redone in v6 (dev), and v6 (dev) turned into a branch for v7 😄 |
Beta Was this translation helpful? Give feedback.
-
|
I for one am very excited by this release and look forwarded to testing it on our application once out of preview. I do plan on making the switch if there are no showstoppers. Much thanks for the amazing framework!!! Since MS upended the world with SSR (which has it's place), I do have a question. Will v7 have tweaks/changes that better support SSR? (IE, replacing some native C# interactive code with JS where it might make sense to do so? I know this goes against the initial vision of MudBlazor being as native as possible). |
Beta Was this translation helpful? Give feedback.
-
This is a very complicated topic. What level of support do you expect for SSR (static)? What are the criteria that classify it as "working / supported" in SSR? Here are a few examples:
And so on.
As you mentioned, this goes against our philosophy. We don't plan to use JS more than necessary; otherwise, we end up like MatBlazor, and I don't think it would be Blazor anymore. SSR (static) means there is no interactivity, i.e., the native interactivity that Blazor offers won't work. In other words, you would need to replace it with JS because SSR only provides one render cycle per request, so anything after that, such as eventing DOM manipulation, etc., has to be done in JavaScript., which is too much rewrite for a small team of enthusiasts. Additionally, there are not many Blazor component libraries that flawlessly support SSR, except for those that simply wrap Bootstrap/JS components. This highlights how difficult it is to fully support SSR. So I'm afraid that decent SSR (static) support is not coming. But speaking of JS usage:
This is a little off-topic, but I think there is only one area where JS will do more heavy lifting, and it's the popover, because:
But that's one of the rarest exceptions where it's absolutely necessary.
Currently, we do not have any list of controls that support SSR (static). We have received a similar request in the past, and I believe we will consider it in the future. As for now, if I'm not mistaken, the template has an example of how you could mix SSR pages with interactive pages that use MudBlazor. However, the SSR pages use Bootstrap as it's just JS/CSS. But we will at least ensure that this scenario will work. Maybe @mikes-gh will contribute something to this topic later. |
Beta Was this translation helpful? Give feedback.
-
Thanks for your detailed reply and I completely understand. Retrofitting any Blazor apps/libraries to support SSR is tricky and feels limiting. In our app, the goal is to ensure that, when having a need for a SSR page, that the visual appearance matches the rest of our MudBlazor app. This, for the most part, already works as it should. Where I would like to see more support is perhaps on the basic form controls. I admittedly haven't spent much time with SSR yet, but I have found that many controls like buttons and text inputs work just fine. Others like checkboxes, radios, and selects, however, do not (again, there maybe workarounds I haven't explored yet). It's natural that highly interactive controls will not function, but perhaps focusing on the main form input controls so they work in SSR would be a laudable goal and a small enough surface area to be able to accomplish. (For example, like you have SimpleTable, you could have a SimpleSelect that uses a standard HTML select control that is styled correctly.) Dialogs would be next on my wish list for SSR (JS of course would be needed). I know there are likely workarounds and we can apply your CSS directly. Just some thoughts. I know the team is small and you have a lot of other priorities, but I'm hoping now that SSR is present, we'll see a lot of MVC developers move to Blazor and I am hoping that the excellent MudBlazor framework will benefit. :) |
Beta Was this translation helpful? Give feedback.
-
|
P.S. Just like to add choosing a framework is a daunting decision, as if you choose the wrong one, a critical piece of your own app can be compromised if it is not supported or functions poorly. |
Beta Was this translation helpful? Give feedback.
-
|
MudBlazor is developing exactly where a very small part of the community who cares to contribute drives it. The parts everyone demands but nobody cares to work on are never done. The current team probably won't be able to shoulder this additional burden. Everyone in the team already is on a mission of their own interest. It could be done if somone like you who needs the SSR compatibility joins the team and slowly crosses off one component after another. Anyone who wants to join efforts please let us know that you are interested to join the team and we'll happily welcome you. We just need a good PR that speaks for your skills. |
Beta Was this translation helpful? Give feedback.
-
|
Understood. Being an old guy raised in the world of MS and closed source, I personally have not directly contributed code to an OS project, so I am cautious that I would cause more harm than good. I don't want to waste anyone's time any more than I already am. ;) That said, I would love to and need to start investigating where I might be able to contribute. Again, I also hope to support financially when we can. Is it still a goal to hire a FT developer for MudBlazor? I'm guessing, like WinRAR, everyone uses MB, but no one contributes financially. Hopefully as Blazor grows, that will change as well. I would hope that MS invests (via grants or donations) in these OS projects that promote their ecosystem. |
Beta Was this translation helpful? Give feedback.
-
|
@Garderoben initially planned to start a company off MudBlazor hire devs and sell corporate licenses and support to pay for developers but I think these plans have been put aside a few years ago. We currently use donations to pay Azure hosting fees and the rest (i.e. the Github-Donation button) just goes to Garderoben directly. I think of it somehow as compensation for his initial efforts which were really incredible. Nobody invested as much time and energy than he did in the beginning. Now he is kind of inactive though. Others like me or Kuro who have spent a ton of time don't get any donations whatsoever but money is not what motivates us and we have our well paying jobs. Most other team members likewise. We never found a good way to split donations and reward contributors financially. It is somehow an impossible problem I don't know how to solve without quitting my dayjob which I don't want to do. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Doh, egg on my face. I am using both in our app and am testing both migrations/prereleases simultaneously. Apologies. I'll keep grinding on the conversion and post any issues I may encounter (to the correct project). ;) |
Beta Was this translation helpful? Give feedback.
-
|
I will say one of the frustrating things about Blazor (in general) and this migration is the component parameters that have been removed or renamed don't show up as errors/warnings at compile time in VS. IE MudList Clickable="true" is no longer a valid parameter, but VS doesn't warn of this at compilation. It does, however, have different syntax color coding, so it "knows". You simply get exceptions at runtime. If anyone has a solution for this, please share. :) Perhaps there is a way to enable warnings for this? |
Beta Was this translation helpful? Give feedback.
-
|
The |
Beta Was this translation helpful? Give feedback.
-
|
I would like to add that yesterday meziantou updated his analyzers to produce a warning if the component parameters are defined with "CaptureUnmatchedValues = true", as are many in UI frameworks to support HTML attributes. In the previous version, most MudBlazor components would not have caused a warning with a bad parameter. With the latest version, it will now issue warnings for bad parameters on MudBlazor components. :) This is critical for this conversion, as we have about 100 parameters we have to rename and now we have a map. :) I would humbly suggest recommending this analyzer in the migration guide, as it will be critical to clean up all the changed parameters. |
Beta Was this translation helpful? Give feedback.
-
|
Added, thanks for the tip! |
Beta Was this translation helpful? Give feedback.
-
|
Personally I love that all of this "cleanup" is happening. I use MudBlazor in my Job as well as my private projects and honestly prefer it over any commercial Blazor component library out there. I think I still wouldn't be able to write proper bUnit tests if I wasn't able to look at the tests from MudBlazor. I don't know if we will switch to v7 right away at work, but I will definitely do the switch ASAP for my private projects. I'm for frequent and smaller packs of breaking changes, as it is 1. less of a hassle to migrate and 2. IMO a huge motivation booster for the main contributors. My major gripe with MudBlazor since .Net8: SSR support I read the thread above and understand that the capacity for that is not there with the limited teamsize. I would like to contribute, but can't commit to doing every component that would be nice to have a "simple" SSR version of it. Is there a plan from the core team on how they would like to have this approached? |
Beta Was this translation helpful? Give feedback.
-
Even if you PR support for only a single component you'd be welcome to do so. Every little bit helps! |
Beta Was this translation helpful? Give feedback.
-
I completely agree. One has to balance compatibility with progress. Just have to be disciplined that when something is a breaking change, there is justification for it and it's not just a "preference/style" change. Having the ability to support items for a period of time with an obsolete flag is also great when possible, to help push people to change without breaking directly. Give yourselves and the community the freedom to innovate and evolve faster. :) No need to lock yourselves to past choices for years. With the simplicity of package management, one can stay with an older version when needed. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, Here are my two cents, as a beginner with only one MudBlazor project (based on a previous FluentUI project). Breaking Changes: Do you agree with the proposed breaking changes? How do you think they will impact your current projects or workflow? Exciting Features: Are there any features in v7 that particularly excite you? What improvements or additions do you look forward to the most? Migration Plans: Do you plan to migrate to v7 once it's released? If so, what factors are influencing your decision? Future Breaking Changes: How do you think breaking changes should be handled in the future? Should we opt for occasional massive changes with long stable periods in between, or would you prefer smaller breaks occurring more frequently, making migrations easier but potentially disruptive? Wishlist: Is there anything specific you'd like to see included in v7? Whether it's new functionalities, enhancements, or improvements to existing features, your suggestions are highly valued. Regards, |
Beta Was this translation helpful? Give feedback.
-
|
I also would much prefer more frequent smaller breaking changes. It's much easier to upgrade bit by bit than all at once. |
Beta Was this translation helpful? Give feedback.
-
|
Personally, I love change and support it. For a project to grow, we must have a strong base standard, and we are doing this right now. The feature I want to see the most is that the form element will be SSR-Friendly. We need it to work on a simple auth page like login/register, then redirect to the Interactive page. We can try:
That's all I have. Feel free to correct me, as I don't work much with the front end, so CSS is not my field. |
Beta Was this translation helpful? Give feedback.
-
If all you need is a login/register page in SSR static with controls that feel like MudBlazor, there is a great project called MudBlazor.StaticInput by @Anu6is. In my opinion, it covers all the needs for that. |
Beta Was this translation helpful? Give feedback.
-
|
With |
Beta Was this translation helpful? Give feedback.
-
|
Another icon font pack has been published: Material Icons. These are the same icons as the SVG ones in the core library, but they use the font instead. In the future, we might remove the SVG variant and replace it with this one, as the SVGs are heavier due to the amount of strings. |
Beta Was this translation helpful? Give feedback.
-
|
Love this! Seems like using this new Material Icons font library could easily replace the existing icons with a CSS include and a simple find and replace? Assuming this is the case and there are no issues with font vs SVG, I agree with full replacement. Also keeps the library smaller if people are not using them. Hopefully this makes it easier to maintain when new icons/symbols are added by google. :) |
Beta Was this translation helpful? Give feedback.
-
|
We will probably replace it in v8, though. The old parser was using old metadata JSON which, for example, doesn't contain "edit_document" for material icons. The new parser is using new metadata that contains both material icons and material symbols and is updated by google, but there is a chance the icon names can be different (old vs new metadata). Also, we already made a breaking change in icons in v7, and I don't want to do another one. The core library is using nested classes; the |
Beta Was this translation helpful? Give feedback.
-
|
Makes sense. Regardless, your work with these two repos is a great step in the right direction. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
As I run through my conversion, I noticed that a "Title" property was added to MudButton. Would it make sense to add it to MudLink for consistency ("title" works fine)? |
Beta Was this translation helpful? Give feedback.
-
|
Sure, please PR if you will |
Beta Was this translation helpful? Give feedback.
-
|
I think it's better to only add attribute properties if they benefit from it. I added |
Beta Was this translation helpful? Give feedback.
-
|
I posted my arguments in favor of such parameters here: #9098 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
FYI: It looks like the "Placement" property was removed from MudRadioGroup (Preview 4). I didn't see this listed in the migration guide (apologies if I missed it). |
Beta Was this translation helpful? Give feedback.
-
|
These should be reported directly in the migration guid issue instead of here please. |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
-
|
shall we report other issues here or somewhere else? I mean about v7.0.0 |
Beta Was this translation helpful? Give feedback.
-
|
If it's an actual issue you should create an issue |
Beta Was this translation helpful? Give feedback.
-
Dear Community,
We invite you to share your valuable insights and feedback regarding the ongoing development of v7.0.0. Your input is crucial in shaping the future direction of MudBlazor.
Please feel free to express your thoughts on various aspects such as the proposed breaking changes, features you're excited about, concerns you may have, and whether you plan to migrate to this version. Your feedback will help us gauge the community's sentiment and ensure that the upcoming release meets your expectations.
Here are some prompts to guide your feedback:
Breaking Changes: Do you agree with the proposed breaking changes? How do you think they will impact your current projects or workflow?
Exciting Features: Are there any features in v7 that particularly excite you? What improvements or additions do you look forward to the most?
Migration Plans: Do you plan to migrate to v7 once it's released? If so, what factors are influencing your decision?
Future Breaking Changes: How do you think breaking changes should be handled in the future? Should we opt for occasional massive changes with long stable periods in between, or would you prefer smaller breaks occurring more frequently, making migrations easier but potentially disruptive?
Wishlist: Is there anything specific you'd like to see included in v7? Whether it's new functionalities, enhancements, or improvements to existing features, your suggestions are highly valued.
Feel free to share any additional thoughts, questions, or concerns you may have. Your feedback plays a pivotal role in making MudBlazor better for everyone.
Thank you for being an integral part of our community.
Best regards,
MudBlazor Team
Beta Was this translation helpful? Give feedback.
All reactions