Use custom attributes for ViewManagers property setters as in NativeModules

[vmoroz]

ViewManages currently use a single UpdateProperties function and a big switch statement. We should change it to have one method per property as it is done in Objective-C view managers and use custom attributes as we do for the NativeModules.
Ideally we should mimic the same custom-attribute based approach for ViewManagers as developers use today in Java and Objective-C.

[asklar]

@chrisglein This is actually taken care of by my latest PR #4575 (the one property per method instead of dealing with the whole map). My PR doesn't address the custom attribute but I'm interested in this since that would make things more discoverable from a reflection/metadata perspective which would help for #3587

[vmoroz]

@chrisglein @asklar let's discuss the details offline if you would like to take care about this task. This task is concerned about the ViewManagers implementation that use the ABI-safe API, while the changes you have done are mostly in the current ViewManages that are part of the Microsoft.ReactNative.dll and do not use the ABI-safe API.

We want the community-written ViewManagers to be written against the ABI-safe API, and in order to ensure that these ViewManagers can be written efficiently, we better change many of our 'internal' ViewManagers to use the same API and the same techniques. Writing community ViewManagers against ABI-safe API would enable the DLL-based distribution model.

@jonthysell has implemented the ABI-safe API for the ViewManagers. See the sample code in https://github.com/microsoft/react-native-windows/tree/master/packages/microsoft-reactnative-sampleapps/windows . It provides a good foundation. It should be improved by adding a one-per-property property setter augmented with a custom attribute like we do for the NativeModules (REACT_METHOD, REACT_EVENT, etc.) and promoting the strongly typed values and their 'automatic' conversion instead of working with the 'raw' IJSValueReader/IJSValueWriter/JSValue.

[aschultz]

There are a few use cases where being able to process the entire property bag at once are useful. Sometimes XAML interactions need to be ordered a certain way, or you want to wait until you've processed them all to kick off a heavy operation (say, starting video playback). I'd like to keep an escape hatch for that.

In those situation, the manual property extraction is still annoying though. Have you considered adding something akin to std::optional, but with 3 states (unset, set to null, set to value) instead of 2?

That would allow something like the following:

REACT_STRUCT(MyProps);
struct MyProps {
    REACT_FIELD(Color);
    Prop<winrt::hstring> Color;
};

void MyViewManager::UpdateProperties(..., IJSValueReader const& reader) {
    auto props = ReadValue<MyProps>(reader);
    if (props.Color.HasChanged()) {
        if (props.Color.IsNull()) {
            // Prop was removed. Clear XAML value.
        } else {
            // Prop was added. Set XAML value.
        }
    }  else {
        // Prop unchanged
    }
}

[elicwhite]

I don't have a background with the Windows constraints, but another approach could be to have the codegen generate the switch statement that calls the individual methods as well as something like an interface that has all the methods.

The common case is that people will use the Codegen, and their updateProperties implementation could call the function that was generated by the codegen. If their view manager is complex and they want to handle properties together, then they can opt out of using the codegen'd methods.

This is the approach we've taken with the codegen in a couple of places to satisfy the same constraints

[asklar]

We need the single property updateProperty in order to be able to measure API parity and identify unimplemented properties at runtime. Currently the existing UpdateProperties API on IViewManagerWithNativeProperties only has the UpdateProperties API which doesn't give insight into which properties were handled or not. We recently had to add an additional method to internal view managers to be called at the end of all property updates so I would expect that method to make it into the new interface alongside the single property update API.
FYI there is currently no codegen for c++ view managers in Windows.