I'm trying to use the component in my CSHTML view (existing MVC app):
@(await Html.RenderComponentAsync<NewJobComponent>(RenderMode.ServerPrerendered, new { Job = Model }))
I understand why, but what's the alternative in order to pass anything to the component? Since I cannot do the following in my CSHTML file:
<NewJobComponent Job="Model" />
Thanks for contacting us.
We currently have no support for this. We will park this issue in the backlog to collect more feedback from community.
The only way I've found for now is parsing a URL like http://sitename/blazorcomponent?myparam=123 this way:
@inject NavigationManager navMan;
..
protected override void OnParametersSet()
{
var uri = new Uri(navMan.Uri);
string myparamStr= Microsoft.AspNetCore.WebUtilities.QueryHelpers.ParseQuery(uri.Query).TryGetValue("myparam", out var myparam) ? myparam.First() : "";
}
We have a scenario where we plan to progressively transition our CMS application from MVC to use mostly Razor components. One of our use cases is a FormComponent that our CMS admins can configure with their own questions. When we call the RenderComponentAsync, I expect to have a way to tell my component which FormId I want to render. The majority of our use cases require the functionality of telling the component whatto render.
Html.RenderComponentAsync<FromComponent>(RenderMode.ServerPrerendered, new { FormGuid = content.ContentGuid })
We have a similar situation to @leMicin:
We're swapping parts of an existing MVC app to Blazor components. In many cases we have code on an a Razor Page or MVC page that looks like this:
@(await Html.RenderComponentAsync<SOAllocationOverview>(new {SaleId = Model.SaleId}))
where the SaleId was a parameter in the URL of the page.
I'm really grateful to @Dimexoid for the idea for retrieving that value in the component itself, but that limits the re-usability of the components as it is now reliant on existing in a page that has a URL with parameters with certain names. The original approach seems cleaner to me.
Also, if we were creating components inside a loop on a Razor page we'd want to be able to pass the ID of the list item into the Blazor component.
What's the logic behind removing the option of passing in the model?
@tomRedox They explained it on this issue : #12245 . There was a performance problem with the solution as it was. I can understand why the solution was not working.
If you can't have the parameters on the server because we are unsure if the client will actually open a connection, then that means the parameters need to be sent from the client on the opening of the connection.
The parameters should be sent to the client with the Document, and when the client connects to the server, it sends the parameters to the server. This will make so the server does not use expensive CPU / Memory until the client successfully connects.
Removing it without offering an alternative will make it pretty much impossible for us to transition projects, which is sad because I was excited for Blazor.
@leMicin ahhh.. thank you, I hadn't seen that.
For our use case where we have a low number of users with a system running on an intranet, I think we're pretty unlikely to encounter the issues mentioned in #12245.
I remember when React started getting traction in the enterprise, a lot of that was due to being able to introduce it into existing codebases. It seems a real shame to limit that here, it seems like there must be some way to pass the values of the parameters without incurring the pre-rendering issues.
Ah, losing the option to pass parameters to components is a real shame. As others, we were using Blazor to progressively convert our existing Razor Pages application into a more dynamic experience.
I'm trying not to build an SPA, as blazor seems to force me to do.
This feature would have been great for that purpose.
I'll throw my hat in with everyone else in the thread. I was trying to use Blazor to create a more dynamic experience for my MVC application rather then investing in Angular/React. That's severely hindered by removing the ability to pass in parameters. I may be able to over come it with some additional coding on the Blazor component, but it lessens the separation of concerns of MVC and I thought one of the goals of Blazor was to work with existing Microsoft technologies, not forcing them into a new one. Like @leMicin I was using this for a low usage internal intranet app, and I don't forsee the issues in #12245.
Thinking about it a bit more, one potential answer here is to create an extra 'mvc wrapper' Blazor component for the component we're building. The wrapper would then be responsible for either extracting values from the page's URL, or could use Blazor's JS Interop to retrieve data from the page and would then pass those values on to the actual Blazor component that does the work. That would allow the original component to keep using parameters and help that component to continue to be resusable.
Then if the option to pass in parameters returns then the inner component can stay unchanged and we can just delete the wrappers.
That would at least keep a reasonable separation of concerns and avoid the need to open up a completed component later.
actually this + the fact that OnInitializedAsync
is called twice, makes blazor not that useful for many scenarios. I wanted to enhance one of our products with blazor but it's hard to do so, when we either can't support PreRendering or we need to have a performance offset by calling everything twice.
@mkArtakMSFT now this has a milestone set, does that mean this feature will return on 5.0.0-preview1, or just that it's up for consideration at that time? I'm wondering whether to design components on the assumption that we will ultimately be able to pass values to them via parameters in future?
This makes transition from MVC to Blazor very difficult.
And I think it should be considered at least for 3.1 instead of 5.0!
@tomRedox assuming we will find a good solution here, yes, this will be part of 5.0.
I'd like to chime in and say I was very surprised to see this error... What is the point of a component that you can't pass a parameter to? If even just an Id value...
@(await Html.RenderComponentAsync<PplComponent>(RenderMode.ServerPrerendered, new { Id = 1 }))
I was very excited to use server side blazor to render complex forms and "wizards" in my MVC app, rather than using signalR and typescript. But this kinda stops that idea...
@DrDave-M as I understand it the parameter feature hasn't been removed because it's thought to be unnecessary, it got pulled as part or removing the facility for stateful pre-rendering.
That change was made close to the final release date for Core 3, so I guess there wasn't time to give this further attention at that point.
I've tagged @rynowak into this conversation back on #12245 too.
It seems there has been a lot of activity on this thread. We're going to try (not a promise) to bring this in 3.1 as part of https://github.com/aspnet/AspNetCore/issues/14433
I was hoping to use Blazor in my applications. Sadly, I would use tutorial examples that use parameters, only to fail. The lack of ability to pass parameters from MVC views or razor pages is a deal killer for my organization.
The code for passing parameters to prerendered server components has now been restored and will reappear in 3.1. See #14433.
Should this work with 3.1.100-preview1-014459
?
Yes, works like a charm with preview1. But you can only phase non complex
objects.
ccit-spence notifications@github.com schrieb am So. 20. Okt. 2019 um
10:53:
Should this work with 3.1.100-preview1-014459?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/AspNetCore/issues/13721?email_source=notifications&email_token=AA6H4LFADCBVDCQS6TSYRKLQPQL7XA5CNFSM4IUAENK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBYFPJA#issuecomment-544233380,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA6H4LBZVHOQTT25BAPEQG3QPQL7XANCNFSM4IUAENKQ
.
I am still getting this using the CLI on a Mac.
@(await Html.RenderComponentAsync<CommentInput>(RenderMode.ServerPrerendered, new { RelatedId = Model.Data.Id}))
InvalidOperationException: Prerendering server components with parameters is not supported.
@ccit-spence what's the SDK you're using? Most probably you've got something wrong in your setup.
If, however, you think you're running into an issue caused by the framework, please file a new issue and provide as much details as possible, so we can try to reproduce it.
Most helpful comment
It seems there has been a lot of activity on this thread. We're going to try (not a promise) to bring this in 3.1 as part of https://github.com/aspnet/AspNetCore/issues/14433