Why do we assign InputActions in InputActionMappingContexts, but still have to bind InputActions one by one in the SetupPlayerInput?

[MaskOfDanyu]

In all the tutorials I find, and even seeing it done in the templates, InputActionMappingContexts are made, and assigning the buttons for the InputActions. But I notice they usually expose UInputActions using UPROPERTY(). Why not something like for example UInputMappingContext Mapping;, then when binding it would be something like BindAction(Mapping[0], ETriggerEvent::Triggered, this, );

[gardian206]

it is so that an InputAction can be utilized in multiple InputMappingContext

for example (I will consider an XBox/Nintendo layout) if I have IA_Jump and for IMC_MainGame I set IA_Jump to be mapped to Button_A then in IMC_MiniGameSideScroll I can map IA_Jump to Button_B we are still mapping IA_Jump to different buttons, and based on the current (or highest priority) InputMappingContext we can decide which of the delegate functions get bound.

in your example you don’t finish binding the delegate you need to pass a function for the Delegate to be bound to as the next argument.
this is similar to in blueprints we have to drag out the Exec pin, and start putting execution nodes

to the specific C++ stuff
the reason to expose the UInputAction as a UPROPERTY() is so that it can be assigned in the Editor (probably in the Details window) to avoid “Runtime-Resolved-Hard-References” (someone on the project changes the name or location of the asset and the best case scenario is either a crash, or an error message, but you will probably get nothing as a result)
in the examples/templates these are declared as private but then exposed to the Editor so we still get data protection from C++ side and they are often marked as EditAnywhere, BlueprintReadOnly so that they can only be modified in the details window of the blueprint they are to be assigned in.