Develop Reference

Blazor and ICommand, what are the alternative and how do people not need it?

One of the useful thing when doing xaml in either Xamarin or Maui is having the ICommand interface; even better with the CommunityToolkits.Mvvm.
The ICommand has execut and canExecute to make coding the press of a button very easy.
In Blazor you can try and use ViewModels in the same way, as services,
I'm not talking just about items in a list to decouple from the model and have more props like an isSelected.
But it's not really the best thing and you don't have ICommand.
What do you do then when managing buttons?
<button #onclick="OnButtonClicked" disabled="#(canButtonExecute || isButtonExecuting)>
click me
</button>
You still have to make two properties, and a method to properly handle a button click or some combination of these, but the ICommand is not really a thing in Blazor, nor Microsoft suggest Mvvm for this framework.
There is a guy that plans to port the CommunityToolkit to Blazor but it's not like people are begging for it.
So how you all solve this issue? Not mentioning also that the disabled attribute in html can be just removed with the developer console.
Also it can be for any other case where ICommand is usefull and buttons arent just a way to submit forms. ( i know with the EditForm component you can use some properties of the model to make sure a button isnt clicked twice but still! )
Can you even make a custom directive to use in html components to not make a custom button element (imagine doing a blazor component as a wrapper for every html element come on)?
Like the #onclick but like #command="MyCommand"?

Blazorise supports ICommand on buttons https://blazorise.com/docs/components/button

Difference between Command (ICommand) and Click event

When should I use the Command and when to use the Click event?
F.e. if I have a Button in my UWP app what should I use?

When should I use the Command and when to use the Click event?
Yours is a broad question and I would simply answer with: "It depends".
Because:
The Command implements the ICommand interface and this means more code to add to your application but usually this won't change. Instead, the event handler doesn't require any interface implementation.
For every command you want, you have to provide the code that will handle the click and the CanExecute logic, to say when the command can execute. This is not requested in a simple event handler (like MyButton_Click). This means that, using a Command, you will have more control over the elements of your UI (the button won't execute anything if CanExecute is false).
When you want to add a Command, you will bind it to your DataContext (the ViewModel, if you implement the MVVM pattern). Instead, when you add a simple event handler (like MyButton_Click), the code will be placed in your code-behind that is the logic behind your main window. This means that implementing a Command, according to me, you'll have everything you need to modify in just one place (the ViewModel) instead of logic scattered everywhere in your project.
Of course, you can use whatever you want and my points are there just to give you an insight about these different implementations and you have to consider which solution is suitable for you, considering also the requirements you have been given (like: "Don't use event handlers" or "The Command is too advanced, let's just use something simple", etc.) and/or other constraints in your project.

C# WPF userControl to send data to mainWindow textBlock on buttonClick

I am trying to create a simple onscreen keypad created using buttons (currently a User-control), on those buttons i have a click event, when i click/touch a button i want the value of that button sent to a Text-block in my Main-window.
I can't/don't understand how to make the User-control (keypad) see the Text-block (in Main-window) to add in the value that i need.
I have seen solutions that use command Bindings and solutions that use the visual tree traversing but all of them are the main window accessing the user control, not the other way around.

All the examples are the other way around because that is how a UserControl is supposed to work.
A UserControl is a packaged piece of re-usable functionality. It should not know anything about the code that is using it.
Instead you should expose routed events in your UserControl for things like a when number was selected, and subscribe to them in your main window.

There are many ways to achieve what you want. If your MainWindow.xaml has a UserControl and you want to react to a change from the control in the MainWindow.xaml.cs file, then you could add a delegate to the UserControl code behind and register a handler for it in the MainWindow.xaml.cs file. Implementing new delegates are generally somewhat simpler than implementing RoutedEvents, which is another way that you could handle this situation.
Using a delegate like this will enable you to effectively pass a signal to the main view from the child UserControl code behind, which you can react to in any way you want to. Rather than explain the whole story again here, please see my answers from the Passing parameters between viewmodels and How to call functions in a main view model from other view models? posts here on Stack Overflow for full details on how to achieve this.

Event handling in MVVM

In MVVM, Model will usually have the data model, view is UI (XAML) which is further binded to the properties VM, ViewModel which typically inherits INotifyPropertyChanged.
When it comes to event handling, are there any specific pattern to handle all events on UI?
For Ex: Lets say if we have save/new/close button or some other button... and desired goal is when user does some operation and clicks on any of the button, control should go to code behind and should perform desired operation... how should I make sure that I have done the event handling in proper manner? and which interface I should use / when and how?
like we have ICommand interface/Relay command/Delegate command... I am not clear with this..
Thanks in advance for your response to my query...

Amit, if you are planning to hook up buttons, the accepted way is to use an implementation of ICommand (my personal preference is RoutedCommand). If you are aiming of to raise and handle events, have a look at Event Aggregators which is based on Publisher/Subscriber pattern.
In this, you will register a method (message handler) to ‘listen’ to a message (event) that matches a pattern. Once you done that, you can raise/publish messages (events) and when a match is found, the correct handler will gat raised
PRISM framework by Microsoft has done a good job of implementing event aggregate pattern
http://msdn.microsoft.com/en-us/library/ff921122(v=pandp.20).aspx
Hope this is useful

Why is ICommand better than code behind calling the VM?

I have a co-worker that asked me why he has to use the ICommand pattern.
He wants to add a button and then make an event for it in the code behind. Then from the event he wants to call a method on the ViewModel.
I gave him the obvious answer: This adds coupling between the View and the ViewModel. But he argued that the View and the ViewModel are already coupled. (We set our view's DataContext to the ViewModel in the View's code behind: DataContext = new MyViewModel();
Yes, I told him that his way adds "more coupling", but it sounded a bit lame even to me.
So, I know that ICommand is the clean way, and I do it that way. But what else does ICommand buy you besides not using an already existing coupling?

It's not about decoupling, but how deep you can penetrate inside your ModelView hierarchy: not event pumping, but event routing, built-in in the framework.
It's about UI managent: Command has state (CanExecute), if assign the command to the control, if command's state becomes false, control becomes disabled. It gives you powerful UI state management way, avoiding a lot of spaghetti coding, for complicated UI especially.

I have a co-worker that asked me why he has to use the ICommand
pattern.
It seems implied this is a standard at your company (whether explicitly stated or unspoken). That should be answer enough to his question.
If all company code is supposed to use that pattern, it can cause co-developer confusion and frustration when someone else has to debug his code.
Also, in my opinion, using ICommand is faster to develop / mock up because you don't NEED to have the ICommand property on the context to run your program. It lets your UI designers (if you are lucky enough to have them) completely finish their tasks even if you are behind in your coding.

ICommand can also give you a place for handling wether or not a specific button can be used right then. this would be handled through the canexecute method.

You can bind the CanExecute method of the command to the properties of a control, also a Command encapsulates an action in a nice way. In my opinion / experience this approach makes a lot of sense because you have both the condition and the execute action in a single abstraction, which makes it easier to understand and test.
If in the future you find that this action is repeated you can abstract it easily in your own custom ICommand and use it in several places.

One thing that I don't see in the previous answers is that using the ICommand promotes code reuse by allowing the same action to be used by different GUI components. For example, if I had a command that should result in the opening of a window and that command could be invoked in three or for different screens in the application, an ICommand implementation lets me define that logic in a single place. With the code-behind event handlers, I have to copy and paste redundant code, in violation of DRY (or else, I'd have to roll my own implementation by abstracting out to a class, at which point, I might as well use ICommand).