The @bind:after and @bind:event sure makes it easier to read than what we had before like @oninput="@(EventCallback.Factory.CreateBinder(this, newValue => MyMethod(newValue), string.Empty))"
I really look forward to these new features because currently I have to do a lot of work-arounds e.g. call methods in setter-methods in order to get a similar functionality without too much effort. I am using MudBlazor and if you want to listen to change-Events (e.g. disable buttons when select-input changes) you have to override the "bind-value"-property (because that calls on-value-changed as well) and handle all the logic yourself which is pretty tedious and kinda unnecessary.
I remember having to deal with the old binding mechanics two years ago, barely getting it to work and it felt like a mess Now I'm back to Blazor, and just at the perfect time it seems. This works like a charm. Thank you!
I really want to use Blazor WASM in production, but it can’t allocate large chunks of memory. You receive a runtime exception that, I believe, has existed for years in mono.
Maybe its because of a new update or something but his doesnt work with a eventcallback, i used a Action instead and called InvokeAsync(StateHasChanged) manauly to update the table
Usually it is a good idea *not* to call the method on every input but use a debounce to only call the method after you stop typing. Otherwise you will be doing a lot of useless api calls.
If someone has a problem with @bind:after="Search" where it gives an error. Use these package references instead. [Sorry for bad, pronunciation, am not a native speaker of English]
The @bind:after and @bind:event sure makes it easier to read than what we had before like @oninput="@(EventCallback.Factory.CreateBinder(this, newValue => MyMethod(newValue), string.Empty))"
I really look forward to these new features because currently I have to do a lot of work-arounds e.g. call methods in setter-methods in order to get a similar functionality without too much effort. I am using MudBlazor and if you want to listen to change-Events (e.g. disable buttons when select-input changes) you have to override the "bind-value"-property (because that calls on-value-changed as well) and handle all the logic yourself which is pretty tedious and kinda unnecessary.
I remember having to deal with the old binding mechanics two years ago, barely getting it to work and it felt like a mess
Now I'm back to Blazor, and just at the perfect time it seems. This works like a charm. Thank you!
Most welcome! Glad I could help. And thanks a lot for your feedback! 😊
Thanks!
I really want to use Blazor WASM in production, but it can’t allocate large chunks of memory. You receive a runtime exception that, I believe, has existed for years in mono.
What about real multithreading in .net 7 Blazor WASM? Do we get it finally??
Maybe its because of a new update or something but
his doesnt work with a eventcallback, i used a Action instead and called InvokeAsync(StateHasChanged) manauly to update the table
Usually it is a good idea *not* to call the method on every input but use a debounce to only call the method after you stop typing. Otherwise you will be doing a lot of useless api calls.
True - but not the point of the video.
Amazing!! Shame we only upgrade to LTS 🙁 gotta wait till .net8
Hi,
Could you please a make a video on blazor empty solutions and create a layout and use it(please create a custom layout)
In the production ready version of NET7 AT THIS END OF THE YEAR THIS DOES NOT WORK.
love this channel ❤
thanks for the video
Brilliant, thanks!
I love you so much ❤
🥰
do less )
missed some blazor playground vids :3
If someone has a problem with @bind:after="Search" where it gives an error. Use these package references instead. [Sorry for bad, pronunciation, am not a native speaker of English]
Hello, Thanks for the wonderful tutorial. I drop a message for you on Twitter and email Please respond accordingly