<!-- Thanks for submitting a pull request! We appreciate you spending
the time to work on these changes. Please follow the template so that
the reviewers can easily understand what the code changes affect -->
# Summary
As per the spec, bbox should not include any transformations, including
scaling. It should also not include any control points. This fixes
getBBox to give correct results matching Google Chrome, Firefox as per
the spec.
* What issues does the pull request solve? Please tag them so that they
will get automatically closed once the PR is merged
* What is the feature? (if applicable)
Bug fix.
* How did you implement the solution?
Like this, see.
* What areas of the library does it impact?
getBBox API.
## Test Plan
I build some stuff that works with SVG, the results on web were
inconsistent, and digging down I realise it was a react-native-svg.
Some fun fact, there was a surprisingly similar bug related to very
confusing named (CGPathGetBoundingBox vs CGPathGetPathBoundingBox) APIs
in Firefox some years ago as well.
https://bugzilla.mozilla.org/show_bug.cgi?id=1369904
### What's required for testing (prerequisites)?
### What are the steps to reproduce (after prerequisites)?
## Compatibility
| OS | Implemented |
| ------- | :---------: |
| iOS | ✅ |
| Android | 🔘# |
| Web | 🔘 *|
* Depends on the host platform. But works fine in major browsers.
# will create a follow up PR. Currently getBBox on Android doesn't
account for scaling properly.
## Checklist
<!-- Check completed item, when applicable, via: [X] -->
- [x] I have tested this on a device and a simulator
- [x] I added documentation in `README.md`
- [x] I updated the typed files (typescript)
- [x] I added a test for the API in the `__tests__` folder
Co-authored-by: Omeid Matten <omeid@kemene.com>
PR restoring backwards compatibility due to braking changes in method signatures of getViewManagerNames and setHitSlop, lambda expression being available for RN > 0.64(?). Since viewRegistry_DEPRECATED is available from RN 0.65, and its addUIBlock method is available from RN 0.69, and both those things are only really needed on new architecture, we use them only there and stick to the old impl for old arch.
Changed `requireNativeComponent` to `codegenNativeComponent` so that upcoming changes (Static View Configs, Bridgeless Mode and idk what more) in `react-native` are available in the library. Also, types and native components are now taken directly from `fabric` folder to make sure the values passed to the native components are the ones defined in props. It should work on all supported versions since `codegenNativeComponent` function exists from RN v. 0.61.0. Suggested by @RSNara and @cipolleschi
Reason for [`5394bbb` (#1847)](5394bbbced):
- on `Paper`, `Animated` uses `setNativeProps` method when we set `useNativeDriver` to `false`, and does not rerender the component. Therefore, new transform lands only in `SvgView` and is parsed in `RCTViewManager.m` .
- on `Fabric`, the same code makes the components rerender. Due to this, information about new transform is passed to the `SvgView` child: `G` , making it apply translations from the transform in its `updateProps` method.
- other than `Animated` use-case, on both archs, if we just passed `transform` prop to `Svg` component, it would end up in double transformations now as well. All of those changes are due to https://github.com/software-mansion/react-native-svg/pull/1895, which added proper parsing of RN style `transform` prop (array of transformations objects) therefore making `G` properly handle `transform` prop passed from `Svg`.
Reason for [`19bcb24` (#1847)](19bcb2464b): Same as https://github.com/software-mansion/react-native-screens/pull/1624
