Following Microsoft doesn't work out for us as well, we abandoned that idea as it puts too much restrictions on us.

having matching versions with the .NET framework would definitely help

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.

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!

v6.11.1 added something like 11 new features a couple months ago. It does look like newer Releases do it "properly" though

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 😃

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.

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 😄

Will v7 have tweaks/changes that better support SSR?

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:

1. Working completely without any side effects or loss of functionality.
2. Works with reduced functionality.

And so on.

I know this goes against the initial vision of MudBlazor being as native as possible.

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:

JS where it might make sense to do so.

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:

1. It's impossible to avoid JS when it comes to popovers. I know the Popover API in HTML recently came out, but there are still some things that browsers do not support, so it will take time until this is completely polished. There are a few challenges as well to use it, however in the far future, if everything goes well with this API, we might have dialogs, tooltips, and popovers that work in SSR.
2. Our popover JS side is buggy, and nobody wants to maintain it, so it would make sense to use a third-party JS library instead.
3. Popovers are complicated and one of the most important things in the framework. It may sound funny, but some popover JS libraries like popper.js have more downloads than the Vue framework.

But that's one of the rarest exceptions where it's absolutely necessary.

Is there official guidance on what level of support (if any) MudBlazor has for SSR? Perhaps listing what render modes a control supports in the docs?

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.

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.
I have to say, when I moved to new position at a startup and decided to build our application in Blazor and MudBlazor, it was a tough/scary choice (spent over a month evaluating may platforms and frameworks). I can easily say that we made the right choice with both platforms. MudBlazor is fantastic and I feel it is supported and works better than many commercial frameworks I've used in the past.
Looking forward when our startup succeeds, and we can contribute more financially to MudBlazor's success.

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.

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.

@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.

MudPasswordField is not part of MudBlazor, it belongs to the CodeBeam.MudBlazor.Extensions. The author of this extension needs to update their code to use the v7 API. Since there are breaking changes, such errors are common when a 3rd party is using an older version of the library.

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

The Meziantou.Analyzer can detect unknown component parameters. We also have illegal parameter detection, and Clickable is on the list. However, it will only throw an exception during runtime when the component is used. Nonetheless, it's better than nothing.

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.

Added, thanks for the tip!

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.

Even if you PR support for only a single component you'd be welcome to do so. Every little bit helps!

We need it to work on a simple auth page like login/register, then redirect to the Interactive page

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.

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.

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. :)

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 Filling class is inside the Material class, which is inside the Icons class, while in the new icon packs I just use namespaces instead. This is already a breaking change. Nesting is bad because if you have both+ libraries with the root class "Icons" within the same MudBlazor namespace, you will get a compiler error, meaning you can't extend it and are forced to come up with another name. This would become ugly with more icon support. However, you don't have the same problem with namespaces.

Makes sense. Regardless, your work with these two repos is a great step in the right direction. Thanks!

Sure, please PR if you will

I think it's better to only add attribute properties if they benefit from it. I added Title to the base for consistency among buttons and to avoid the icon issues fixed in Fab and IconButton, but now that I'm looking at it again I believe none it's not even necessary after the root issue was fixed (see #4280 for example). These properties should probably be removed in fact before v7 ships.

I posted my arguments in favor of such parameters here: #9098 (comment)

I understand your question.

However, I don't think I can give a simple yes or no answer. After all, I'm not the tech lead of MudBlazor, and I can't definitively say what direction MudBlazor will take. MudBlazor has maintained backward compatibility for almost three years. The only major exception I can think of is the DataGrid, which changed frequently but was marked as experimental.
In the past 1.5 years, I have ensured that MudBlazor remains API/ABI compatible. We had many services that duplicated each other and numerous obsolete APIs. While maintaining backward compatibility is possible, it stifles innovation. Many PRs stalled for years because they introduced breaking changes, which is detrimental to an open-source project. I could definitely feel the moment when current contributors started losing interest and new people hesitated to join because maintaining the same codebase for years is unappealing. People want to innovate.

So, my personal opinion, not as a MudBlazor member, is that MudBlazor wasn't meant to be a platform stable for 20 years like some enterprise solutions (BizTalk). If MudBlazor had an enterprise license, the situation would be different. It would be the direct responsibility of MudBlazor to maintain backward compatibility for enterprise users because that’s what they are paying for.

To me personally, the frontend is such a fast-paced field that maintaining backward compatibility for a long time is not feasible (I don't think it's correct to compare it with browsers or Photoshop), especially for an open-source product due to resource constraints. Even major projects backed by companies like Facebook cannot always maintain backward compatibility. The number of times React has been overhauled is countless. The same goes for Angular—Angular 1 lasted for 10 years, but eventually, its lifecycle ended, and many projects will never migrate to Angular 2.
https://www.youtube.com/shorts/aXcuz6fn8_w?feature=share
This video sums up what happening in the frontend world.

Blazor is still a very young technology—only five years have passed since its creation. When MudBlazor was developed, everything was new, and mistakes were made. While MudBlazor is ready for production, if you are an enterprise company planning to use it for at least ten years, it may not be quite there yet. MudBlazor still needs more time to reach the level of polish required for long-term, enterprise-level stability.
Sorry, the message is a bit cumbersome, please take it as a stream of my thoughts.

I'm not the tech lead of MudBlazor

Understatement ;). OK, "not the sole tech lead" would be correct.

In the past 1.5 years, I have ensured that MudBlazor remains API/ABI compatible. We had many services that duplicated each other and numerous obsolete APIs. While maintaining backward compatibility is possible, it stifles innovation.

I forgot to add that it doesn't mean we won't continue to do it. If we see that the new popover system can coexist with the old one, we will do so. We will always try to find a way to make things backward compatible (if possible), it's just that it won't be supported for as long as 5 years+, but rather for 1-3 years at most.

Btw, the only problem we face is that we can't deprecate components. We would like to but it is just not possible. We'd have to go from MudSelect to Mud7Select to Mud8Select.

That was one of my earlier ideas, and I even proposed that idea in discord with the more fancy name MudSelectX (as example). This component would initially be experimental, then stable, eventually marking MudSelect as obsolete. In the next major version, we would remove the old MudSelect and rename MudSelectX back to MudSelect. This approach would provide time for users to migrate.

I don't believe we should repeat what we did in v7 with the TreeView, where we rewrote it and removed the old version in a major release. Even though breaking changes are acceptable in major versions, we gave users no time to migrate, forcing them to immediately adjust to new TreeView if they want to use v7, this is not some property rename but a component rewrite.

A better strategy would be either to introduce the updated component in the previous major version, retaining both the old and new versions, and deprecating(removing) the old one in the subsequent major release. Alternatively, if the update occurs during the next major version, we should still maintain both versions and remove the old one in the major release after that. Otherwise, it's a bit too abrupt.

<MudSelect Version="Version.V8"/>

This is unfortunately not possible.

Thank you, everyone, for your insightful feedback. We thoroughly evaluated various UI frameworks and championed MudBlazor because we admire your team's dedication and the project's grassroots ethos. I appreciate your commitment to innovation despite resource constraints. I valued the statement on the MudBlazor website about pushing forward and committing to the project. I respect that you're doing it for the sake of doing it. It was my-bad for not considering the implications of the major release-breaking changes - albeit, this is a rare occurrence from your feedback. Thank you for the reinforcement.

Reflecting on your responses, here are the key takeaways:

• Our use-case with plugins is somewhat unique, though enterprise scenarios would likely share similar challenges with large-scale implementations.
• It was noted (and henon hates apple ;) ) that breaking changes, while necessary for framework maturity, can pose challenges, and another major revision is anticipated in the future.
• There's consideration for versioning components to maintain backward compatibility.

We're heavily invested in MudBlazor, having built over 1,000 components over 10 months of development. Our team finds MudBlazor preferable to other frameworks we've explored internally. This framework is integral to our platform, empowering users across education, SMEs, and DIY/maker communities - groups I hold in high regard. Our platform product also enables users to design custom UIs with MudBlazor programmatically and through code, resulting in significant exposure for MudBlazor.

We're confident in continuing to use MudBlazor with your responsive communication and willingness to engage deeply with our worries. Your insights into our specific challenges and thoughtful consideration of our questions reinforce our decision.

Thank you all once again for your contributions!
DJ

• Wishlist : Complete project Add Nullable annotation support in MudBlazor, in particular the Select and Autocomplete components.

This will be completed. The end goal is to enable Nullable globally. The issue with the input components is that we want to rework them first before applying nullable annotations.

https://v6.mudblazor.com

@danielchalmers could this be a side-effect of

MudDialog: Fix content not stretched in fullscreen mode by @danielchalmers in #8743

@Kenoobie Could you submit a bug report issue with more details including what it should look like?

Done. #9332

Hi.

Error: One or more errors occurred. (VTable setup of type MudBlazor.Extensions.Services.MudExDialogService failed)
at Jn (marshal-to-js.ts:349:18)
at Tl (marshal-to-js.ts:306:28)
at 00b21cf6:0x1fad7
at 00b21cf6:0x1bf9f
at 00b21cf6:0xf16c
at 00b21cf6:0x1e7f1
at 00b21cf6:0x1efe7
at 00b21cf6:0xcfbc
at 00b21cf6:0x44213
at Go (scheduling.ts:47:16)

I don't think we can help you here, you seems to be using a 3rd party library. We don't have MudBlazor.Extensions.Services.MudExDialogService. Please, contact the library author.

@reengineeringdevops , I've made that same mistake when testing v7 RCs. ;)

If have no issues with MudExtensions v7 RC1 code and MB v7.2 together. You can access it by enabling prereleases on NuGet. I believe they should be releasing their v7 update this week.

Please create an issue with a minimal reproduction in try.mudblazor.com (please strip away EFcore dependencies and other complicated app logic). Otherwise I'll not be able to help you. You can tag me in the issue so I get notified of it.

I guess you mean parameter SearchFunc which is of type Func<string, CancellationToken, Task<IEnumerable<T>>>. I think it is not possible to have a default value in a func definition.

Also, the SearchAsync method you are talking about seems to be defined in your code (to be passed to SearchFunc), so you can simply ignore the cancellation token that is passed to you.

Yeah, it's not possible define a default in a Func / Action, you can simply to ignore the CancellationToken as it was mentioned.