Allow setting props to Shadow wrapping View

[orierel]

Hi,

I'm missing the functionality of setting custom properties to the shadow wrapper View, in my case I am looking to set pointerEvents to none to avoid shadow handling touch gestures that should be handled by the view underneath the shadow.

[ftzi]

Have you tested it? A similar thing was done in #24, to the parent and content view.

[orierel]

I have tested it and already am using this PR in my production React Native app.

In the PR you mentioned you added pointerEvents={"none"} to the parent View of the View I made this PR for.
You can resolve this PR by adding pointerEvents={"none"} to the child View as well, it would of fix my problem but when I created this PR I thought it would be better to think ahead of more cases like this that could be in the future, the only thing I did not allow in this PR is to override the style you applied to the View.

[ftzi]

Yes, I will add the shadowViewProps as it may be useful to other cases, I was just curious about the pointerEvents. Going to add both asap.

Thanks!

[ftzi]

Hi @orierel! Just added both in 6.0.0 via d32dc12.

As a little tip that you may not know (as you haven't done it in your PR), here is how I did it:

<View pointerEvents='none' {...shadowViewProps} style={[{ ...StyleSheet.absoluteFillObject, left: offsetX, top: offsetY }, shadowViewProps?.style]}>

This way the user can set the style inside the props.

Thanks for your contribution and have a great new year! 😀

[orierel]

I don't think that would be the right way because now your allowing users override your style props which are required and shouldn't be "violated" by wrong usage.
Also, not sure what is the point of creating PRs in this repo if your not merging them and instead just using them as ideas / requests and then creating your own PR,, I would create an issue instead of supplying a potential solution instead if I knew that.

[ftzi]

shouldn't be "violated" by wrong usage

Well, the user can also violate the shadow by inputting other "invalid" view props besides the style. Actually I didn't even listed the shadowViewProps in the README as no one will probably need to use it, only people that read the lib code will try to change it to fix something. I did this way because it allows me to try other styles in debugging etc. The user can violate the lib and even React Native in many ways due to wrong usage.

Few days before your PR, I was already testing the shadow view style to remove the width: '100%', height: '100%' that was causing a visual bug in the first render. Those were removed in 6.0.0 as pointed out in Changelog. As the lib didn't allow me to change the style of the shadow, I was having to change the lib .js in my app to test my hypothesis, so, I have added shadowViewStyle before your PR.

Precisely, I commited it 1 day before your PR (ea55a99) in 6.0.0.beta-0 branch, using just shadowViewStyle prop instead of shadowViewProps. As you found out that more advanced users could find a use to setting the view props (like adding the pointerEvents='none'), I decided to follow your idea.

I truly appreciate your participation, but in your 4 line code changes, none were exactly equal to how the code came out to be.

• Your changes: https://github.com/SrBrahma/react-native-shadow-2/pull/32/files#diff-0b5adbfe7b36e4ae2f479291e20152e33e940f7f265162d77f40f6bdb5da7405

• 6.0.0 changes: d32dc12#diff-0b5adbfe7b36e4ae2f479291e20152e33e940f7f265162d77f40f6bdb5da7405

It was just easier and faster for me to write it by myself to get what I wanted for the lib. Merging and overwriting the few lines you've done wouldn't make too much sense to get it done.

It's always safer in opensource to first open an Issue to avoid wasted work. Some PRs can happen to be merged without an Issue and discussion, but sometimes what happened here will happen.