feat: migrate RNMBXSources to new arch

[WoLewicki]

PR adding New Architecture support to the library 🎉

We at Software Mansion have been working on improving support for the new architecture for quite a while now. If you need help with anything related to New Architecture, like:

• migrating your library
• migrating your app
• investigating issues
• improving performance

or you just want to ask any questions, hit us up on projects@swmansion.com

---

Notes

PR migrating all RNMBXSources to new arch.

[WoLewicki]

@mfazekas I have a few questions with this PR:

1. I can see features native command in both ShapeSource and VectorSource components, but they are not implemented on the native side. Can I just remove them? I added a module for ShapeSource to better handle it:

   maps/src/components/ShapeSource.tsx

   Line 182 in cd4379c

   async features(filter: Array<string> = []) {

2. I'd like to remove the whole NativeBridgeComponent (https://github.com/rnmapbox/maps/blob/cd4379c98670ea6e6a561e8ebbe76c7f6e0247a0/src/components/NativeBridgeComponent.tsx) class since it won't be used after we transfer commands to just native methods. Is it ok? Should I know something particular about it when deleting?
3. Can I leave the basic implementation of getting the ShapeSource view in the module or should I do something similar to this PR: j-piasecki@c60584d ? It seems that the methods on ShapeSource are not called immediately after the components are rendered but I may be missing something.

Other than that, the PR seems to be ready. I'd remove the NativeBridgeComponent in the next PR when migrating PointAnnotation since it also uses this class.

[mfazekas]

@mfazekas I have a few questions with this PR:

1. I can see features native command in both ShapeSource and VectorSource components, but they are not implemented on the native side. Can I just remove them? I added a module for ShapeSource to better handle it:

   maps/src/components/ShapeSource.tsx

   Line 182 in cd4379c

   async features(filter: Array<string> = []) {

This was implemented in v8 but was not yet implemented in v10 this can be deleted. Now

2. I'd like to remove the whole NativeBridgeComponent (https://github.com/rnmapbox/maps/blob/cd4379c98670ea6e6a561e8ebbe76c7f6e0247a0/src/components/NativeBridgeComponent.tsx) class since it won't be used after we transfer commands to just native methods. Is it ok? Should I know something particular about it when deleting?

Sure this can be deleted.
We still have some common code that might needs to be shared in some way:

https://github.com/rnmapbox/maps/blob/b08319a2a23440153c36d900c1490bc718645856/src/components/MapView.tsx#L921-L945C4

3. Can I leave the basic implementation of getting the ShapeSource view in the module or should I do something similar to this PR: j-piasecki@c60584d ? It seems that the methods on ShapeSource are not called immediately after the components are rendered but I may be missing something.

I think we'll face the same issue if the user takes a ref and calls the commend as soon as the ref is available.
I think we can share a single ViewTagResolver across multiple view managers. But this is something I'm ok to be done later.

Other than that, the PR seems to be ready. I'd remove the NativeBridgeComponent in the next PR when migrating PointAnnotation since it also uses this class.

[WoLewicki]

Ok thanks for answering the comments, I'll remove the features for now then and will do the rest of the cleanup concerning other components in next PRs 🚀

[WoLewicki]

After checking deeper, I think I'll leave the NativeBridgeComponent, but only with the _runPendingNativeCommands since it seems reasonable to have it. Wdyt?

[mfazekas]

@WoLewicki I think that's ok. (FWIW if we can me it into composition instead of inheritance and HOC that's even better, but it's not critical.)