Fix: pointerEvents propagation

[staszekscp]

Overview

The PR fixes two issues reported here:

1. Wrong behaviour of pointerEvents being set explicitly for all the descendants instead of leaving the CSS inheritance to take care of the style propagation.
2. Incorrect pointerEvents for values passed via inline styles instead of StyleSheet.create()

Testing

I've tested the change on the Expensify app that uses react-native-web. The bug that was reported by a reviewer on my PR doesn't appear with my fix included.

I also did a small reproduction where the changes can be tested. The fix is applied via patch-package there.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit ad846ff:

Sandbox	Source
react-native-web-examples	Configuration

[necolas]

My concern here is that this has a good chance of regressing performance because we're flattening the styles before resolving them. That's probably why the special handling of the pointerEvent prop wasn't ported.

It's been a while since I've looked at the e2e benchmarks but that would be the way to confirm this. Might be a good idea to separate the fix for the pointerEvents behavior from the attempt to support inline styles pointerEvent. The latter is an edge case that can easily be avoided by changes to product code anyway

[staszekscp]

Ok, I get the concern. I can remove the code to fix the inline style issue in this PR, but I still think it should be done, especially because nobody is aware of the difference in the pointerEvents behaviour. Even the React Native docs say that a plain JS object is fine for styling, and suggest using StyleSheet.create only for more complex scenarios. That's why I think that the issue should be solved in the react-native-web library.

In that case could you run the e2e tests to confirm that the solution causes performance regressions? I'm not sure what's the complexity of the flatten method, but there is always a chance to improve the code. I noticed that the props.style is passed as style[2] for the View component. If it's the same for all other components, we could look for the pointerEvents value only there. If it's an object we get O(1), but, even if in the client app the style prop gets passed by an array of style objects we can iterate in O(n) complexity to find the pointerEvents there.

[necolas]

A plain js object for styling is not fast enough for web. Doesn't matter what RN says

[staszekscp]

What I meant is that if the docs say that it's fine to use plain JS objects people will follow this instruction anyways. That's why I think it is should be covered. Maybe there should be at least a warning in the console to provide some feedback to the library users that something might not work as expected.

I've removed the code from the PR so it includes only the fix for the incorrect pointerEvents propagation

[staszekscp]

Hey @necolas! It's been a while since the fix has been merged to main, would it be possible to prepare a release so we can include it into our codebase?

[necolas]

Sorry forgot to do that. I'll merge a couple of other fixes and then get that out today

[staszekscp]

Thanks!