iOS: Support corner-specific border radii on Images

[rigdern]

This adds support for corner-specific radii on Images on iOS. Specifically, these props:

• borderTopLeftRadius
• borderTopRightRadius
• borderBottomLeftRadius
• borderBottomRightRadius

This feature is already supported on Android.

Most of the logic was copied from RCTView.

Test Plan (required)

I made a test app where I set borderRadius and the corner-specific border radius props mentioned above to a variety of values including undefined and ensured the Image rendered correctly. I tested initial values as well as updates. Additionally, my team is using this change in our app.

Adam Comella
Microsoft Corp.

[janicduplessis]

Nit: Could you remove the extra empty lines from L493 to L502

[janicduplessis]

cc @javache

[javache]

cc @shergin

[shergin]

@rigdern Adam,
Thank you so much for this PR and your effort!

The problem with supporting proper border rendering for is actually much more complicated because we have to not only render the border correctly but also apply proper layout to the component (padding and border should kinda affect intrinsic size of ). Previously, we also decided that we don't want to copy-paste code from RCTView, instead we want to have unified and supportable solution for this problem which can be applied for all custom components.

Recently (couple of weeks ago) we decided that the answer to this challenge is pretty simple: We have to wrap all components (which should have proper border rendering) in RCTView instance on native side. I am working on this right now. I already implemented it for (proper support for padding, borders and intrinsic size for both types of ) and it will land in the beginning of the next week.
Adopting this approach for is a bit more complicated because we have to deprecate support of nested components inside as a first step (we will provide drop in replacement for this case). I hope I will have the fix for this border problem in the beginning of the next month.

[rigdern]

@shergin Thanks for the explanation. I'm looking forward to your change landing in master.

In your post, you mentioned borders generally and not border radius specifically. Is the implementation of border for Image that is in master today broken?

Can you elaborate on why your solution will break nesting of components within Images? Can you also elaborate on the drop in replacement for this nesting case? Will similar restrictions be imposed on Android or will the iOS and Android Image APIs become inconsistent?

Am I correct in assuming that your change will introduce support for corner-specific border radii on Images?

[shergin]

In your post, you mentioned borders generally and not border radius specifically. Is the implementation of border for Image that is in master today broken?

Yeah, kind of. The way how borders are rendered now is... far from perfect. For instance, now if an image has border, the border draws on top of the image, which is counterintuitive and does not match Yoga layout model. So, it should render like [border][padding][image-content][padding][border] whereas right now it renders like [[border]image-content[border]].

Am I correct in assuming that your change will introduce support for corner-specific border radii on Images?

Yeah, this change will introduce as full border support as generic <View>s have.

Can you elaborate on why your solution will break nesting of components within Images?

The current model of implies that the internal content of <Image> defines its size, which is in most cases counterintuitive. We want to implement proper support for intrinsic content size for <Image> instead, which means that actual image bitmap will defines the size of the component.
See 9637dd4 for details.

Will similar restrictions be imposed on Android or will the iOS and Android Image APIs become inconsistent?

We plan to deprecate (and remove very soon) support of <Image> with nested content for both platforms.