feat: use process function if prop is a function but view attribute configured a process function

[hannojg]

Summary:

Motivation

As per the ViewConfig flow types we can configure a custom process function for props:

react-native/packages/react-native/Libraries/Renderer/shims/ReactNativeTypes.js

Lines 38 to 43 in 22e7691

	export type AttributeType<T, V> =
	| true
	| $ReadOnly<{
	diff?: (arg1: T, arg2: T) => boolean,
	process?: (arg1: V) => T,
	}>;

However, this process function is ignored in the diffProperties function when the incoming prop is a function.

This is a problem, as we have no mechanism to opt-out of the default behaviour of a function prop being set to true. In our case we are trying to pass the props as direct JSI values to our View components, but right now function props are always received as true, due to this forced behaviour and we want to opt out.

This PR implements a check to call the process function if it's set. This way we can opt-out of passing functions as true to the native side instead of the actual function.

Note: this is only one piece of the puzzle, as this flow only gets triggered for updating props on a component (as far as I can see). The flow for when a component gets created is different and is handled here:

• feat(ReactNative): prioritize attribute config process function to allow processing function props react#32119

Changelog:

[GENERAL] [ADDED] - Call process for a prop's view config, even if that prop is a function.

Test Plan:

I modified the code manually in a template react-native app and confirmed its working. This is a code path you only need in very special cases, thus it's a bit hard to provide a test for this. I recorded a video where you can see that the changes are active and the prop is being passed as native value once the props for a component get updated:

compressed2.mp4

[hannojg]

Test and lint are changing for things I haven't touched 🤔

[javache]

This code has gotten out-of-sync with what's upstream. Let's land this change in React and I'll look into merging it here.

It may take a while before you'll see this fix though (and the approach of wrapping the function in an object may be required) since we'd need to wait for a next React release.