-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move Blazor endpoints source generation into Razor compiler #48767
Comments
Thinking about this more, I don't quite see how it could work. We don't require people to use the Razor compiler to author their page components, so what happens for people who implement a component in plain |
@SteveSandersonMS it gets picked up anyways. The only thing that putting this logic in the compiler does is ensure we can "see" the If you are asking what happens if someone disables the razor source generator, then you don't get discovery and don't get auto detection of render modes. You can manually write the code to produce the same outcome as the source generator. |
Right yes, there's nothing stopping it from discovering all component types regardless of whether they were originally implemented as
Not really, I don't think we have to worry about that. |
@javiercn @mkArtakMSFT Am I right to think we could push this out for now? AFAIK the reflection-based page discovery is already working fine and customers won't see any particular benefit from switching to a sourcegenerator-based one for .NET 8, since it doesn't support any broader thing that may require it (e.g., AOT). And for rendermodes, it's better to do that based on which DI services are registered as that will be simpler and more reliable (e.g., will work with callsite rendermodes too). If that's the case it would definitely be good to focus our efforts on the essential things that we must ship first. |
The .NET 8 feature I was most looking forward to using was Blazor United but unfortunately for us each microservice defines its own razor class library each containing several routable components. This slipping to .NET 9 means we dont get to use the new feature until 9/2024 at the earliest which is disappointing to say the least. |
@buvinghausen Is your requirement simply to have routable components spread across multiple class libraries? If so that's fine and is supported in .NET 8. We didn't cut the feature; we just changed how it was implemented. |
@SteveSandersonMS thanks for the clarification |
@SteveSandersonMS - could you please clarify the final decision/API to map razorcomponents from multiple web assemblies? I looked at all the related posts but couldn't find what was implemented. My apologies if I missed but it seems that it still supports only one class library. Is there any support planned to have functionality similar to the additional assemblies parameter like before? To clarify, I am looking for routing components to be spread over various libraries. |
@darena-pjindal as far as I know the functionality is not available in preview 7 I have a very slimmed down project that I will test RC1 on when it drops next week. Fingers crossed it is available because I really want to use the new hosting model but not being able to have microservices define routes is definitely a deal breaker. |
Thanks @buvinghausen . I was confused by the reply above and many related posts that mentioned an "Api" to do that. |
@darena-pjindal I just downloaded RC1 and it appears they added an extension method I don't have time this week but I will try to port our running main application over to .NET 8 RC1 this weekend with the new Blazor hosting mode and see if I lose much in the way of limbs/blood and will report back ;-) |
Thanks so much, @buvinghausen. i also just saw the you tube stream and was getting ready to try it out. I will try it out right away. Exciting stuff! |
One thing I did notice in my extremely cursory testing since it appears the App.razor Router is basically ignored is the NotFound experience returns back a generic message I also see a new Good luck on the path |
Tested on RC-1, the following extension makes this work again! app.MapRazorComponents<App>()
.AddAdditionalAssemblies(typeof(MainLayout).Assembly); |
Thanks for contacting us. We're moving this issue to the |
Closing as a dupe of #46980 |
@javiercn You mentioned this work yesterday. Could you fill in details?
Also, in terms of ordering the work, am I right to believe we could schedule this pretty late, since if we don't make it then the reflection-based approach will work anyway and the sourcegen can be slotted in any time nonbreakingly?
The text was updated successfully, but these errors were encountered: