Add new architecture support

[j-piasecki]

Description

Adds setup for the new architecture support to the library:

• codegen configuration
• adds forward declaration for MapView class, so that swift header can be used in
• adds support for the new architecture to the MapView component as base for migration

We will work incrementally to migrate the rest of the components and modules on top of the changes introduced here.

This work is done on behalf of Expensify.

Checklist

• I have tested this on a device/simulator for each compatible OS
• I updated the documentation with running yarn generate in the root folder
• I added/updated a sample - if a new feature was implemented (/example)

Screenshot OR Video

[j-piasecki]

Hi @mfazekas! So far I've migrated the map component, fully only on iOS, (some approaches are inspired by the existing PR) and I have a few things I want to ask about:

• Using RCT prefix for iOS components on the new arch is a problem since it's reserved for core components, so the fabric components would have to use a different one. Based on the existing PR I started with MBX, is that ok or should I change it to something else?
• Related to the previous point - should all files use the new prefix or only the ones where it's necessary?
• Due to codegen limitations when it comes to native commands, I added a native module that's implementing them instead as a workaround. This makes it necessary to modify how commands are dispatched JS-side, is the current approach ok?
• The fabricexample app is there to simplify testing since it has no dependencies and is pretty straightforward which makes debugging easier. Should I remove it when the PR is ready to merge or should it stay in the repo?

If you can spare some time, could you go over the changes in the PR to check if you can see any problems with the approaches taken? It would be much easier to solve them now, given that relatively not much has been done yet 😅.

[mfazekas]

Hi @mfazekas! So far I've migrated the map component, fully only on iOS, (some approaches are inspired by the existing PR) and I have a few things I want to ask about:

• Using RCT prefix for iOS components on the new arch is a problem since it's reserved for core components, so the fabric components would have to use a different one. Based on the existing PR I started with MBX, is that ok or should I change it to something else?
• Related to the previous point - should all files use the new prefix or only the ones where it's necessary?
• Due to codegen limitations when it comes to native commands, I added a native module that's implementing them instead as a workaround. This makes it necessary to modify how commands are dispatched JS-side, is the current approach ok?
• The fabricexample app is there to simplify testing since it has no dependencies and is pretty straightforward which makes debugging easier. Should I remove it when the PR is ready to merge or should it stay in the repo?

If you can spare some time, could you go over the changes in the PR to check if you can see any problems with the approaches taken? It would be much easier to solve them now, given that relatively not much has been done yet 😅.

Thanks this is awesome! Yes MBX should be ok, for prefixes. And I think it's fine to use only when necessary. We can clean that up later.

Native modules is a clever workaround for the codegen limitations I've also faced. For the first glance your approach worked, I'll need to test if it works on pre fabric world as well.

The fabriceexample can stay, we'll see in the future. For now my feeling is that they make the RN upgrade more complicated, than the value it adds, but we'll see it should be easy to remove at any time.

I'll try to go over the changes in more details over the weekend.
Thanks again for this work!

[j-piasecki]

Native modules is a clever workaround for the codegen limitations I've also faced. For the first glance your approach worked, I'll need to test if it works on pre fabric world as well.

I haven't tested the old architecture with the changes applied yet, as was focusing on getting the new arch to work fully. I don't think it will work at the moment 😅.

[mfazekas]

It's a bit unfortunate to have both whitespace changes and significant changes in the same PR, it's make kind of pain to review.

[j-piasecki]

Sorry, I don't remember changing it. They should be removed now.

[mfazekas]

I'd put this to the caller, which would be then:

-                mapView.getCoordinateFromView(args!!.getString(0), args.getArray(1).toScreenCoordinate());
+                mapView.getCoordinateFromView(args.getArray(1).toScreenCoordinate()) { sendResponse(args!!.getString(0), it};

Actually I've refactored android commands based on your changes so they can be used as react methods as well - see #3029. Sorry it'll be a bit of pain to rebase your changes

[j-piasecki]

I've rebased the PR to the main branch. Do you think merging instead of rebasing would be a problem in the future? It would be easier to do, and it would simplify parallelizing the work.

[mfazekas]

Look great, thanks much for all the work. Feel free to use merge instead of rebase if you prefer that.

[j-piasecki]

@mfazekas @WoLewicki figured out a clever way to use the swift header by adding a forward declaration for the MapView class, which doesn't have @objc annotation and it simplifies the iOS setup a lot. There's no need for factories and multiple declarations of essentially the methods in multiple files.

We also figured that since there is a native module on the new arch, we can use it instead of commands on the old arch as well to reduce the complexity and code duplication.

Could you look at the changes and tell us what you think?

[mfazekas]

@mfazekas @WoLewicki figured out a clever way to use the swift header by adding a forward declaration for the MapView class, which doesn't have @objc annotation and it simplifies the iOS setup a lot. There's no need for factories and multiple declarations of essentially the methods in multiple files.

Thanks, clever. Yes it's look simpler this way.

We also figured that since there is a native module on the new arch, we can use it instead of commands on the old arch as well to reduce the complexity and code duplication.

Could you look at the changes and tell us what you think?

NativeModule is something I wanted to implement on Android, so that is great.

[j-piasecki]

It looks like e2e tests are failing for the MapLibre implementation. Most likely because:

1. We changed the map component name to MBXMapBox in the JS, but not in the native implementation of MapLibre
2. We are loading the module using TurboModuleRegistry.getEnforcing(...), which will throw when the module is not found, and it doesn't exist in this implementation.

It looks like MapLibre and mapbox-gl are deprecated and are going to be removed. Should we make them compatible with our changes, or should we ignore them?

[mfazekas]

It looks like e2e tests are failing for the MapLibre implementation. Most likely because:

1. We changed the map component name to MBXMapBox in the JS, but not in the native implementation of MapLibre
2. We are loading the module using TurboModuleRegistry.getEnforcing(...), which will throw when the module is not found, and it doesn't exist in this implementation.

It looks like MapLibre and mapbox-gl are deprecated and are going to be removed. Should we make them compatible with our changes, or should we ignore them?

Yep CI cannot run Mapbox as metal is not supported on GitHub CI actions. So we've used Mapblibre for the CI. But now Maplibre is so far behind we can just remove it.

[j-piasecki]

Yep CI cannot run Mapbox as actions/runner-images#6138. So we've used Mapblibre for the CI. But now Maplibre is so far behind we can just remove it.

So what exactly are the next steps here?

[mfazekas]

So what exactly are the next steps here?

I guess for me to review and merge, disable MapLibre CI, so we can go forward

[j-piasecki]

Not sure if @rnmapbox/maps works with the reactwg/react-native-new-architecture#135 with fabric at the moment or not

Ah, I completely missed this 😅. We tried it (only the MapView component) and on iOS it worked fairly well - the only problem was events not working. On Android, it didn't work at all IIRC.

[mfazekas]

@j-piasecki I have a strange issue with this branch.

In the PointInMapView.js example. The async method call

maps/example/src/examples/Map/PointInMapView.js

Line 29 in 9a4a099

const pointInView = await this._map.getPointInView(e.geometry.coordinates);

here only resolved every second time (but then the old one resolves as well.)

It seems that the culprit is [UIManager addUIBlock:^()]. Queues the block but then execution get delayed to the second click.

https://github.com/j-piasecki/mapbox-maps/blob/66e6ccdbf9af21a1eb27527df92c41b436532bc6/ios/RCTMGL-v10/MBXMapViewModule.mm#L38-L39

I think the issue is that MBXMapViewModule was previously RCTMGLMapViewManager which was a subclass of RCTViewManager. And I think addUIBlock cannot be used outside RCTViewManager, in the sense that the block might be just queue, but the queue might be only flushed by the next ui operation. note

This is the recording of rnmapbox example from the fabric branch. Note that coords are updated every second call.
https://github.com/rnmapbox/maps/assets/52435/a5a13b86-78dd-49ff-8be9-26664784ff5f

This is the recording of rnmapbox example from main branch.
https://github.com/rnmapbox/maps/assets/52435/b25953e6-9384-4c66-a873-c95fd91357e5

[mfazekas]

@j-piasecki Some minor notes, none of those requires any immediate action more a FYI:

1.) actually the MBXMapView is not really good as the native Mapbox libraries also use the MBX prefix. So we should be using RNMBXMapView or something like that. But we can change that later. Sorry for disinformation about that.

Mapbox

2.) Xcode seems to be giving errors in the IDE about MBXMapView when not compiling for FABRIC. This sounds like an IDE issue, as the project builds but I still see those errors in IDE, if I do any edits to MBXMapViewModule:

[mfazekas]

Suggested change

	reject(@"takeSnap", [NSString stringWithFormat:@"Unknown reactTag: %@", viewRef], nil);
	reject(@"MBXMapView command", [NSString stringWithFormat:@"Unknown reactTag: %@", viewRef], nil);

We could also pass the command names for more precise error. But I don't think that's worth the effort.

[WoLewicki]

done ✅

[WoLewicki]

@mfazekas I pushed a change that should fix the issue you have in #3022 (comment). Could you test it? For some reason the ui blocks are dispatched before the one we add is inserted in the queue, so I changed them to be added on uiManager queue so no need to asynchronously change queues to add them.

[WoLewicki]

1.) actually the MBXMapView is not really good as the native Mapbox libraries also use the MBX prefix. So we should be using RNMBXMapView or something like that. But we can change that later. Sorry for disinformation about that.

Should we change it in this PR or can it be done later?

[mfazekas]

1.) actually the MBXMapView is not really good as the native Mapbox libraries also use the MBX prefix. So we should be using RNMBXMapView or something like that. But we can change that later. Sorry for disinformation about that.

Should we change it in this PR or can it be done later?

It can be done later. Was more a reminder to myself.

[mfazekas]

@j-piasecki thanks much for all the great work. I've merged to main now. Created a branch for v10.0 and initial fabric support will be on 10.1 releases.

[WoLewicki]

Ok, we've already migrated many more of the views so we'll keep submitting the PRs with them 🚀

[mfazekas]

@j-piasecki how do we update generated files in old-arch?!

[WoLewicki]

When running the app on the new arch, those files should be generated in the main lib's android folder in build/generated/source/codegen/java/com. From there, you should just copy the files and it should work just fine on old arch.

[mfazekas]

When running the app on the new arch, those files should be generated in the main lib's android folder in build/generated/source/codegen/java/com. From there, you should just copy the files and it should work just fine on old arch.

Makes sense, thanks.

What is the plan for the style prop type in layers?
We have generated types for them in typescript. Based on json file from Mapbox (v8.json).

We used to pass it as a json object, I think in codegen cannot hand such complex object type. So are we going to use string to pass those from JS to native? I see you're using UnsafeMixed, so that is the codegen solution then, right?

maps/src/utils/MapboxStyles.d.ts

Lines 616 to 1043 in f34aa2f

	export interface SymbolLayerStyleProps {
	/**
	* Label placement relative to its geometry.
	*/
	symbolPlacement?: Value<
	Enum<SymbolPlacementEnum, SymbolPlacementEnumValues>,
	['zoom']
	>;
	/**
	* Distance between two symbol anchors.
	*/
	symbolSpacing?: Value<number, ['zoom']>;
	/**
	* If true, the symbols will not cross tile edges to avoid mutual collisions. Recommended in layers that don't have enough padding in the vector tile to prevent collisions, or if it is a point symbol layer placed after a line symbol layer. When using a client that supports global collision detection, like Mapbox GL JS version 0.42.0 or greater, enabling this property is not needed to prevent clipped labels at tile boundaries.
	*/
	symbolAvoidEdges?: Value<boolean, ['zoom']>;
	/**
	* Sorts features in ascending order based on this value. Features with lower sort keys are drawn and placed first. When `iconAllowOverlap` or `textAllowOverlap` is `false`, features with a lower sort key will have priority during placement. When `iconAllowOverlap` or `textAllowOverlap` is set to `true`, features with a higher sort key will overlap over features with a lower sort key.
	*/
	symbolSortKey?: Value<number, ['zoom', 'feature']>;
	/**
	* Determines whether overlapping symbols in the same layer are rendered in the order that they appear in the data source or by their yPosition relative to the viewport. To control the order and prioritization of symbols otherwise, use `symbolSortKey`.
	*/
	symbolZOrder?: Value<
	Enum<SymbolZOrderEnum, SymbolZOrderEnumValues>,
	['zoom']
	>;
	/**
	* If true, the icon will be visible even if it collides with other previously drawn symbols.
	*
	* @requires iconImage
	*/
	iconAllowOverlap?: Value<boolean, ['zoom']>;
	/**
	* If true, other symbols can be visible even if they collide with the icon.
	*
	* @requires iconImage
	*/
	iconIgnorePlacement?: Value<boolean, ['zoom']>;
	/**
	* If true, text will display without their corresponding icons when the icon collides with other symbols and the text does not.
	*
	* @requires iconImage, textField
	*/
	iconOptional?: Value<boolean, ['zoom']>;
	/**
	* In combination with `symbolPlacement`, determines the rotation behavior of icons.
	*
	* @requires iconImage
	*/
	iconRotationAlignment?: Value<
	Enum<IconRotationAlignmentEnum, IconRotationAlignmentEnumValues>,
	['zoom']
	>;
	/**
	* Scales the original size of the icon by the provided factor. The new pixel size of the image will be the original pixel size multiplied by `iconSize`. 1 is the original size; 3 triples the size of the image.
	*
	* @requires iconImage
	*/
	iconSize?: Value<number, ['zoom', 'feature']>;
	/**
	* Scales the icon to fit around the associated text.
	*
	* @requires iconImage, textField
	*/
	iconTextFit?: Value<Enum<IconTextFitEnum, IconTextFitEnumValues>, ['zoom']>;
	/**
	* Size of the additional area added to dimensions determined by `iconTextFit`, in clockwise order: top, right, bottom, left.
	*
	* @requires iconImage, textField
	*/
	iconTextFitPadding?: Value<number[], ['zoom']>;
	/**
	* Name of image in sprite to use for drawing an image background.
	*/
	iconImage?: Value<ResolvedImageType, ['zoom', 'feature']>;
	/**
	* Rotates the icon clockwise.
	*
	* @requires iconImage
	*/
	iconRotate?: Value<number, ['zoom', 'feature']>;
	/**
	* Size of the additional area around the icon bounding box used for detecting symbol collisions.
	*
	* @requires iconImage
	*/
	iconPadding?: Value<number, ['zoom']>;
	/**
	* If true, the icon may be flipped to prevent it from being rendered upsideDown.
	*
	* @requires iconImage
	*/
	iconKeepUpright?: Value<boolean, ['zoom']>;
	/**
	* Offset distance of icon from its anchor. Positive values indicate right and down, while negative values indicate left and up. Each component is multiplied by the value of `iconSize` to obtain the final offset in pixels. When combined with `iconRotate` the offset will be as if the rotated direction was up.
	*
	* @requires iconImage
	*/
	iconOffset?: Value<number[], ['zoom', 'feature']>;
	/**
	* Part of the icon placed closest to the anchor.
	*
	* @requires iconImage
	*/
	iconAnchor?: Value<
	Enum<IconAnchorEnum, IconAnchorEnumValues>,
	['zoom', 'feature']
	>;
	/**
	* Orientation of icon when map is pitched.
	*
	* @requires iconImage
	*/
	iconPitchAlignment?: Value<
	Enum<IconPitchAlignmentEnum, IconPitchAlignmentEnumValues>,
	['zoom']
	>;
	/**
	* Orientation of text when map is pitched.
	*
	* @requires textField
	*/
	textPitchAlignment?: Value<
	Enum<TextPitchAlignmentEnum, TextPitchAlignmentEnumValues>,
	['zoom']
	>;
	/**
	* In combination with `symbolPlacement`, determines the rotation behavior of the individual glyphs forming the text.
	*
	* @requires textField
	*/
	textRotationAlignment?: Value<
	Enum<TextRotationAlignmentEnum, TextRotationAlignmentEnumValues>,
	['zoom']
	>;
	/**
	* Value to use for a text label. If a plain `string` is provided, it will be treated as a `formatted` with default/inherited formatting options. SDF images are not supported in formatted text and will be ignored.
	*/
	textField?: Value<FormattedString, ['zoom', 'feature']>;
	/**
	* Font stack to use for displaying text.
	*
	* @requires textField
	*/
	textFont?: Value<string[], ['zoom', 'feature']>;
	/**
	* Font size.
	*
	* @requires textField
	*/
	textSize?: Value<number, ['zoom', 'feature']>;
	/**
	* The maximum line width for text wrapping.
	*
	* @requires textField
	*/
	textMaxWidth?: Value<number, ['zoom', 'feature']>;
	/**
	* Text leading value for multiLine text.
	*
	* @requires textField
	*/
	textLineHeight?: Value<number, ['zoom', 'feature']>;
	/**
	* Text tracking amount.
	*
	* @requires textField
	*/
	textLetterSpacing?: Value<number, ['zoom', 'feature']>;
	/**
	* Text justification options.
	*
	* @requires textField
	*/
	textJustify?: Value<
	Enum<TextJustifyEnum, TextJustifyEnumValues>,
	['zoom', 'feature']
	>;
	/**
	* Radial offset of text, in the direction of the symbol's anchor. Useful in combination with `textVariableAnchor`, which defaults to using the twoDimensional `textOffset` if present.
	*
	* @requires textField
	*/
	textRadialOffset?: Value<number, ['zoom', 'feature']>;
	/**
	* To increase the chance of placing highPriority labels on the map, you can provide an array of `textAnchor` locations: the renderer will attempt to place the label at each location, in order, before moving onto the next label. Use `textJustify: auto` to choose justification based on anchor position. To apply an offset, use the `textRadialOffset` or the twoDimensional `textOffset`.
	*
	* @requires textField
	*/
	textVariableAnchor?: Value<
	Enum<TextVariableAnchorEnum, TextVariableAnchorEnumValues>[],
	['zoom']
	>;
	/**
	* Part of the text placed closest to the anchor.
	*
	* @requires textField
	*
	* @disabledBy textVariableAnchor
	*/
	textAnchor?: Value<
	Enum<TextAnchorEnum, TextAnchorEnumValues>,
	['zoom', 'feature']
	>;
	/**
	* Maximum angle change between adjacent characters.
	*
	* @requires textField
	*/
	textMaxAngle?: Value<number, ['zoom']>;
	/**
	* The property allows control over a symbol's orientation. Note that the property values act as a hint, so that a symbol whose language doesn’t support the provided orientation will be laid out in its natural orientation. Example: English point symbol will be rendered horizontally even if array value contains single 'vertical' enum value. For symbol with point placement, the order of elements in an array define priority order for the placement of an orientation variant. For symbol with line placement, the default text writing mode is either ['horizontal', 'vertical'] or ['vertical', 'horizontal'], the order doesn't affect the placement.
	*
	* @requires textField
	*/
	textWritingMode?: Value<
	Enum<TextWritingModeEnum, TextWritingModeEnumValues>[],
	['zoom']
	>;
	/**
	* Rotates the text clockwise.
	*
	* @requires textField
	*/
	textRotate?: Value<number, ['zoom', 'feature']>;
	/**
	* Size of the additional area around the text bounding box used for detecting symbol collisions.
	*
	* @requires textField
	*/
	textPadding?: Value<number, ['zoom']>;
	/**
	* If true, the text may be flipped vertically to prevent it from being rendered upsideDown.
	*
	* @requires textField
	*/
	textKeepUpright?: Value<boolean, ['zoom']>;
	/**
	* Specifies how to capitalize text, similar to the CSS `textTransform` property.
	*
	* @requires textField
	*/
	textTransform?: Value<
	Enum<TextTransformEnum, TextTransformEnumValues>,
	['zoom', 'feature']
	>;
	/**
	* Offset distance of text from its anchor. Positive values indicate right and down, while negative values indicate left and up. If used with textVariableAnchor, input values will be taken as absolute values. Offsets along the x and yAxis will be applied automatically based on the anchor position.
	*
	* @requires textField
	*
	* @disabledBy textRadialOffset
	*/
	textOffset?: Value<number[], ['zoom', 'feature']>;
	/**
	* If true, the text will be visible even if it collides with other previously drawn symbols.
	*
	* @requires textField
	*/
	textAllowOverlap?: Value<boolean, ['zoom']>;
	/**
	* If true, other symbols can be visible even if they collide with the text.
	*
	* @requires textField
	*/
	textIgnorePlacement?: Value<boolean, ['zoom']>;
	/**
	* If true, icons will display without their corresponding text when the text collides with other symbols and the icon does not.
	*
	* @requires textField, iconImage
	*/
	textOptional?: Value<boolean, ['zoom']>;
	/**
	* Whether this layer is displayed.
	*/
	visibility?: Enum<VisibilityEnum, VisibilityEnumValues>;
	/**
	* The opacity at which the icon will be drawn.
	*
	* @requires iconImage
	*/
	iconOpacity?: Value<number, ['zoom', 'feature', 'feature-state']>;
	/**
	* The transition affecting any changes to this layer’s iconOpacity property.
	*/
	iconOpacityTransition?: Transition;
	/**
	* The color of the icon. This can only be used with [SDF icons](https://docs.mapbox.com/help/troubleshooting/using-recolorable-images-in-mapbox-maps/).
	*
	* @requires iconImage
	*/
	iconColor?: Value<string, ['zoom', 'feature', 'feature-state']>;
	/**
	* The transition affecting any changes to this layer’s iconColor property.
	*/
	iconColorTransition?: Transition;
	/**
	* The color of the icon's halo. Icon halos can only be used with [SDF icons](https://docs.mapbox.com/help/troubleshooting/using-recolorable-images-in-mapbox-maps/).
	*
	* @requires iconImage
	*/
	iconHaloColor?: Value<string, ['zoom', 'feature', 'feature-state']>;
	/**
	* The transition affecting any changes to this layer’s iconHaloColor property.
	*/
	iconHaloColorTransition?: Transition;
	/**
	* Distance of halo to the icon outline.
	*
	* @requires iconImage
	*/
	iconHaloWidth?: Value<number, ['zoom', 'feature', 'feature-state']>;
	/**
	* The transition affecting any changes to this layer’s iconHaloWidth property.
	*/
	iconHaloWidthTransition?: Transition;
	/**
	* Fade out the halo towards the outside.
	*
	* @requires iconImage
	*/
	iconHaloBlur?: Value<number, ['zoom', 'feature', 'feature-state']>;
	/**
	* The transition affecting any changes to this layer’s iconHaloBlur property.
	*/
	iconHaloBlurTransition?: Transition;
	/**
	* Distance that the icon's anchor is moved from its original placement. Positive values indicate right and down, while negative values indicate left and up.
	*
	* @requires iconImage
	*/
	iconTranslate?: Value<Translation, ['zoom']>;
	/**
	* The transition affecting any changes to this layer’s iconTranslate property.
	*/
	iconTranslateTransition?: Transition;
	/**
	* Controls the frame of reference for `iconTranslate`.
	*
	* @requires iconImage, iconTranslate
	*/
	iconTranslateAnchor?: Value<
	Enum<IconTranslateAnchorEnum, IconTranslateAnchorEnumValues>,
	['zoom']
	>;
	/**
	* The opacity at which the text will be drawn.
	*
	* @requires textField
	*/
	textOpacity?: Value<number, ['zoom', 'feature', 'feature-state']>;
	/**
	* The transition affecting any changes to this layer’s textOpacity property.
	*/
	textOpacityTransition?: Transition;
	/**
	* The color with which the text will be drawn.
	*
	* @requires textField
	*/
	textColor?: Value<string, ['zoom', 'feature', 'feature-state']>;
	/**
	* The transition affecting any changes to this layer’s textColor property.
	*/
	textColorTransition?: Transition;
	/**
	* The color of the text's halo, which helps it stand out from backgrounds.
	*
	* @requires textField
	*/
	textHaloColor?: Value<string, ['zoom', 'feature', 'feature-state']>;
	/**
	* The transition affecting any changes to this layer’s textHaloColor property.
	*/
	textHaloColorTransition?: Transition;
	/**
	* Distance of halo to the font outline. Max text halo width is 1/4 of the fontSize.
	*
	* @requires textField
	*/
	textHaloWidth?: Value<number, ['zoom', 'feature', 'feature-state']>;
	/**
	* The transition affecting any changes to this layer’s textHaloWidth property.
	*/
	textHaloWidthTransition?: Transition;
	/**
	* The halo's fadeout distance towards the outside.
	*
	* @requires textField
	*/
	textHaloBlur?: Value<number, ['zoom', 'feature', 'feature-state']>;
	/**
	* The transition affecting any changes to this layer’s textHaloBlur property.
	*/
	textHaloBlurTransition?: Transition;
	/**
	* Distance that the text's anchor is moved from its original placement. Positive values indicate right and down, while negative values indicate left and up.
	*
	* @requires textField
	*/
	textTranslate?: Value<Translation, ['zoom']>;
	/**
	* The transition affecting any changes to this layer’s textTranslate property.
	*/
	textTranslateTransition?: Transition;
	/**
	* Controls the frame of reference for `textTranslate`.
	*
	* @requires textField, textTranslate
	*/
	textTranslateAnchor?: Value<
	Enum<TextTranslateAnchorEnum, TextTranslateAnchorEnumValues>,
	['zoom']
	>;
	}

maps/style-spec/v8.json

Lines 1071 to 1088 in f34aa2f

	"layout_symbol": {
	"symbol-placement": {
	"type": "enum",
	"values": {
	"point": {
	"doc": "The label is placed at the point where the geometry is located."
	},
	"line": {
	"doc": "The label is placed along the line of the geometry. Can only be used on `LineString` and `Polygon` geometries."
	},
	"line-center": {
	"doc": "The label is placed at the center of the line of the geometry. Can only be used on `LineString` and `Polygon` geometries. Note that a single feature in a vector tile may contain multiple line geometries."
	}
	},
	"default": "point",
	"doc": "Label placement relative to its geometry.",
	"sdk-support": {
	"basic functionality": {

[WoLewicki]

Yeah, it basically makes a folly:dynamic on the native side that we can parse as we like then.

[mfazekas]

Yeah, it basically makes a folly:dynamic on the native side that we can parse as we like then.

This is only available in RN 0.72 right? So we only support 0.72 and later for new architecture builds:

facebook/react-native@0ae5e50

With "react-native": "0.71.7",

I'm getting:

ORG_GRADLE_PROJECT_newArchEnabled=true ./gradlew assemble

> Task :rnmbx:generateCodegenSchemaFromJavaScript FAILED
/Users/boga/Work/OSS/RNMBGL/maps/example/node_modules/flow-parser/flow_parser.js:807
throw a}function
^

Error: Unknown prop type for "attributionPosition": "UnsafeMixed"

[WoLewicki]

This is only available in RN 0.72 right?

Wow, I didn't even know this, would have to check.

And yeah, the current state of Fabric is that it introduces breaking changes in each version of react-native so all libraries we maintain only support the newest version of react-native.